Sure, I'll try to to look into it. However I'd appreciate if you could confirm first :
- did you explicitly add an "org.apache.cxf.jaxrs.provider" value to your bundle's Import-Package ? You haven't told me if you tried it - what is the story with the LinkageError you mentioned earlier ? Looked like to me it was to do with the fact there were multiple xml apis floating around in the container. Did you try either of the options suggested ? If you have JAXB working then why does not that LinkageError interfere, does not make sense ? thanks, Sergey Daniel Bimschas-2 wrote: > > Sergey, > > this ping pong game we're playing here seems a little ineffective. > Therefore, I wrote a minimal Hello, World project [1] that reflects my > project layout. There's a run.sh inside that uses Pax Runner to start up. > I hope this helps and you find the time to take a look inside. > > Thanks a million, > Daniel > > [1] > http://www.itm.uni-luebeck.de/users/bimschas/projects/playground.cxf-jaxrs-issue.tar.gz > > Am 05.02.2010 um 15:48 schrieb Sergey Beryozkin: > >> Hi >> >> Please see comments with S.B. >> >> ----- Original Message ----- From: "Daniel Bimschas" >> <[email protected]> >> To: <[email protected]> >> Sent: Friday, February 05, 2010 2:16 PM >> Subject: Re: DOSGi and JSON responses >> >> >> Ah, damnit. I forgot to mention that I took out my self-written >> JSONProvider extending class in order to be sure that doing this doesn't >> get in the way of something. Therefore, Import-Package doesn't contain >> "org.apache.cxf.jaxrs.provider.*" but that should be okay. >> >>> S.B You do not need to extend the CXF provider to the Import-Package >>> including "org.apache.cxf.jaxrs.provider.*", can you make sure please it >>> is explicitly imported ? I'm not sure how you build your own bundle but >>> there's usually a way to provide the Import-Package at build time - but >>> if it is cumbersome to do for some reasons then indeed, just have a >>> custom provider extending the cxf one and doing nothing else but >>> indirectly ensuring Import-Package contains the right value...Otherwise >>> i won't work, given that DOSGi uses the bundle activator of the custom >>> bundle to load the providers. That said, I'll update the CXF JAXRS >>> handler to try the dswContext (which is CXF aware) when the loading >>> exception occur... >> >> >> I investigated further. If I use the following properties in my DS >> component: >> >> <property name="service.exported.interfaces" type="String" value="*"/> >> <property name="service.exported.configs" type="String" >> value="org.apache.cxf.rs"/> >> <property name="service.exported.intents" type="String" value="HTTP"/> >> <property name="org.apache.cxf.rs.address" type="String" >> value="http://localhost:8081/verzeichnis/"/> >> <property name="org.apache.cxf.rs.databinding" type="String" >> value="jaxb"/> >> >> there are no exceptions (but also no JSON support). >> >> S.B> : It is either "org.apache.cxf.rs.databinding" or >> "org.apache.cxf.rs.provider", otherwise what to do if the former declares >> jaxb and the latter declares some other XML aware provider ? Also there's >> no need to specify JAXBElementProvider (JAXB is supported OTB), only of >> you need to configure it somehow... >> >> Using the following properties >> >> <property name="service.exported.interfaces" type="String" value="*"/> >> <property name="service.exported.configs" type="String" >> value="org.apache.cxf.rs"/> >> <property name="service.exported.intents" type="String" value="HTTP"/> >> <property name="org.apache.cxf.rs.address" type="String" >> value="http://localhost:8081/verzeichnis/"/> >> <property name="org.apache.cxf.rs.provider" type="String"> >> org.apache.cxf.jaxrs.provider.JAXBElementProvider >> org.apache.cxf.jaxrs.provider.JSONProvider >> </property> >> >> I get the CNFEs mentioned before. >> >>> S.B : please update Import-Package in your bundle >> >> Changing the "org.apache.cxf.rs.address" property to >> "org.apache.cxf.rs.httpservice.context" as you proposed before doesn't >> change anything too (but that seems just logically). >> >> The strange thing is that I only get those exceptions when the bundle >> starts up. The applications runs fine nevertheless and when I do HTTP >> requests there are no more exceptions. >> >>> except that LinkageError ? >> >> cheers, Sergey >> >> Is this maybe a fallback to the default "jaxb" that could lead to this >> behaviour? >> >> cheers, >> Daniel >> >> >> >> Am 05.02.2010 um 14:45 schrieb Sergey Beryozkin: >> >>> I'm wondering, is the problem here to do with the fact that DOSGI is >>> trying to use the BundelContext/Bundle of the application bundle to load >>> the providers ? It should work if the providers's code is indeed inside >>> a given app bundle but looks like it causes issues if the provider's >>> code is actually located elsewhere. >>> >>> That said, if you own bundle imports the org.apache.cxf.jaxrs.provider.* >>> then surely the OSGI loader has to be capable to find the classes >>> available elsewhere in the container, especially given that CXF minimal >>> bundle is exporting org.apache.cxf.jaxrs.provider ? >>> >>> Can you please check that your own bundle Import-Packag(es) the >>> org.apache.cxf.jaxrs.provider.* ? >>> >>> thanks, Sergey >>> >>> ----- Original Message ----- From: "Daniel Bimschas" >>> <[email protected]> >>> To: <[email protected]> >>> Sent: Friday, February 05, 2010 1:34 PM >>> Subject: Re: DOSGi and JSON responses >>> >>> >>> Maybe the full debugging output including stack trace can help more: >>> >>> INFO: Creating a >>> de.uniluebeck.itm.soapraktikum.ws0910.persons.vz.rest.PersonResource >>> endpoint from CXF PublishHook, address is >>> http://localhost:8081/verzeichnis/ >>> java.lang.ClassNotFoundException: >>> org.apache.cxf.jaxrs.provider.JAXBElementProvider >>> 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:250) >>> at >>> org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:604) >>> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1487) >>> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:897) >>> at >>> org.apache.cxf.dosgi.dsw.handlers.JaxRSUtils.loadProviders(JaxRSUtils.java:112) >>> at >>> org.apache.cxf.dosgi.dsw.handlers.JaxRSUtils.getProviders(JaxRSUtils.java:67) >>> at >>> org.apache.cxf.dosgi.dsw.handlers.JaxRSPojoConfigurationTypeHandler.createServer(JaxRSPojoConfigurationTypeHandler.java:119) >>> at >>> org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86) >>> at >>> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.java:106) >>> at >>> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:80) >>> at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164) >>> 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) >>> 05.02.2010 14:32:16 org.apache.cxf.dosgi.dsw.handlers.JaxRSUtils >>> loadProviders >>> WARNUNG: JAXRS Provider >>> org.apache.cxf.jaxrs.provider.JAXBElementProvider can not be loaded or >>> created >>> java.lang.ClassNotFoundException: >>> org.apache.cxf.jaxrs.provider.JSONProvider >>> 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:250) >>> at >>> org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:604) >>> at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1487) >>> at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:897) >>> at >>> org.apache.cxf.dosgi.dsw.handlers.JaxRSUtils.loadProviders(JaxRSUtils.java:112) >>> at >>> org.apache.cxf.dosgi.dsw.handlers.JaxRSUtils.getProviders(JaxRSUtils.java:67) >>> at >>> org.apache.cxf.dosgi.dsw.handlers.JaxRSPojoConfigurationTypeHandler.createServer(JaxRSPojoConfigurationTypeHandler.java:119) >>> at >>> org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86) >>> at >>> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.java:106) >>> at >>> org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:80) >>> at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164) >>> 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) >>> 05.02.2010 14:32:16 org.apache.cxf.dosgi.dsw.handlers.JaxRSUtils >>> loadProviders >>> >>> >>> Am 05.02.2010 um 14:22 schrieb Daniel Bimschas: >>> >>>> It's Felix over Pax Runner in my case. If I take the >>>> "sun.*,com.sun.*,javax.xml.bind,javax.xml.bind.*" packages out of the >>>> bootdelegation classpath the following errors will occur: >>>> >>>> java.lang.ClassNotFoundException: >>>> org.apache.cxf.jaxrs.provider.JAXBElementProvider >>>> java.lang.ClassNotFoundException: >>>> org.apache.cxf.jaxrs.provider.JSONProvider >>>> >>>> For me, currently that doesn't make sense since the DOSGI bundle is >>>> fully resolved and all classes should be loadable. I'll further >>>> investigate this... >>>> >>>> Am 05.02.2010 um 13:29 schrieb Sergey Beryozkin: >>>> >>>>>> S.B : Is it a single bundle distro ? Yes, it ships the stax api >>>>>> bundle I think...Hmm...Will it work if you try the multibundle distro >>>>>> and omit the stax-api bundle ? Or perhaps updating the Equinox config >>>>>> to block the stax api from the system ? >>>> >>>> -- >>>> M.Sc. Daniel Bimschas >>>> Institute of Telematics, University of Lübeck >>>> http://www.itm.uni-luebeck.de/users/bimschas >>>> Ratzeburger Allee 160, 23538 Lübeck, Germany >>>> Phone: +49 451 500 5389 >>>> >>> >>> -- >>> M.Sc. Daniel Bimschas >>> Institute of Telematics, University of Lübeck >>> http://www.itm.uni-luebeck.de/users/bimschas >>> Ratzeburger Allee 160, 23538 Lübeck, Germany >>> Phone: +49 451 500 5389 >>> >>> >> >> -- >> M.Sc. Daniel Bimschas >> Institute of Telematics, University of Lübeck >> http://www.itm.uni-luebeck.de/users/bimschas >> Ratzeburger Allee 160, 23538 Lübeck, Germany >> Phone: +49 451 500 5389 >> >> > > -- > M.Sc. Daniel Bimschas > Institute of Telematics, University of Lübeck > http://www.itm.uni-luebeck.de/users/bimschas > Ratzeburger Allee 160, 23538 Lübeck, Germany > Phone: +49 451 500 5389 > > > > -- View this message in context: http://old.nabble.com/DOSGi-and-JSON-responses-tp27330507p27471408.html Sent from the cxf-user mailing list archive at Nabble.com.
