I see two cases, managed and non-managed code. In the former, where
the source is a component, there would be one set of chains (no
distinction between inbound and outbound) attached to the source
component. For non-managed code, it would be pretty much the same
thing with the chains held in the proxy or CallableReference.
Apologies if this has been explained previously and is now common
knowledge (if so, could you point me at the explanation?).
We've always had concepts of managed vs. non-managed code. The
problem is the specs never made the distinction very well and
confused the two in places. One of the main goals of the recent spec
changes was to clarify this (hence the reintroduction of things like
ComponentContext). The code is now in the 1.0 spec module but Jeremy
also posted to the wiki on this. I'm not sure, though, if you are
referring to this.
So is the idea that each chain has interceptors (say, databinding and
security) that are used for both incoming and outgoing messages? Is
there going to be a way to indicate to an interceptor which way is in
effect?
I'm not following and probably missing something. I don't think this
is any different than what we have today. There would be forward and
callback chains associated with a Wire. If the interceptor needs to
know if the invocation is a forward or callback invocation, it would
be the job of the interceptor "builder" on the slave to provide it
with that information (or have the builder instantiate different
interceptors). There is a mail thread on interceptor builders from
last week which covers the format for serializing a portable wire
definition from master to slave. The idea is the definition would be
created on the master and sent to the slave where interceptor
builders would be responsible for creating interceptors according to
some extensible wire definition information.
And would there be a way to indicate the order in each
direction? Maybe making the chain a doubly-linked list?
Could you explain a little further? I think the chain is exactly how
we have it today except it is one as opposed to two chains for each
direction.
A --------------\
|-----------------C
B --------------/
I'm proposing we do the following:
A ---------------
C
B ---------------
In the approach connections would be:
1. Between components
2. From a transport to a component
3. From a component to a transport
4. From a transport to a transport
When you say transport, do you mean a composite reference and/or
service implementation for a given binding?
I think of transport as what a binding provides a "link" to (not a
composite reference or service since they may have multiple bindings).
Even with a single hop, a callback invocation handler at C would still
need to be able to choose between A and B depending on where the
forward call came from. How do you see it referring to the correspon-
ding wire when it needs to make the callback?
It would be retrieved from the context, basically how it is today. We
need to be careful here, though, about dealing with context cleanup
on threads.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
