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 Tue, 04 Feb 2003 07:42:26 GMT
Ok Folks,

After careful deliberation, I think it is fair to sum up the JNDI 
discussion as follows:
1)    Making JNDI integral to the Mailet container will not fly.  Noel 
correctly points out that lightweight container are made difficult 
(impossible?) by requiring JNDI support.  I can't really see the use of 
a lightweight container, but my perspective is somewhat narrow on this 
count, so I am willing to agree that someone else might find one useful. 
 :-)
2)    While I am convinced that per-mailet contexts are a great idea, 
no-one else seems to be.  This tells me that my approach here might be 
the silver bullet that I am looking for (;-p), but others won't find it 
generally useful - so I won't force it on anyone.
3)    Everyone seems to agree (or at least, not disagree) that JNDI is a 
good way for James to implement general resource sharing.  This is to be 
considered a James-specific implementation detail and provided to 
Mailets as extended functionality, rather than as part of the Mailet 
API/spec.

Here is what I think we should do about it:
1)    Implement a naming service provider as an Avalon 
block/service/whatever the correct term is.  The org.apache.naming 
package should serve as a base for this.
2)    Provide a configuration mechanism for initialising the JNDI tree 
with resources at system startup.  I am thinking that a generic XML 
configuration file for setting resources into JNDI could be used.  (This 
ought to be applicable beyond James.)  Haven't thought this through too 
far, but at a minimum we should be able to create Contexts, set 
primitive values for these attributes, provide pluggability for setting 
non-primitive values (such as DataSources, ThreadPools, or custom 
objects like complex user configurations.).
3)    Persistence of values written to JNDI programmatically can be 
deferred to a later phase.
4)    Add MailRepositories to JNDI for use by James Mailets.  Whether 
this is done via the pluggin mechanism, or whether this is done 
implicitly when James instantiates a mail repository is something we 
should decide.

The list of resources that James wants to make available via JNDI should 
be established by discussion.  Well-known names for these resources 
should also be established.

After discussion with a few of the guys at work, I think that this 
generic approach to putting values into JNDI as system startup is 
something that is valueable beyond the scope of James.  I intend to make 
this useable outside of James/Avalon.  Specifically, I want to use it 
from a startup class within Weblogic to provide resources to J2EE 
components.

I also intend to make is possible to approximate per-Mailet Contexts in 
the following manner:
1)    Provide the ability to configure a Context with links to the 
desired resources.
2)    Supply the name of this context to the Mailet via an init param.
3)    The Mailet then looks up the Context and uses it to get whatever 
resources you configured for it.

I don't see that any of my personal additions hurt the cause by being 
there.  They do, however, imply a commitment to keep the solution a 
little more generic than might otherwise be necessary.  (i.e. no 
James-specific or Avalon-specific stuff in the core 
loading/initialisation code.)

Does anyone have any objections, or further suggestions to this?

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