james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Knauf <akn...@xtra.co.nz>
Subject Re: JNDI Mailet Configuration
Date Sun, 02 Feb 2003 08:48:18 GMT
Hi Noel,

>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.
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?

>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.
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?

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.

>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.
I believe that two better approaches to simplifying the implementation 
would be to:
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?


To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message