Here it is: https://issues.apache.org/jira/browse/DOSGI-58
cheers, Daniel Am 05.02.2010 um 16:37 schrieb Daniel Bimschas: > I'll open the issue! > > Am 05.02.2010 um 16:17 schrieb Sergey Beryozkin: > >> I see....Perhaps it could recognize that a conflict will occur and print a >> more meaningful exception message advising users to use a context property. >> If DOSGI will try to silently attach the endpoint to a paxweb-enabled >> HttpService then it might become complicated (paxweb may not be installed in >> case of multibindle distro) or a user might've used the explicit address >> exactly because a standalone jetty were expected to start, etc... >> >> Can you please open a JIRA in a DOSGI subproject so that we can track this >> issue and discuss how to fix it ? >> >> thanks, Sergey >> >> ----- Original Message ----- From: "Daniel Bimschas" >> <[email protected]> >> To: <[email protected]> >> Sent: Friday, February 05, 2010 3:07 PM >> Subject: Re: DOSGi and JSON responses >> >> >> Oh, I know of the org.osgi.service.http.port value that lets Pax Web start >> it's Jetty instance on 8080 per default. I tried to say that users of DOSGI >> (especially newbies) would certainly expect that using >> "org.apache.cxf.rs.address" would work nevertheless by simply using the same >> port (i.e. if there's no web context conflict). >> >> I guess that some DOSGI (or CXF) bundle which is responsible for registering >> the JAX-RS servlet to some Jetty instance could surely check if there's a >> servlet container instance running on the desired port and reusing that >> instance... >> >> Daniel >> >> Am 05.02.2010 um 15:56 schrieb Sergey Beryozkin: >> >>> Hi >>> >>> This can be easily fixed AFAIK, I can't recall the name of the paxweb >>> property but you can ensure its Httpservice occupies some other port...Just >>> checked in ServiceMix, it is >>> >>> org.osgi.service.http.port=8181, >>> >>> add it to felix/etc/config.properties. etc >>> >>> cheers, Sergey >>> >>> Sergey, >>> >>> I just stumbled over another issue that may annoy DOSGI users. If you start >>> the single bundle distribution (no idea if it's the same with multi bundle) >>> it starts a Jetty on localhost:8080 which should be usable like a OSGi >>> compendium HTTP service (that's what I understood at least). Now if one >>> uses the JAX-RS stuff and registers it's instance with the >>> "org.apache.cxf.rs.address" property he will have to choose a port other >>> than 8080 or he'll get the following exception: >>> >>> WARNUNG: WARNING : Problem creating a remote endpoint for >>> de.uniluebeck.itm.soapraktikum.ws0910.persons.vz.rest.PersonResource from >>> CXF PublishHook, reason is null >>> org.apache.cxf.service.factory.ServiceConstructionException >>> at >>> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:114) >>> at >>> org.apache.cxf.dosgi.dsw.handlers.JaxRSPojoConfigurationTypeHandler.createServer(JaxRSPojoConfigurationTypeHandler.java:129) >>> 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) >>> Caused by: org.apache.cxf.interceptor.Fault: Could not start Jetty server: >>> Address already in use >>> at >>> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:339) >>> at >>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.activate(JettyHTTPDestination.java:157) >>> at >>> org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48) >>> at >>> org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:164) >>> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:122) >>> at >>> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:105) >>> ... 8 more >>> Caused by: java.net.BindException: Address already in use >>> at sun.nio.ch.Net.bind(Native Method) >>> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119) >>> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) >>> at >>> org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:205) >>> at >>> org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:304) >>> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39) >>> at org.mortbay.jetty.Server.doStart(Server.java:233) >>> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39) >>> at >>> org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.addServant(JettyHTTPServerEngine.java:306) >>> ... 13 more >>> >>> I guess it should be possible to reuse the running Jetty instance and >>> deploy the instance to the standard OSGi HTTP service. At least that's what >>> a user would expect. What do you think about it? >>> >>> Kind regards, >>> 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 >> >> > > -- > 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
smime.p7s
Description: S/MIME cryptographic signature
