I've seen similar errors to this described in the past, and they were attributed to the order in which the jersey bundles were started within felix, but with Jersey 1.1.5 (GF 3.0.1) the bundles have been combined, and besides, they get started (or loaded) automatically by the domain startup, so I have no control over the order.
I have a simple OSGi bundle (named framework) that has Jersey client code in it. Within the activator, there is the following code (I moved the code to the activator to simplify the test case. It is normally in a separate module that is called by the activator):
public void start(BundleContext context) throws Exception
{
String baseUrl = "some value here";
try
{
logger.info("Framework Activator starting up.");
ClientConfig cc = new DefaultClientConfig();
cc.getClasses().add(StringReader.class);
cc.getClasses().add(JsonObjectWriter.class);
cc.getClasses().add(JsonObjectReader.class);
cc.getClasses().add(JsonArrayReader.class);
Client client = Client.create(cc);
WebResource resource = client.resource(baseUrl);
}
catch (Exception ex)
{
logger.log(Level.SEVERE, "Error during activation", ex);
}
finally
{
logger.log(Level.INFO, "***** Activation Complete ");
}
}
When the bundle is deployed (dropping it in the autodeploy directory) the 'Client client = Client.create(cc);' line above causes the following error:
[#|2010-10-27T22:31:09.170-0400|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=20;_ThreadName=Thread-1;|org.osgi.framework.BundleException: Activator start error in bundle framework [231].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1751)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1027)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1013)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1006)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:396)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:206)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.sun.jersey.core.header.MediaTypes
at com.sun.jersey.core.spi.factory.MessageBodyFactory.initReaders(MessageBodyFactory.java:154)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.init(MessageBodyFactory.java:145)
at com.sun.jersey.api.client.Client.<init>(Client.java:275)
at com.sun.jersey.api.client.Client.<init>(Client.java:150)
at com.sun.jersey.api.client.Client.create(Client.java:476)
at Activator.start(Activator.java:43)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
... 8 more
If I shut down the domain and clear out the OSGi cache, then I get the following exception prior to the one above:
[#|2010-10-27T22:43:20.570-0400|SEVERE|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=20;_ThreadName=Thread-1;|org.osgi.framework.BundleException: Activator start error in bundle framework [225].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1751)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1027)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1013)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:398)
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:206)
Caused by: java.lang.ExceptionInInitializerError
at com.sun.jersey.core.header.MediaTypes.<clinit>(MediaTypes.java:58)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.initReaders(MessageBodyFactory.java:154)
at com.sun.jersey.core.spi.factory.MessageBodyFactory.init(MessageBodyFactory.java:145)
at com.sun.jersey.api.client.Client.<init>(Client.java:275)
at com.sun.jersey.api.client.Client.<init>(Client.java:150)
at com.sun.jersey.api.client.Client.create(Client.java:476)
at Activator.start(Activator.java:43)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
... 7 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:122)
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:91)
at javax.ws.rs.core.MediaType.<clinit>(MediaType.java:44)
... 16 more
Caused by: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744)
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at javax.ws.rs.ext.FactoryFinder.newInstance(FactoryFinder.java:62)
at javax.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:155)
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:105)
... 18 more
This looks awfully similar to a problem that was described here -
http://jersey.576304.n2.nabble.com/Classloader-problem-with-Felix-Jetty-td5086976.html .
We've got this to work in the past by recycling the domain, clearing out the OSGI cache, and other quirky methods, and sometimes it will start up, but lately I haven't been able to get it to start at all. I've messed around with installing the 1.5-SNAPSHOT Jersey jars, and that seems to alleviate this error, but that causes some other problems with our apps, so I'd like to stick with 1.1.5 for now.
I've tried every combination of dependencies using jersey-server, jersey-core, jersey-client, jersey-json, jettison, etc. and nothing seems to make a difference. Any help would be greatly appreciated.
Larry