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
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"
<bimsc...@itm.uni-luebeck.de>
To: <us...@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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
