resolving two dependency chains in FuseESB and Jersey Servlet

Question

I am trying to deploy a Jersey servlet in FuseESB (based on apache serviceMix) but I get the following error:

Error executing command: Unable to resolve module com.temp.myappserver [248.4] because it is exposed to package 'javax.ws.rs' from org.apache.servicemix.specs.jsr311-api-1.1 [139.0] and com.sun.jersey.jersey-core [274.0] via two dependency chains.

Chain 1:
  com.temp.myappserver [248.4]
    import: (&(package=javax.ws.rs)(version>=1.1.0)(!(version>=2.0.0)))
     |
    export: package=javax.ws.rs
  org.apache.servicemix.specs.jsr311-api-1.1 [139.0]

Chain 2:
  com.temp.myappserver [248.4]
    import: (package=com.sun.jersey.spi.container.servlet)
     |
    export: package=com.sun.jersey.spi.container.servlet; uses:=com.sun.jersey.server.impl.application
  com.sun.jersey.jersey-servlet [267.0]
    import: (package=com.sun.jersey.server.impl.application)
     |
    export: package=com.sun.jersey.server.impl.application; uses:=javax.ws.rs
  com.sun.jersey.jersey-server [265.0]
    import: (package=javax.ws.rs)
     |
    export: package=javax.ws.rs
  com.sun.jersey.jersey-core [274.0]

I know why I get this error - indeed the jersey-core jar manifest exports javax.ws.rs and serviceMix depends on its own implementation.Is there a way to resolve it or do I need to convert my services to CXF?

Answer 1

You have analyzed the problem correctly: Felix cannot resolve this situation, since there are two bundles providing a package, com.sun.jersey.jersey-core doesn't import it (it should), and the your own bundles wants to import a specific version, that is different from the one that com.sun.jersey.jersey-core provides (since that bundle does not provide a version statement, it defaults to 0.0.0, so it doesn't match your requirement).

So, what can you do?

• The best solution would be for the jersey-core bundle to provide the correct imports, in stead of imposing its own version on the rest of the framework.
• Since that might take a while, you can drop the version statement in your own import, giving the framework a chance to wire you up to the jersey-core bundle, in stead of the servicemix one. I know that is not an ideal situation, but it seems to be the best we can do.

As a general note on uses constraints, see Neil Bartlett's post on 'uses'.