Configuring Jersey Application

It is a common issue, I am asked about every now and then, how to pass the user data to a user application? The user needs to change the code behavior depending on the configuration data. This is where the @Context Configuration comes handy.

In the following text, I try to describe the possible methods to pass the user’s property to the Configuration object so that it is available when it is injected.

Hardcode in the Application/ResourceContext

This is the simplest way, just set the property just like:

new ResourceConfig().property("NAME","VALUE")

Using web.xml Initial Parameters

For classic war bundled applications, the properties can be defined in the web.xml:


Using the AutoDiscoverable

Jersey comes with AutoDiscoverable SPI, which allows for being detected by a JDK’s ServiceLoader when anywhere on a classpath. Such AutoDiscoverable is then used as if it were a part of the application. The advantage is that the application itself does not need to be rebuilt, only the AutoDiscoverable with the properties.

The org.glassfish.jersey.internal.spi.AutoDiscoverable service needs to be added to META-INF/services, and it needs to point to the AutoDiscoverable implementation:

public class MyAutoDiscoverable implements AutoDiscoverable {
    public void configure(FeatureContext context) {"NAME", "VALUE");

Using the System Properties

Quite often, the administrators come and ask to configure Jersey application, mainly to use any of the CommonProperties property, but they do not want to recompile their Jersey application, nor the AutoDiscoverable. Since Jersey 2.29 it is possible to turn on the ability to convert the System properties into Configuration properties. That can be done by using the System property, too:

java -Djersey.config.allowSystemPropertiesProvider=true -DNAME=VALUE

Note that with the security manager turned on, write access permission is required to execute System.getProperties(). With insufficient permissions, the warning message is logged (with Level.FINER) and only CommonProperties, ClientProperties, and ServerProperties properties are used, as the property names are known and System.getProperty(name) method can be used, which does not require the write access permission.

Using Microprofile Config

Microprofile platform became very popular lately and Microprofile Config Specification is a recommended way in the Jakarta EE world to configure the specifications under the Jakarta EE umbrella.

Jersey 2.29 comes with support for Microprofile Config implementation such as Helidon or SmallRye. To configure the Jersey application, the file needs to be created in the META-INF folder. The required properties are then simply set in the


Then Jersey Microprofile Config extension is needed to be added:


And the Microprofile Config implementation, such as Helidon:


Or SmallRye:


or any other suitable Microprofile Config implementation.

Other Methods

There are other methods that are variants to the described methods, or they are less straightforward and significantly more complicated. However, if you have any other favorite method that was not discussed, I’d love to hear about it in the comments.

Posted in Jersey | Comments Off on Configuring Jersey Application

Jersey 2.29.1 has been released!

What a busy summer! Jersey 2.29 has been released in June and Jakarta EE 8 release was the next goal to be achieved before Oracle Code One.

It has been a lot of work. Jakarta EE 8 contains almost 30 different APIs, one-third of which Jersey depends on. Fujitsu, IBM, Oracle, Payara, RedHat, Tomitribe, Eclipse Foundation, the individual contributors, everyone worked hard to follow the new certification process to get the Certification of Compatibility of the new APIs released as part of Jakarta EE together with the respective implementations.

As of today, three application servers were announced to be certified Jakarta EE 8 Application Servers, Eclipse Glassfish 5.1, IBM OpenLiberty and RedHat WildFly announced they are fully certified as a compatible implementation of the Jakarta EE 8 profiles.

Jersey team provided a great deal of help with the certification, building some of the APIs, creating the TCK jobs and run some of the TCKs, …, and yet the team was able to deliver a new version of Jersey!

Jersey 2.29.1 is mainly a maintenance release, with a couple of fixes, and three main new features. It depends on the new Jakarta EE 8 APIs (mainly JAX-RS 2.1.6), it provides ApacheHttpClientBuilderConfigurator to improve the ability to configure Apache Http Client, and it provides a Microprofile Rest Client 1.3.3 implementation. The full list of features is available here.

Please give it a try and let us know how you like it.

Posted in Jakarta EE, Jersey | Comments Off on Jersey 2.29.1 has been released!

Jersey 2.29 has been released!

It is a pleasure to announce that Jersey 2.29 has been released. It is rather a large release. While Jersey 2.27 was the last non-Jakarta EE release and Jersey 2.28 was the first release of Jersey under a Jakarta EE umbrella, and both of them stayed compatible with Jersey 2.26 as much as possible (binary compatibility, no new API, only updated dependencies and fixes that did not change the Jersey API or behavior), Jersey 2.29 brings many fixes that stacked up since 2.26 and lot of new features, most notably:

  • JDK 11 support
  • Possibility to pass configuration properties through the environment variables
  • Possibility to pass configuration properties using a Microprofile Config implementation
  • Implementation of Microprofile REST Client specification
  • Extension module for Spring 5
  • Possibility to use HK2 Abstract Binder removed in 2.26 again for backward compatibility
  • Enhanced Jetty connector configuration possibilities

Please let us know how you like it!

We are still working on the documentation, though. We have updated the design of a User Guide to correspond with the Jakarta EE style. Now we need to focus on the content, fix what is obsolete and describe new features, that’s our main goal for the silly season!

Posted in Jersey | Comments Off on Jersey 2.29 has been released!

Jersey 2.28 has been released

Jersey 2.28 has been released and is available in maven central! Jersey 2.28, the first Jakarta EE implementation of JAX-RS 2.1 has finally been released. Please let us know how you like it!

After whole Java EE has been contributed to the Eclipse Foundation, every project mainly focused on introducing the project and on bringing it closer to the community. From all the tools made available for the community, I’d like to mention Travis CI. It is a great tool that can be used by the community to verify the functionality of provided pull requests. As always Jersey team is happy for them as well as for any other help from the community.

Another goal of Jakarta EE was to create a new release of every project with new versions of dependencies released in the Jakarta EE. In the case of Jersey, the dependencies were updated as much as possible. Of course, sometimes that’s not desired, such as when testing integration with Servlet 2.5 the dependency on Servlet 4.x is not exactly right.

Functionally, we mainly focused on fixing issues, first with building Jersey that was reported by the community, and later some reported differences between Jersey and JAX-RS Specification. This is common for every Jakarta EE project this release: it was required not to provide any changes in API and functionality to ensure the compatibility between last Java EE and initial Jakarta EE releases.

Jersey master contains quite a list of changes, fixes, and improvements to be available in next Jersey release. Currently, there are a few legal details left that need to be resolved so that Jakarta EE projects are allowed to release a version that has API changed, that brings new features, and/or modifies some behavior. Once those legal matters are resolved, a next Jersey release will be created!

Posted in Jersey | 1 Comment

Eclipse Glassfish 5.1.0.RC2 has been released!

That’s right, Eclipse Glassfish 5.1.0.RC2, the Jakarta EE implementation, has been published in maven central. Eclipse Glassfish 5.1.0 release is terribly close.

Latest Glassfish in maven central, Eclipse Glassfish 5.1.0.RC1, publicly available couple of months, is mostly identical to Oracle Glassfish 5.0.1, the latest Java EE reference implementation. It contains many Java EE projects and dependencies, and it has been released mainly for the Eclipse community to introduce Jakarta EE, its functionality, and to demonstrate the commitment of all people working on Jakarta EE.

Eclipse Glassfish 5.1.0.RC2 is very close to the final version, all the Java EE compatibility tests passed there, while it depends on Jakarta EE APIs and implementation rather than Java EE ones.

Comparing Java EE and Jakarta EE, functionally, there is only a minimal difference. That was the goal, to transfer the Java EE to Jakarta EE without changes in the API, so that the community can smoothly deploy the projects from a Java EE application server to the Jakarta EE application server. Only major bug fixes in the functionality were allowed.

Jakarta EE was focused on bringing the projects close to the community. Everyone with enough enthusiasm can start contributing to a project and become a committer. Most of the projects do use Travis CI and the projects contain Travis scripts so that anyone who wants to contribute can run the tests in his own GitHub fork on Travis CI (after registering there). For the projects, committers have access to Eclipse Jenkins infrastructure, where any build and test jobs can be set up. Unlike with Java EE, the compatibility tests are available, with a description of how to use them. There is a Jakarta EE wikipedia, and each project has its own mailing list.

Apart from these new things, the license of projects has been changed. The code is available under EPL 2.0 license, whereas examples are available under EDL 1.0 license.

The main positive thing, though, is that it is the interest of the community that decides about the future of the Jakarta EE projects.

Posted in Jakarta EE | Comments Off on Eclipse Glassfish 5.1.0.RC2 has been released!

Jersey 2.28-RC4 has been released

Jersey 2.28-RC4 is available in maven central! Jersey 2.28-RC4, the first Jakarta EE publicly available version of Jersey, is an almost final version of Jersey 2.28.

Jersey 2.28, is to be released soon. It will be part of Eclipse Glassfish 5.1.0, which is to be officially released January 29. Only a few changes are yet to be made, mainly in versions of dependencies that are yet to come. Unlike the three previous internal RCs, Jersey 2.28-RC4 is mature enough to be available in maven central. Check it out and let us know how you like it!

Posted in Jersey | Comments Off on Jersey 2.28-RC4 has been released

Glassfish 5.1.0 is to be released!

Glassfish Application Server has been the reference implementation of Java EE since Java EE 5. Those days, it was Glassfish version 2. Java EE 6 reference implementation was Glassfish 3.x, Java EE 7 reference implementation was Glassfish 4.0, Java EE 8 reference implementation was Glassfish 5.0.

A little bit over a year ago it was announced that Java EE is to be contributed to the Eclipse Foundation. The process was not a trivial task, the code to be contributed was revisioned and updated to be legally correct, secure, and cleaned. Right before each project on GitHub was archived and transferred under Eclipse Foundation and Jakarta EE, one last version of it was released. This is what makes Oracle Glassfish 5.0.1, the latest reference implementation of Java EE 8.

Eclipse Glassfish 5.1.0, on the other hand, is Jakarta EE implementation. It is the initial Jakarta EE release, that has a binary compatible API with Java EE and Java EE Compatibility Test Suite should pass with this initial Jakarta EE release. There is some difference between Java EE 8 and Jakarta EE, though.

The contributed Java EE projects were subject of community revision. While only small changes that do not change the API were allowed for the initial release, the projects updated their dependencies, updated functionality to work with them, fixed some possible bugs, polished documentation, and javadoc, and adopted the Eclipse license.

After the hard work that started at the end of 2017 by Oracle contributing millions of rows of Java EE code, and continued by the Eclipse Foundation and the community, after a little more than a year, January 29 is to be the Eclipse Glassfish 5.1.0, the Jakarta EE implementation, release date.

Posted in Jakarta EE | Comments Off on Glassfish 5.1.0 is to be released!

Happy New Year: But Where Are the Christmas Presents?

The year 2018 is to be over soon. Christmas is over, but there is no Jakarta EE for a Christmas present –  the Jakarta EE release is postponed to January 2019. Not even Jersey 2.28 is released. While it may seem so – the GitHub repository already contains tag and branch 2.28 – the tag and branch are erased and recreated again, from time to time.

This is confusing, but it actually is how the Jakarta release is planned. In order to minimize the effort to release Jakarta EE, this one time only, each project is staged with a final version, so that any other project depending on it can immediately have a reference to the project, without a need to update the version in dependency list every time the project is updated. Each project is possibly staged a couple of times, with git tag and branch updated.

It has some advantages, but it goes against the maven intention. Without comparing all the pros and cons, it is obvious the community can be under an impression that the 2.28 is final already. I am really sorry for the confusion, it is not only Jersey related, it is Jakarta EE wide, caused by good intentions of trying the release to be as fast and smooth as possible.

The final release will be well announced, of both Jakarta EE and Jersey (by email, twitter, blog…). Jersey will merge GitHub EE4J_8 branch to master. And Jersey and Eclipse Glassfish will be available in maven central.

Enjoy what’s left of 2018, Very Happy New Year, and best wishes to Jakarta EE in 2019.

Posted in Jakarta EE, Jersey | Comments Off on Happy New Year: But Where Are the Christmas Presents?

Finishing Jakarta EE Release

It has been a year since the opening of Java EE has been announced. Whole year first the Oracle company and later the Jakarta EE community jumped in to be working hard on the transition of every Java EE technology to the Eclipse Foundation under Jakarta EE umbrella. Java EE reference implementation – Glassfish application server, as well as the Java EE Technology Compatibility Kit (Java EE TCK), are under the Jakarta EE umbrella, too.

As part of the transition process, couple of Java EE technologies were released recently, noticeably (from the Jersey perspective):

However, these technologies won’t be part of the initial Jakarta EE release. Every API and every implementation needs to be released again, with Eclipse compatible license. The initial Jakarta EE release should be (binary) compatible with the latest Java EE releases.

To prove the compatibility of Jakarta EE with JavaEE, the Jakarta EE initial release needs to pass Java EE TCK. The process is to stage the artifacts first, integrate to Eclipse Glassfish, pass the Java EE TCK, and then release the artifacts, the Jakarta EE initial release.

All of the Jakarta EE APIs were staged. The API artifacts are no longer javax.* jars, they are jakarta.* jars, now. JAX-RS API will be of version 2.1.3. The implementations are being staged, too. Eclipse Jersey will be of version 2.28.

Everyone works hard on the Jakarta EE release, but it is a bit overdue. All the artifacts were planned to be staged before November 5th. Currently, it looks like a couple of more weeks are needed. The good news is, it’s happening, and likely everyone can get his Jakarta EE to release for a Christmas gift.


Posted in Jakarta EE, Jersey | Comments Off on Finishing Jakarta EE Release

Introducing Jersey to the Eclipse Community

Most of the Java EE projects have already transitioned to the Eclipse Foundation under the Jakarta EE umbrella of projects. One of those projects is Jersey, which is a RESTful Web services framework and reference implementation of the JAX-RS Specification. We announced the initial contribution of Jersey a few weeks ago. Since then, we saw an increase of community interest in Jersey. We registered a number of filed ideas for enhancements, discovered issues, and received pull requests from both individuals and industry. All of these are very welcome.

Jersey is used in Glassfish and Weblogic application servers, and it is often understood to be an “enterprise” framework that needs full application server with CDI, EJB, and bean validation support, or at least a servlet container, such as Tomcat. Sure, Jersey can leverage integration with other Java EE/Jakarta EE projects, but there is more.  Jersey comes with an ability to deploy JAX-RS application in a Java SE environment; it provides a container extension module that enables support for using a variety of frameworks that only understand the HTTP protocol. This is useful in the microservices world. Using Jersey, you can create a simple micro application that is capable of running inside a Docker container with just a JDK installed!

Let’s create an application that accepts queries and provides answers. First, we define the maven dependencies. Note the last hk2 dependency which is needed since Jersey 2.26:


For simplicity, we can use the HTTP server from the JDK so as not to bring other dependencies, such as the widely used Grizzly. (Other deployment options are described in the Jersey User Guide, which has yet to be transitioned to the Eclipse Foundation):


We would like to send popular JSON, so we add a dependency for it:


We define the entity to be sent as an answer and the resource that sends responses for the ultimate question requests:

public class Answer {
  public Answer(String answer) {
    this.answer = answer;
  public String answer;

public class QuestionResource {
  public static final String RESPONSE = "42";

  public Answer getResponse() {
    return new Answer(RESPONSE);

We start the JDK HTTP Server on port 8080 with the QuestionResource registered. We also want the entity to be wired as JSON, so we use JsonBindingFeature:

URI base_uri = UriBuilder.fromUri("http://localhost/").port(8080).build();
ResourceConfig config = new ResourceConfig(QuestionResource.class, JsonBindingFeature.class);
JdkHttpServerFactory.createHttpServer(base_uri, config);

At this point, the Jersey application is up. We can use cURL, or even better, the JAX-RS Client (implemented by Jersey of course – and we have defined the maven org.glassfish.jersey.core:jersey-client dependency for it already):


And we should see the JSON response:


The ability to run the JAX-RS application in the Java SE environment is a new feature in the planned JAX-RS 2.2 release.

JAX-RS is evolving fast. There are already plans for 3.0, which Jersey needs to reflect. Also there are MicroProfile features that Jersey should either implement or integrate with. And JDK 9/10/11 need to be fully supported. There is a lot of work for the future and we are looking forward to hearing from the community. Your feature proposals, bug reports, and pull requests are very much appreciated!

Posted in Jersey | 2 Comments