cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Tue, 28 Sep 2010 13:09:56 GMT
  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. 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?)

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss


Mime
View raw message