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

JBert commented on DOSGI-110:
-----------------------------

I'll state it more clearly then: it's likely easier to fix DOSGi rather than 
refactoring CXF's use of Spring bean singletons. I therefore choose to alter 
DOSGi and give no support for binding a service as http://localhost/myservice 
when using ``org.apache.cxf.ws.httpservice.context``.

If I look at the code today, th CXF servlet blueprint is not used (DOSGi 
registers its own servlet on the HttpService). You also cannot bind to '/' as I 
think that would disable all other servlets on the HttpService.

So my proposal is to change DOSGi: it should bind a single servlet using a 
fixed (but configurable) alias (e.g. /dosgi) and then register all DOSGi 
services using the address they specified, relative to the servlet. This means 
that a user will need to look for his servlet at /dosgi/foo, but at least CXF 
won't throw exceptions.

Alternatively, the CXF blueprint descriptor could be used, but then we need to 
retrieve that servlet and bind DOSGi services to that.

At any rate, I believe that it's not worth to support binding services using 
their own servlet alias. If a user really wants to expose his service as 
/myservice, let them write their own servlet or specify 
``org.apache.cxf.ws.address`` to start a new HttpService.

This change shouldn't affect remote clients. They need to configure the full 
URI anyway.
                
> Unable to export multiple services
> ----------------------------------
>
>                 Key: DOSGI-110
>                 URL: https://issues.apache.org/jira/browse/DOSGI-110
>             Project: CXF Distributed OSGi
>          Issue Type: Bug
>    Affects Versions: 1.3
>         Environment: Karaf 2.2.5, DOSGi multi-bundle, CXF 2.5.2 from DOSGi 
> multi-bundle, Aries transaction manager
>            Reporter: JBert
>            Priority: Critical
>         Attachments: foobarservices.zip
>
>
> When I register more than one service, the second service will make the 
> following exception be printed to the console (this exception is nowhere 
> caught until it reaches the java.concurrent code):
> {quote}
> Exception in thread "pool-9-thread-4" java.lang.RuntimeException: Soap 1.1 
> endpoint already registered on address /
>         at 
> org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:862)
>         at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131)
>         at 
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:204)
>         at 
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:207)
>         at 
> org.apache.cxf.dosgi.dsw.handlers.HttpServiceConfigurationTypeHandler.createServer(HttpServiceConfigurationTypeHandler.java:173)
>         at 
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminCore.exportService(RemoteServiceAdminCore.java:247)
>         at 
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:72)
>         at 
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance$1.run(RemoteServiceAdminInstance.java:67)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at 
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:66)
>         at 
> org.apache.cxf.dosgi.dsw.service.RemoteServiceAdminInstance.exportService(RemoteServiceAdminInstance.java:38)
>         at 
> org.apache.cxf.dosgi.topologymanager.TopologyManager$2.run(TopologyManager.java:267)
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:679) 
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to