Guillaume, Could you better describe what's expected for the handling of the ServiceMix correlation id?
I was under the assumption that a service that obtains the correlation id from a JBI mex should copy it onto all other mex within the scope of the operation. But now I'm wondering what happens for the case of a one-way invoke triggering a set of mex since one-way operation don't really have a scope beyond the initial message. Attaching a correlation id to the instance (via properties) doesn't seem to solve the general tracking issue since one might want to separately track independent interactions within the same process. alex On 3/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
The original need is to access a set of persistent properties for a given instance of a process and *controlled by the integration layer*. The use of the MEX has a place holder was just an idea. I guess if there is a place for a global set of properties for a given process instance, it would solve the need easily without going into all these problems. Passing user defined properties from a mex to another is another problem that may need another solution. On 3/29/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: > > Yeah, that's what I was going to reply but you've been quicker :) After > thinking of it a bit more I remembered that the instantiating mex is > mostly > null. I think the outstanding mex map wouldn't work either as you'd find > something only for request / response scenarios and not for async. > > On 3/28/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > > > On 3/28/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: > > > > > > So I guess it would make sense to have the engine copy the mex > > > properties > > > from myrole mex to partnerrole mex when it's invoking. Some sort of > > > property > > > propagation feature. The only place where this is possible is when the > > > partner role mex is created, right where the invocation is triggered > in > > > BpelRuntimeContextImpl.invoke(). Here you have the partner mex that is > > > being > > > created and also the my role mex that originated the exchange > > > (_instantiatingMessageExchange). So copying properties from the latter > > > to > > > the former wouldn't be so hard I guess. > > > > > > And then it would be easy in MessageExchangeContextImpl.invokePartner > () > > > to > > > get the properties from the partner mex and and set them on the jbi > mex. > > > > > > Makes sense? > > > > > > > > This isn't entirely clear to me. The mex that originated the exchange > > isn't necessarily the instantiating mex. That's what held me from > > commenting on this thread so far. Implementing the feature for the > > instantiating mex is interesting but doesn't cover the general case. > > > > To locate the mex you would have to look in the outstanding mex map and > > probably use the scope hierarchy to determine which is the eldest. I > think > > we would need to provide a new API method to the engine to enable this. > > > > alex > > > > > > > -- Cheers, Guillaume Nodet ------------------------ Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
