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
