Aaron,
> > I think you are getting just a bit carried away.
> I disagree.
It was said with a smile. :-) I'm perfectly willing to follow this through
with you, but I don't believe that it makes sense to use JNDI as the
mechanism for getting all parameters.
The issue, Aaron, is whether or not it is acceptable to require JNDI for all
Mailet containers. Sell that point, and we can discuss the rest of this
message. Until then, it is a moot point.
One of the goals is to allow lightweight mailet containers. In my opinion,
your proposal could effectively preclude them by requiring JNDI. My
proposal only precludes lightweight containers from hosting matchers and
mailets that require JNDI.
Most matchers and mailets do not need anything more than the simple
getInitParameter method. By requiring JNDI, your proposal adds a major
complication to the mailet container. Then it further compounds the JNDI
complication by asserting that each matcher and mailet would have its own
unique JNDI context.
There extra burden on the matcher / mailet author is relatively minor for
the basic job of retrieving parameters (your examples don't show exception
handling, for example). The load on the admin is proportional to the actual
configuration. The primary burden is on the container author and also in
deployment overhead. But while I agree with you that the container author
should bear the greater burden, I don't believe that requiring JNDI for all
mailet containers is justified.
Can it be done? Certainly. Since you seem interested in exploring how,
I'll lay out one of the possible mechanisms.
One issue is what you do when an object calls new InitialContext(). To
implement the proposed model, the context factory has to know which matcher
/ mailet instance is making the call, and associate it with a JNDI context
that supports the unique entries for that matcher / mailet, as well as any
shared entries.
In my opinion, the "proper" (using the term loosely) way would be to do
something where the caller provided its identity through the
InitialContext(Hashtable environment) constructor. Calling the null
constructor would give you an initial context lacking any parameters. I'm
certain that will cause more than a few pilot errors, but it considerably
simplifies the implementation.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
