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
smime.p7s
Description: S/MIME cryptographic signature
