Improper OSGi manifest

[glassfishrobot]

I am using the OSGi version of Metro in version 2.3.1, but I cannot create an OSGi runtime environment so that all package dependencies get fulfilled. I have a minimum standalone runtime (without OSGi) using:
jetty:9.2.10.v20150310, stax:1.7.7, gmbal:4.0.0.b001, management-api:3.2.1.b002, pfl-tf:4.0.0.b004, pfl-basic:4.0.0.b004, ha-api:3.1.9, javax.servlet-api:3.1.0.

Everything is working fine, but in OSGi I have tried to fulfill all package dependencies, but there is no way of getting Metro working. Some packages are not available on the OSGi package layer by third party bundles and some come directly from the underlying JRE. I think that the manifest file must be fixed to get a working version of Metro in OSGi and make all packages optional that are not required by Metro.

That's a hard blocker for me and hopefully there is an OSGi expert available that can help me getting Metro running under OSGi.

[glassfishrobot]

Reported by herr-herner

[glassfishrobot]

Was assigned to snajper

[glassfishrobot]

herr-herner said:
I got it working, but you must correct the manifest generation.

Here is the solution. Can you please add it?

webservices-osgi:pom.xml

...
com.sun.xml.xsom.*;resolution:=optional,
...


*

The packages com.sun.xml.xsom.* are exported by jaxb-osgi, but without any versions. The fix in the import statements allows OSGi to bind the optional package dependency to jaxb-osgi bundle. The dynamic package import of * is necessary, because we must load classes listed in the @webservice annotation at runtime, e.g. @webservice(endpointInterface = "webservice.TestWebService"). Otherwise, we get a ClassNotFoundException because the interfaces are not known in advance, so that the packages dependencies cannot be declared in form of import statements.

[glassfishrobot]

snajper said:
Looking at JAXB builds, jaxb osgi manifest, I'm seeing:
com.sun.xml.xsom;uses:="org.relaxng.datatype,org.xml.sax,com.sun
.xml.xsom.impl.scd,javax.xml.namespace,com.sun.xml.xsom.util,com.sun.
xml.xsom.parser,com.sun.xml.xsom.visitor";version=20140925
in the export. So, the version is in there. Am I missing something?
DynamicImport causes trouble to consuming products, such as GF:
http://wiki.osgi.org/wiki/DynamicImport-Package
Though I'm not aware of any other solution.

[glassfishrobot]

herr-herner said:
I am refering to webservices-osgi 2.3.1. The manifest contains under Import-Package com.sun.xml.xsom.parser;version="[20130531.0,20130532)", but the jaxb-osgi 2.2.11 has the export statement com.sun.xml.xsom.parser;version=20140925. The versions do not match resulting that webservices-osgi does not get resolved. Any ideas?

Without the DynamicImport-Package statement, a web service containing e.g. @webservice(endpointInterface = "webservice.TestWebService") fails with a ClassNotFoundException because the package "webservice" is not visible to the classloader of webservices-osgi that you are using for loading the class. If you use another classloader, this will be possible. One way is to get the classloader of the class containing the annotation (that is acually the WebService implementation) and get the class from him. This classloader sees the class in OSGi because it is the classloader of the corresponding bundle.

If you are willing to make some code adaptions, I would try to test it directly in my OSGi environment. My aim is to get a full working version of Metro in the OSGi world.

[glassfishrobot]

herr-herner said:
Just a question: What are the next steps in Metro development? The project seems not be really active, although Sun, Oracle and you made a good implementation job and I think it is worthwhile to revive Metro. In comparison to Apache CXF, Metro is much more light-weighted, but the project requires "some" maintainance work. It builds only under an old Maven version (I used 3.0.5, it fails with 3.3.1) and only with Java 7. Your dependencies are outdated and need to be replaced, requiring some code adaptions. Even in times where everybody thinks that RESTful services are the answer to everything, I am of the opinion that "classical" SOAP-based Web Services have the right to coexist.

[glassfishrobot]

petr_dolezal said:
Voting for this issue as well (and I'd vote for related JAX_WS-396 if not closed already). I'm trying to run Metro in an OSGi container using the bundles from osgi/ folder supplied in the Metro 2.3.1 release and I'm having really tough time. Again.

Originally, we wrapped Metro and other problematic libraries in a single monolithic bundle. It was few years ago, when the OSGi support was weak for most libraries. However, although it works, this approach is not really viable, it has some limitations and brings other problems. Therefore we were separating the bundled parts from the monolithic behemoth step after step, as the upgrades of the libraries allowed. The remaining part now is basically the web-related stuff and Metro is the the major reason why we were not able to finish the separation so far. Now we need to upgrade a part of our dreadful monolith, so we attempted again to break its hard core and finally get rid of it.

My setup starts from quite small core based on Equinox (Mars) with basic Jetty 9 parts, running on JRE 8. Then I tried to add Metro and it began. It seems that Metro requires really many other bundles, which are often difficult to find. Some of imported packages (even not optional!) look very dubious: I really don't understand why a WS framework requires javax.mail (just one example) or why a web service client application running in an OSGi container must provide the Servlet API.

I have the suspicion that the release might be tried with Glassfish, where it perhaps works fine, because Glassfish is capable of providing all those dependencies, although that are not usually needed. But for other, more light-weight containers these dependencies provide a very difficult obstacle.

OK, my humble request calls for adapting Metro, so that it can be deployed easily into a generic OSGi container that provides minimal, but sufficient support for running a web service or for acting as a web service client.

My situation can be replicated easily. Although we use Equinox as the OSGi container, any other comparable container can be used; e.g., Felix is very easy to use. Just download the container and supply following bundles. And then try to make even the Metro bundles resolved/active. Being desperate, I started to mark some imports as optional and even then it took non-trivial effort to make it start at least.

Here is the set of bundles that I start with, webservices-osgi.jar is the only troublemaker then:

// Bundle list: bundle symbolic name, version, file name
//
// Runtime support
// Mostly for javax.* bundles (although not complete yet, but these look essential)
javax.el, 2.2.0.v201303151357, javax.el_2.2.0.v201303151357.jar
javax.jws, 2.0.0.v201005080400, javax.jws_2.0.0.v201005080400.jar
javax.servlet.jsp, 2.2.0.v201112011158, javax.servlet.jsp_2.2.0.v201112011158.jar
javax.servlet, 3.1.0.v201410161800, javax.servlet_3.1.0.v201410161800.jar
javax.xml.stream, 1.0.1.v201004272200, javax.xml.stream_1.0.1.v201004272200.jar
javax.xml.ws, 2.1.0.v200902101523, javax.xml.ws_2.1.0.v200902101523.jar
javax.xml, 1.3.4.v201005080400, javax.xml_1.3.4.v201005080400.jar
org.apache.bcel, 5.2.0.v201005080400, org.apache.bcel_5.2.0.v201005080400.jar
org.apache.xalan, 2.7.1.v201005080400, org.apache.xalan_2.7.1.v201005080400.jar
org.apache.xerces, 2.9.0.v201101211617, org.apache.xerces_2.9.0.v201101211617.jar
org.apache.xml.resolver, 1.2.0.v201005080400, org.apache.xml.resolver_1.2.0.v201005080400.jar
org.apache.xml.serializer, 2.7.1.v201005080400, org.apache.xml.serializer_2.7.1.v201005080400.jar
org.objectweb.asm.all, 5.0.4, asm-all-5.0.4.jar

// Jetty
org.eclipse.jetty.continuation, 9.3.5.v20151012, jetty-continuation-9.3.5.v20151012.jar
org.eclipse.jetty.deploy, 9.3.5.v20151012, jetty-deploy-9.3.5.v20151012.jar
org.eclipse.jetty.http, 9.3.5.v20151012, jetty-http-9.3.5.v20151012.jar
org.eclipse.jetty.io, 9.3.5.v20151012, jetty-io-9.3.5.v20151012.jar
org.eclipse.jetty.jmx, 9.3.5.v20151012, jetty-jmx-9.3.5.v20151012.jar
org.eclipse.jetty.schemas, 3.1.0.M0, jetty-schemas-3.1.jar
org.eclipse.jetty.security, 9.3.5.v20151012, jetty-security-9.3.5.v20151012.jar
org.eclipse.jetty.server, 9.3.5.v20151012, jetty-server-9.3.5.v20151012.jar
org.eclipse.jetty.servlet, 9.3.5.v20151012, jetty-servlet-9.3.5.v20151012.jar
org.eclipse.jetty.servlets, 9.3.5.v20151012, jetty-servlets-9.3.5.v20151012.jar
org.eclipse.jetty.util, 9.3.5.v20151012, jetty-util-9.3.5.v20151012.jar
org.eclipse.jetty.webapp, 9.3.5.v20151012, jetty-webapp-9.3.5.v20151012.jar
org.eclipse.jetty.xml, 9.3.5.v20151012, jetty-xml-9.3.5.v20151012.jar

// Web Services
// Here the problems start
jaxb-api, 2.2.12.b140109_1041, jaxb-api.jar
com.sun.xml.bind.jaxb-osgi, 2.2.10.b140802_1033, jaxb-osgi.jar
stax2-api, 3.1.1, stax2-api.jar
org.glassfish.metro.webservices-api-osgi, 2.3.1, webservices-api-osgi.jar
org.glassfish.metro.webservices-osgi, 2.3.1, webservices-osgi.jar
woodstox-core-asl, 4.2.0, woodstox-core-asl.jar

[glassfishrobot]

This issue was imported from java.net JIRA METRO-32