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 03:27:45 GMT


Noel J. Bergman wrote:

>Aaron,
>
>I think you are getting just a bit carried away.
>
I disagree.  I am certainly taking your proposal somewhat further that 
you intended.  I believe that this direction leads to a simplification 
of the Mailet API and of the contract between the Mailet container and 
the Mailet.

>
>I am not proposing that we remove getInitParameter from the Mailet API.
>That is all that most matchers and mailets need, and it is easy to manage.
>I am proposing that resources, including more complex configuration files,
>would be accessed via JNDI.
>  
>
Why have two ways of doing something?   I think it is better for mailet 
authors to know that there is one place to go for all resources, than to 
go to one place for simple parameters and to anouther for more complex 
ones.  Using JNDI for both would (in simple cases) still be exactly the 
same amount of code for the Mailet author.  As I mentioned before, we 
could implement our own Context sub-interface to provide accessors that 
return strings.

e.g.
---------------------------
MailetContext myContext = new InitialMailetContext();
String myParam = myContext.getAttribute("myParam");
--------------------------

How is this any more complex than getInitParameter?

>  
>
>>The Context returned by new InitialContext() is specific to this Mailet.
>>    
>>
>
>You might want to rethink this notion.  That is a lot of work for the
>container, and is not the way that the Servlet API works, which is
>per-webapp.
>

James has no equivalent to the Webapp concept.  There is no mechanism 
for the grouping of Mailets into "mailapps".  (In fact, I am not really 
sure that it would even make sense.)  If there were, then a per mailapp 
Context would certainly be a better granularity that per Mailet. 
 However, each Mailet is currently a distinct unit, with distinct 
resource requirements.

See my ToRepository example.  Even for as simple a case as that, JNDI is 
simpler for the mailet author.  This simplicity is primarily provided by 
per-mailet contexts.

There seems to be some perception that per Mailet Contexts are complex 
and difficult.  This is certainly not true from the Mailet author's 
perspective.  While there is some complexity involved from the container 
authors perspective, this is exactly the point of having containers at 
all - get someone to do the hard bits for you!  The complexity involved 
in per-mailet contexts is certainly no worse than any number of other 
problems encountered by appserver authors.  In fact most existing 
appservers already provide JNDI facilities - providing per-mailet 
contexts would be only a small step.

If worst comes to worst, and per mailet contexts prove impossible from 
off the InitialContext constructor, then "Mailet::getContext() : 
Context" is extremely simple to implement.  As is "new 
InitialMailetContext(this)".

As for  the complexity of actually getting the right stuff into the 
Context - achieving simple parameters is no more difficult this way than 
it is now.  Putting links to other resources in the context is no more 
difficult than providing references any other way.  Anything that should 
be provided globally would have a well-known name that would be 
implicity bound.  Anything that should not be provided globally would 
have to be configured somehow anyway.

There seems to be some resistence to this idea, but I cannot see why.  I 
have heard two objections so far:
1 - Servlets don't do it.
2 - It sounds difficult.

These are somewhat non-specific.  I have tried to address both of these. 
 Does anyone actually think that this would be detrimental to the 
container design, or to the mailet concept in any way?

Cheers

ADK


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


Mime
View raw message