On Jul 19, 2006, at 6:02 AM, Scott Kurz wrote:
Would you agree it would make sense for Tuscany to provide this
function
rather than the host env?
If this is the host env's job then it must get a notification every
time a
Composite boundary is crossed in the case of recursively nested
composites. True it may be easy enough for the host env to set up
CurrentCompositeContext for the outermost, deployable composite
(there's
likely a more correct term). But it seems simpler to consistently
have
Tuscany set up this context as a step in the invocation chain
rather than to
have the host to have to set up the context correctly for both
outer-level
and nested composites.
Or is there already such a notification mechanism for crossing
Composite
boundary in effect? (I apologize that I haven't studied the code
extensively to understand this; I'm mostly relying on learning via
running
samples and stepping through the debugger).
The host env is responsible for setting this up for unmanaged code
i.e. code that is running that is not managed by the Tuscany runtime.
By definition, the runtime can't do this (I'm classifying launcher a
host code not runtime code).
Once we have entered managed code then the runtime takes over. It is
responsible for creating the invocation chains and would handle the
context switch as appropriate - I was thinking this would be in the
code that supports Services exposed by a Composite; I don't think
it's there yet. It may well need to set the Thread context
ClassLoader at the same time.
All this switching makes me worried, especially when we have closely
coupled composites. Having to intercept every call to a component
implemented by a composite just to reset context that is never used
seems like a lot of overhead. In addition, references to services
obtained this way bypass all the context associated with a component
(for example, policy information defined on a reference). I would
like to see this API go away do that it cannot be used from within
managed code, with us finding a simpler solution for unmanaged code.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
