cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Tue, 28 Sep 2010 20:30:44 GMT
On Tuesday 28 September 2010 9:09:56 am Alessio Soldano wrote:
>   Hi,
> On 09/28/2010 01:26 PM, Alessio Soldano wrote:
> >> similar to (1), but the storage could be pre-configured and shareable.
> > 
> > 2) Scenario two is a single JVM/classlaoder with multiple bus's.  This is
> > Yes. Btw this is more or less the scenario we're on right now, as we
> > could have this storage as a shared facility provided by CXF libraries
> > which can be seen by all apps using them.
> I've just done a quick (& dirty) try locally, making the
> uncorrelatedExchanges map in MAPCodec a static attribute of that class,
> so that the map is shared in the jvm. 

Uhg... Yuck.  But for testing, OK.  :-)

> That avoids the problem with the
> retrieval of the correlated exchange in the response endpoint, but
> reveals other issues (or at least generates some doubts/questions to me
> ;-)) once the exchange coming from the request message is installed in
> the response message.
> As previously mentioned, in my testcase, the response is received by a
> response endpoint; setting the exchange from the request in the response
> message overwrites the existing exchange and that seems to cause some of
> the endpoint server things to get lost (the invoker instance in the
> service/endpoint, the whole destination instance, ...). This makes me
> wonder whether completely swapping the exchange is the right approach or
> the MAPCodec there should instead ask the two exchanges to be somehow
> "merged" (having the Exchange class copy what is actually required to be
> copied - btw, is there a list of this?)

Hmm....  it probably needs to be the other way around.  Copy everything except 
a list of things that would cause issues.   The Bus is one, the 
BindingOperationInfo and related servicemodel things is another.  Good luck!  

Daniel Kulp

View raw message