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 [email protected] http://dankulp.com/blog
