Another tiny step forward for Jersey JDK container

Fellow readers (hope it is not too exaggerated to use plural, I like to believe there is more than one of you), this time it will be no rocket science. I know it never was, but today’s post is basically just a little more than a overgrown tweet. But sometimes even a tiny new feature deserves its promo, so that someone’s notices it.

As you might know, Jersey 2 runs on variety of environments, ranging from small and lightweight through servlet up to dinosaur. This time we made a small improvement on the smaller side of the food chain – the jdk-http container module which (among other containers) provides support for running JAX-RS applications in a servlet-less environment on a plain http server, in this case based on com.sun.net.httpserver.HttpServer that comes with the JDK since Java 6.

Our user pointed out, that he would like to be able to configure custom SSLContext to be used with the JDK Server. It was surprising, that our container does not provide this possibility yet, because that rendered using it for https connections unusable. On the other hand, no wonder, as from the same ballpark, we emphasise Grizzly quite a lot, we even chose it as default container for tests and lot of people seem to be using the same (when considering the lighter end of our scale).

So, what’s new? From inside, just a few lines of code, from outside three new overloaded methods in the container’s API.

One that accepts javax.net.ssl.SSLContext:

and two more that accept com.sun.net.httpserver.HttpsConfigurator, the JDK Server’s native encapsulation of the https configuration:

and a bit shorter one, that always starts the server right after the creation:

Note, that even that the server API makes it possible to get the reference to the HttpsConfigurator it uses, but once the server is started, you cannot change it.

Therefore while calling (the last parameter being the start flag):

returns still potentially usable HttpsServer (if you configure the SSLContext before starting it), trying to call:

will fail with an IllegalArgumentException, because you’ve lost your last chance to configure it and the instance is useless.

See it in action in the JdkHttpsServerTest and enjoy.

Leave a Reply

Your email address will not be published. Required fields are marked *