Miguel, thank you for checking. I thought that first, too. But, if you look carefully you'll see it contains it often in uses:="...", but also exports it :-(. I'm pretty sure, I just double-checked.
Daniel Am 15.12.2009 um 17:35 schrieb Miguel: > hi, > > I have seen it very fast but, be carefull because as far as I have seen it > seems that jersey-server doesnt export com.sun.jersey.api.core . It is always > within the clause uses:=" ...." > could be that the reason? > > Miguel > Sent from Madrid, Spain > > On Tue, Dec 15, 2009 at 3:53 PM, Daniel Bimschas <[email protected]> wrote: > It's provided by the Bundle "jersey server - servicemix bundle > (1.1.5.ea-SNAPSHOT)", so it should be available. As I said, other classes > from exactly the same package are loaded just fine. > > Daniel > > Am 15.12.2009 um 15:32 schrieb Miguel: > > > which bundle is providing com.sun.jersey.api.core ? > > > > I don't know if there is an osgi bundle which provides it, otherwise you > > must create one and export all the packages of this library (dont forget to > > set the bundle class path) > > > > > > Miguel > > Sent from Madrid, Spain > > > > On Tue, Dec 15, 2009 at 3:23 PM, Daniel Bimschas <[email protected]> > > wrote: > > Forgot to attach the project ;-) > > > > Cheers, > > Daniel > > > > > > > > Am 15.12.2009 um 13:12 schrieb Daniel Bimschas: > > > > > 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 > > > > ---------------------- > > Daniel Bimschas > > Fleischhauer Strafle 45 > > 23552 Lübeck > > [email protected] > > ---------------------- > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev ---------------------- Daniel Bimschas Fleischhauer Strafle 45 23552 Lübeck [email protected] ---------------------- _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
