Hi Noel,
Er - isn't this a bit of a rule change? We don't even have a container spec yet and already you want a micro edition? I thought you were proposing that JNDI be expected by the Mailet?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.
I agree that implementing a lightweight container would be made more difficult by requiring JNDI. I have not, however, seen any discussion of this requirement in the past. What is it that you envisage these lightweight containers would be used for? They would not be able to have user or mail repositories. How would you provide access to other processors without providing access to the spool?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.
So we back off from replacing getInitParameter(). Let me get back to basics here. My own business requirements (i.e. requirements for which I have a commercial user) are as follows:
1) Provide access to MailRepositories via a standard mechanism that is not subject to change in the next James release.
2) Provide the ability to pass of certain messages to another processor to be processed asynchronously.
3) Provide support for structured configuration.
4) Scale James to around 50 messages per second.
I believe that per-mailet Contexts are a great way of achieving 1 and 3. IMHO, not having to look up the name of your resource before you look up your resource would make things easier for the Mailet author. I don't believe that this needs to be any harder to implement than your basic JNDI support.
The hardest part of the whole thing is actually configuring the resources into JNDI at all. Speaking of which, I have looked at the org.apache.naming stuff. It certainly will make things easier for us to implement JNDI. We will still need to provide a way of initializing the contents of the tree. We may also want to provide a way of persisting the tree.
I believe that two better approaches to simplifying the implementation would be to:
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.
1) Pass "this" to the constructor of InitialMailetContext, or
2) Call Mailet.getInitialContext()
Neither of these are prone to error.
Option 1 need not involve a great burden on the container provider. It could simply do the following inside the constructor:
------------
public InititialMailetConstructor(Mailet mailet)
{
Context ctx = new IntialContext();
_mailetContext = ctx.lookup(getContextNameFor(mailet)); // All other methods delegate to _mailetContext
}
------------
Obviously, one would have to have some way of deriving the context name from the Mailet instance. This strikes me as being a simple implementation detail that need not be specified in the Mailet spec, although Mailet.getName() would make it all very clear.
Could this be any simpler?
ADK
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
