OSGi JAX-RS Connector 4.0 released

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

  • We updated the underlying Jersey library to 2.8 which was released back in April. This update is one of the main reasons we are doing the major version upgrade. From Jersey 2.7 on, the team decided to use Java 7 to compile Jersey. Thus Jersey 2.7+ does not work anymore with Java 6 runtimes. As a result we also needed to upgrade the connector to Java 7. We think it’s worth a major version upgrade to indicate the possible incompatibility with older releases.
  • One major thing that has changed from Jersey 1.x to 2.x is its dependency chain. It has grown over the last months and it just became hard to use it within OSGi. For this reason we decided to rebundle Jersey and provide it as a single bundle called com.eclipsesource.jaxrs.jersey-all which will be delivered with the 4.0 release. The jersey-all bundle does not have fancy dependencies because all of them are included in the bundle and not exposed. The connector still works with the original/untouched Jersey version but we do not ship it with the release. If you want to use the original bundles you have to fetch them on your own.
  • With the introduction of the com.eclipsesource.jaxrs.jersey-all bundle it’s now possible to update the underlying Jersey library much faster. For this reason we can do more minor releases in the future that just contain bug fixes and Jersey updates. This process is nearly automated now.
  • @greencable and ProSyst Software GmbH opened a pull request to support older OSGi runtimes (OSGi R4) which was happily accepted.
  • The consumer was modified to be more robust when building paths. Also a new exception type was introduced called RequestException. It exposes request details like the status code and so on. With this it’s possible to have a more specific error handling.
  • The Gson Provider is API now. This means you can consume it as a service and also modify its contained Gson instance for custom de-/serialization.

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

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

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

At this point I want to thank all the contributors for their great work: @greencable, @NOLFXceptMe and @BryanHunt. As always, feel free to comment icon wink OSGi JAX RS Connector 3.1 released.

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

4 Comments
  • Rob Smallwood
    Posted at 11:22, 2014-07-23

    Do you have any examples of using this with a maven build process i.e. Nothing eclipse dependent.. I’m looking to use this with Karaf and using either Felix or Equinox.. Any advice?

  • Alex
    Posted at 11:17, 2014-08-21

    Any updated on the Rob’s question?

  • Arun
    Posted at 10:32, 2014-08-22

    Dear Holger,

    Firstly, I must say that the osgi-jax-rs connector is a wonderful piece of software and works like a charm. Its lightweight and was exactly what I was looking for. Everything works great. However, when I tried to change some default configurations, I am facing some troubles. I am a new to osgi, so I hope I didnt make blatant mistakes.

    I tried to follow your directions to change the location of the default context path from /services to say /test, but was unsuccessful. Using the steps described in [1], I created an osgi.rest.example plugin project (equinox). I tried to use the ConfigurationAdmin to configure the Configuration service provided by com.eclipsesource.jaxrs.publisher as described in the readme and faq section.

    In the activator, I created a private method, called reconfigureServicePath() as follows:

    private void reconfigureServicePath(BundleContext bundleContext)
    throws IOException {
    ServiceReference configurationAdminReference = bundleContext
    .getServiceReference(ConfigurationAdmin.class.getName());

    if (configurationAdminReference != null) {
    ConfigurationAdmin configAdmin = (ConfigurationAdmin) bundleContext
    .getService(configurationAdminReference);
    Configuration config = configAdmin
    .getConfiguration(“com.eclipsesource.jaxrs.connector”);

    Dictionary props = config.getProperties();
    if (props == null) {
    props = new Hashtable();
    }
    // configure the Dictionary
    props.put(“root”, “/test”);

    // push the configuration dictionary to the Configuration service
    // provided by the publisher
    config.update(props);
    }
    }

    I call this method in the start() of my activator as follows:

    public void start(BundleContext bundleContext) throws Exception {
    Activator.context = bundleContext;
    registration = bundleContext.registerService(ExampleResource.class,
    new ExampleResource(), null);
    this.reconfigureServicePath(bundleContext);
    }

    I updated the original launch described in [1] to include the following plugins:

    org.eclipse.equinox.cm | start level: 3 | auto-start:true
    org.eclipse.equinox.ds | start level: 1 | auto-start: true

    When the osgi.rest.example plugin starts, I get the correct configuration (non null with correct pid), but the dictionary is always null. Thus, I am not able to change the default context path from /services to /test. I am sharing my project with you [2]. It includes the launch configuration as well as the target.

    Hopefully you can help me out. Thank you

    Cheers
    Arun

    [1] https://eclipsesource.com/blogs/2014/02/04/step-by-step-how-to-bring-jax-rs-and-osgi-together/

    [2] https://drive.google.com/file/d/0BxNDJdfXyjnoMlVSd0V2Qk5fV00/edit?usp=sharing