OSGi JAX-RS Connector 3.2 released

OSGi JAX-RS Connector 3.2 released

connectorToday we are proud to release the OSGi JAX-RS Connector 3.2. A lot has happened since the 3.1 release back in October 2013. This post will give you an overview of the new and noteworthy things included in the 3.2 release.

  • We upgraded the underlying Jersey library to 2.5 which was released back in December. We also included the bundles needed for multipart formdata requests.
  • Bryan Hunt started the work on an OSGi friendly integration of the JAX-RS security features. The integration is contained in the new security provider bundle which is called com.eclipsesource.jaxrs.provider.security. All you need to do to use this feature are two things: 1) Start the provider bundle and 2) Implement two interfaces (AuthenticationHandler and AuthorizationHandler) and register them as OSGi services. More detailed instructions can be found in the wiki.
  • As you may have read in the last paragraph, we have a wiki now ;). It contains a basic FAQ and some tutorials. Feel free to contribute and share you knowledge!
  • JAX-RS “Features” can be registered as OSGi services and will be picked up by the publisher now.
  • The publisher is now able to push messages to the client using Jersey’s SSE feature. To enable this you need to start a new bundle called com.eclipsesource.jaxrs.provider.sse. We have also added an example that shows what SSE does. You can also see this example in action in the screenshot below.sse
  • We splited sources and binaries at the bundle level in the past. With this release we provide real source features build with Tycho’s tycho-source-feature-plugin.

You can consume the connector in the usual ways: download, p2 and maven. Checkout the README for more details.

GitHub repository: https://github.com/hstaudacher/osgi-jax-rs-connector

p2 repository: http://hstaudacher.github.io/osgi-jax-rs-connector

At this point I want to thank all the contributors for their great work: @BryanHunt@toedter@dcaillia@codescale and @ddragosd.

[ Find even more Eclipse Tools to hack your workflow. | Running a mission-critical system? Keep it running smooth with our Production Support. ]

  • David Soto Setzke
    Posted at 3:29 pm, January 8, 2014

    Great work, I love the SSE provider!

    How would you deploy the connector bundle on a karaf instance running Felix? It works perfectly when I copy the jars from the eclipseLink and jersey folders in com.eclipsesource.jaxrs.connector.target and the connector jar to the deploy folder, but I would like to have to copy less files – a karaf feature (http://karaf.apache.org/manual/latest-2.3.x/users-guide/provisioning.html) would be perfect.
    I also tried to build a kar file with your tycho-karaf-bridge (https://github.com/hstaudacher/tycho-karaf-bridge).
    But when I try to deploy the kar file, Karaf fails with an exception:

    Caused by: org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision org.glassfish.jersey.core.jersey-common [272.0] because it is expos
    ed to package ‘javax.annotation’ from bundle revisions javax.annotation-api [267.0] and org.apache.felix.framework [0] via two dependency chains.

    Chain 1:
    org.glassfish.jersey.core.jersey-common [272.0]
    import: (&(osgi.wiring.package=javax.annotation)(version>=1.2.0)(!(version>=2.0.0)))
    export: osgi.wiring.package=javax.annotation
    javax.annotation-api [267.0]

    Chain 2:
    org.glassfish.jersey.core.jersey-common [272.0]
    import: (&(osgi.wiring.package=com.google.common.net)(version>=14.0.0)(!(version>=15.0.0)))
    export: osgi.wiring.package=com.google.common.net; uses:=javax.annotation
    com.google.guava [262.0]
    import: (osgi.wiring.package=javax.annotation)
    export: osgi.wiring.package=javax.annotation
    org.apache.felix.framework [0]
    at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3980)[org.apache.felix.framework-4.2.1.jar:]

    So it seems that guava is trying to use the javax.annotations package provided by the Felix framework and not the one provided by the kar file – is there any workaround for this?

  • David Soto Setzke
    Posted at 5:11 pm, January 13, 2014

    I’ll give it a try as soon as 3.2.0 gets published to Maven Central since I need the SSE provider for my project 😉

  • David Soto Setzke
    Posted at 5:24 pm, January 13, 2014

    Nevermind, I just saw that it’s already there.

  • David Soto Setzke
    Posted at 1:14 am, January 20, 2014

    I managed to create a karaf feature which works great! Is there any chance you could publish the artifacts of the providers (SSE, Security, GSON etc.) on Maven Central so that we can fetch them from there as well and don’t have to build them locally?

  • Keren Dong
    Posted at 1:05 pm, January 29, 2014

    @David, would you mind to share your karaf feature? I’m struggling with exactly the same issue as you did (guava and javax.annotation package). Thanks in advance!

  • Andy Van Den Heuvel
    Posted at 5:51 am, February 7, 2014

    Great project! I’m trying to figure out how to use this togheter with jersey’s mvc functionality.
    For example: If I use FreemarkerMvcFeature with relative template references, jersey is still looking for resources in the osgi-jaxrs-connector.

  • Jason
    Posted at 7:18 pm, February 14, 2014

    Hi Holger,

    This is really nice and has been very helpful to me on a project I am working on. I was wondering if you could help on a closely related matter.

    I am using Response with jaxrs in order to build appropriate http responses which works fine for status codes such as temporary redirect. However, when I use status code 500 I get the jetty error web pages instead of the actual simple status I wanted to send.

    This blocks how REST services are meant to work and I am hoping you know how to turn off the jetty error pages when using Equinox and the embedded jetty server provided.

    Kind Regards,


  • Jason
    Posted at 7:15 pm, February 17, 2014

    To use this with embedded jetty and have no html error pages sent to your xml/json client you need create a custom ErrorHandler and register a Fragment which contains a JettyCustomizer concrete class. In the JettyCustomizer you set the context errorHandler to your new ErrorHandler class. The custom ErrorHandler only needs to implement the following method.

    public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException {
    AbstractHttpConnection connection = AbstractHttpConnection.getCurrentConnection();
    String method = request.getMethod();
    if (!method.equals(HttpMethods.GET) && !method.equals(HttpMethods.POST) && !method.equals(HttpMethods.HEAD)) {
    ByteArrayISO8859Writer writer = new ByteArrayISO8859Writer(4096);

    No more html sent to your xml or json clients.