Re: JNDI Mailet Configuration

[Aaron Knauf]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]