Stephen,
Well, I don't think that we're quite agreeing, yet, but we'll get there.
:-)
Personally, I think you are too focused on static assembly, and how things
are done in the code today.
For one thing, I would be perfectly happy to discard backward compatibility
to get a clean, forward-reaching, stable solution. I'll change the code in
James if we get value from it. Heck, we've had to change it enough times
already tracking changes to the interfaces. What's one more if it finally
gets us to a non-fragile interface? We're not talking about everything;
we're talking about a couple of very important areas that appear to need it.
So why not start clean, and see what comes out?
Hypothesize that a component sees a single Context. From that Context, it
can request other objects. OK, how do they get there? Well, I would argue
that there are two distinct issues:
1) Registration of top level context domains with the Context.
2) Registration of objects with context domains.
I maintain that those are two separate issues. The Context should only be
concerned with registration of context domains. I referred to them as top
level with the idea that in theory a JNDI context domain *could* in theory
have some further sub-domains, but that is it's problem, not the Context's.
Objects are registered with the context domain into which they go, not with
contexts. And although we would want to define a general common mechanism,
there might be others. For example, consider Chad Stansbury's comment that
someday he expects to retrieve JINI services via a Context. We wouldn't do
ANY assembly within the domain! The only thing that you can and should know
is to associate that context domain with the Context. The context domain
will have to take care of itself. In point of fact, the contents of that
domain would change over time.
On the other hand, for the standard context domains that are defined by the
container profiles, we will probably have a more typical model. I might
register a factory for a given implementation class, and associate that with
a namespace specific key in a specified domain. Perhaps something like:
<context-domain name="ns" factory="cdf">
<contents>
<object name="config-name" key="ns-key" />
</contents>
</context-domain>
<object name="config-name" factory="ojbf" >
<dependencies>
<object uri="URI" />
</dependencies>
</object>
That is off-the-cuff, and intended only to convey a specific concept. The
first element declares a domain with some contents, the second one defines
an object that happens to have some dependencies. The domain is responsible
for dealing with its own child elements. In this case, there is a block
telling it about some objects to populate itself with. The domain is also
free to declare other objects on its own. The object is saying that it has
dependencies that it would like enforced by the container. Note that
although we can use a namespace specific key within the context-domain
definition, we use the full URI when defining a dependency because the
contract is that only a domain knows about its contents.
Earlier, I said that perhaps you are too focused on static assembly. You
can return the favor by pointing out that I am ignoring some issues.
Possibly so (especially at 4AM :-)). But hopefully everyone learns through
the process, and we arrive at something mutually satisfactory.
As principles, I'd like to suggest that things be kept simple, clean, and
flexible. Nothing more complex than it needs to be, and complexity is
layered and optional.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
