This is exactly what I meant. Sorry if this has not been very clear ;-)
The only problem was I have no idea where / how to store / retrieve this correlation id ... On 3/29/07, Alex Boisvert <[EMAIL PROTECTED]> wrote:
So how about this: -set the JBI correlation id on the instance when the engine receives a one-way message or a request (overwrite if already present) -copy JBI correlation id on all outgoing mex Does that meet your simple-problem-simple-solution criteria? (Maybe that's what you meant all along? :)) alex On 3/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > You're quite true when you imply that the actual ServiceMix > correlation id does not cover all the possible cases. > I'm quite sure that for rather complex scenarios, this > very limited feature will be unusable. > > The aim is to provide a basic feature that can provide meaningful > information in the most common cases. The idea is that all JBI exchanges > that are related together will have the same correlation id. This id is > usually > set by the first component sending the JBI exchange (usually a BC acting > as a consumer in the JBI meaning of the term). The most obvious > cases where this will fail is when a component aggregates several > unrelated > messages to produce another message (be it a bpel process or another > component). > > As there is no way to do that in a pure JBI way, ServiceMix relies on its > components to behave correctly and set the correlation id on related > exchanges. So, for simple components, everything will work > transparently and no additional code is required. But Ode is > a complex component ... > > As for a global tracking system, this will certainly fail at some point > as I said earlier, but things can always be improved ... For example > a JBI exchange could have a list of exchange ids that were directly used > to create an exchange (in case of an aggregation), so that we could > go up the chain of exchanges to the first one(s) ... > > So in short, this feature is a basic implementation that certainly does > not > cover all the possibles cases and thus requires a simple solution :-) > >
-- Cheers, Guillaume Nodet ------------------------ Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
