[
https://issues.apache.org/jira/browse/DOSGI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-58.
--------------------------------------
Resolution: Won't Fix
Assignee: Christian Schneider
With recommendation to use the servlet transport.
> Better handling for port conflicts when using property
> org.apache.cxf.rs.address
> --------------------------------------------------------------------------------
>
> Key: DOSGI-58
> URL: https://issues.apache.org/jira/browse/DOSGI-58
> Project: CXF Distributed OSGi
> Issue Type: Improvement
> Components: REST
> Affects Versions: 1.1
> Reporter: Daniel Bimschas
> Assignee: Christian Schneider
> Priority: Minor
> Labels: configuration
>
> Below is an exception from the mailing list thread that describes the
> issue... (reverse order!)
> 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
