cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Bimschas <bimsc...@itm.uni-luebeck.de>
Subject Re: DOSGi and JSON responses
Date Fri, 05 Feb 2010 17:40:43 GMT
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" <bimschas@itm.uni-luebeck.de>
>> To: <users@cxf.apache.org>
>> 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" <bimschas@itm.uni-luebeck.de>
>>>> To: <users@cxf.apache.org>
>>>> 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


Mime
View raw message