cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DOSGI-58) Better handling for port conflicts when using property org.apache.cxf.rs.address
Date Mon, 22 Oct 2012 11:14:12 GMT

    [ https://issues.apache.org/jira/browse/DOSGI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481302#comment-13481302
] 

Sergey Beryozkin commented on DOSGI-58:
---------------------------------------

+1
                
> 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
>            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" <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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message