Hi,
I also can't understand is there anything which I can do to fix this issue
with empty json response. I am using DOSGi version 1.1 and Jettison 1.0.1
downloaded from the link given in this thread but the result is the same and
response is empty. The example which I try to run is simple get method which
returns Jaxb entity but method is annotated with
@Produces("application/json").
One more question from my side - What is the right way to make my own JSON
provider and to configure cxf to use it (if i am not in spring environment ,
what configuration files and where in the application project should be
added in order to work?) ?
Best regards,
Filip Yankov
Sergey Beryozkin-2 wrote:
>
> 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
>
>
>
>
--
View this message in context:
http://old.nabble.com/DOSGi-and-JSON-responses-tp27330507p28397549.html
Sent from the cxf-user mailing list archive at Nabble.com.
