Hi JB, thanks for the links. In fact the issue you refer to is the one I'd like to work on and the reason the servicemix branch was opened on the jersey repository.
The other link (Davids blog) is a little old and doesn't work anymore using todays libraries. It also introduces dependencies to the Spring framework stuff which shouldn't be necessary. It would be nicer to directly use the 4 to 5 Jersey libs and their direct dependencies to have it working in OSGi. Regards, Daniel Am 15.12.2009 um 14:47 schrieb Jean-Baptiste Onofré: > Hi Daniel, > > There are some issues to use Jersey in OSGi/Karaf/ServiceMix. > > You can find a blog from David: > http://coderthoughts.blogspot.com/2008/03/using-jersey-jsr311-inside-osgi-with.html > > And the open issue in Jersey: > https://jersey.dev.java.net/issues/show_bug.cgi?id=275 > > Regards > JB > > Daniel Bimschas wrote: >> Hi list, >> I'm trying to help on OSGifying the JAX-RS reference implementation Jersey. >> Based on work done by Richard Wallace there was a branch opened (see [1]). >> I tried to replay what is done by the unit tests provided in the >> osgi/servicemix/tests project by manual means, i.e. installing the >> individual jersey bundles and its dependencies manually into Equinox/Felix >> and writing a simple bundle that tries to deploy a Jersey servlet using the >> Grizzly servlet container (which is something that is done in the test using >> Pax Exam). >> My bundle activator implementation does not much more than this: >> // ... >> GrizzlyWebServer gws = new GrizzlyWebServer(8080); >> ServletAdapter jerseyAdapter = new ServletAdapter(); >> jerseyAdapter.addInitParameter("com.sun.jersey.config.property.classnames", >> "com.sun.jersey.osgi.tests.SimpleResource"); >> jerseyAdapter.addInitParameter("com.sun.jersey.config.property.resourceConfigClass", >> "com.sun.jersey.api.core.ClassNamesResourceConfig"); >> jerseyAdapter.setContextPath("/jersey"); >> jerseyAdapter.setServletInstance(new ServletContainer()); >> gws.addGrizzlyAdapter(jerseyAdapter, new String[] { "/jersey" }); >> gws.start(); >> // ... >> which starts up fine. All bundles are resolved and can be started: >> [ 66] [Active ] jsr311-api - servicemix bundle (1.1.5.ea-SNAPSHOT) >> [ 67] [Active ] jersey core - servicemix bundle (1.1.5.ea-SNAPSHOT) >> [ 68] [Active ] jersey server - servicemix bundle (1.1.5.ea-SNAPSHOT) >> [ 69] [Active ] jersey client - servicemix bundle (1.1.5.ea-SNAPSHOT) >> [ 70] [Active ] jersey json - servicemix bundle (1.1.5.ea-SNAPSHOT) >> [ 71] [Active ] jettison (1.1) >> [ 72] [Active ] Jackson JSON processor (1.1.1) >> [ 73] [Resolved ] grizzly-servlet-webserver (1.9.8) >> [ 74] [Active ] ASM all classes (3.1) >> [ 75] [Active ] JerseyTest (0.0.1) >> [ 76] [Active ] Servlet API Bundle (2.5.0.v200806031605) >> Now, if I browse to http://localhost:8080/jersey the following exception is >> thrown: >> javax.servlet.ServletException: Resource configuration class, >> com.sun.jersey.api.core.ClassNamesResourceConfig, could not be loaded >> at >> com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:688) >> at >> com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:620) >> at >> com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:200) >> at >> com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:307) >> at >> com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:470) >> at javax.servlet.GenericServlet.init(GenericServlet.java:241) >> at >> com.sun.grizzly.http.servlet.ServletAdapter.loadServlet(ServletAdapter.java:327) >> at >> com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:268) >> at >> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:165) >> at >> com.sun.grizzly.tcp.http11.GrizzlyAdapterChain.service(GrizzlyAdapterChain.java:185) >> at >> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:165) >> at >> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:659) >> at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:577) >> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:829) >> at >> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:162) >> at >> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136) >> at >> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103) >> at >> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89) >> at >> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76) >> at >> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67) >> at >> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >> at java.lang.Thread.run(Thread.java:637) >> Caused by: java.lang.ClassNotFoundException: >> com.sun.jersey.api.core.ClassNamesResourceConfig >> at >> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:726) >> at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:60) >> at >> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1631) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:250) >> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398) >> at java.lang.Class.forName0(Native Method) >> at java.lang.Class.forName(Class.java:169) >> at >> com.sun.jersey.core.reflection.ReflectionHelper.classForNameWithException(ReflectionHelper.java:220) >> at >> com.sun.jersey.core.reflection.ReflectionHelper.classForNameWithException(ReflectionHelper.java:200) >> at >> com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:653) >> ... 25 more >> What is really weird about that, is that com.sun.jersey.api.core is exported >> by the server bundle and obviously other classes from that bundle and >> package were loaded successfully, too. Using the tracing-feature of Equinox >> I checked the loader output and it confirms that other classes from the same >> bundle and package were loaded. The same behaviour arises with Felix. >> Does somebody have a clue how this is possible? And what could be the >> solution to it? >> Kind regards, >> Daniel Bimschas >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
