[
https://issues.apache.org/jira/browse/CXF-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777014#action_12777014
]
Andreas Benneke commented on CXF-1893:
--------------------------------------
Thanks Daniel for the feedback - I will look into it, but it might take a few
days/weeks.
> Endpoints end up at the wrong bus when initializing multiple busses in one
> thread
> ---------------------------------------------------------------------------------
>
> Key: CXF-1893
> URL: https://issues.apache.org/jira/browse/CXF-1893
> Project: CXF
> Issue Type: Bug
> Components: Bus, Core, JAX-WS Runtime
> Affects Versions: 2.1.3
> Reporter: Andreas Benneke
>
> We are using CXF on JBoss 4.2.3 and have an EAR with multiple WARs, each WAR
> having it's own cxf-bus and endpoint definition(s):
> <jaxws:endpoint
> id="endpointId"
> implementorClass="some.package.SomeClass"
> implementor="#theImplementorBean"
> wsdlLocation="service.wsdl"
> address="/service">
> <!-- NOTE: no bus="..." specified here! -->
> </jaxws:endpoint>
> Deploying this EAR in JBoss all endpoints end up on one single bus (the first
> one created) and all other busses are "empty".
> Looking into the code we found that the
> org.apache.cxf.jaxws.spring.EndpointDefinitionParser$SpringEndpointImpl
> resolves the bus (if none is injected so far) using
> BusFactory.getThreadDefaultBus(). This method however returns the first bus
> created on the current thread.
> As JBoss initializes the whole EAR in one thread the above situation occures.
> As a workaround/solution we added a bus="cxf" to all endpoints which avoids
> the resolution of the bus using the thread:
> <jaxws:endpoint
> bus="cxf" <!-- workaround -->
> id="endpointId"
> implementorClass="some.package.SomeClass"
> implementor="#TheImplementorBean"
> wsdlLocation="service.wsdl"
> address="/service">
> </jaxws:endpoint>
> We however think, that EndpointDefinitionParser$SpringEndpointImpl should try
> to resolve the bus using the current application context (by default name,
> type, whatever) and as a last fallback use the getThreadDefaultBus().
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
