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/
