The properties copying solution certainly has a hacky smell. And when invoking several partner in one interaction it's also not clear (at least to me) on which partner mex the correlation id should be propagated (same partner link? all?).
On 3/28/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 > > >
