> 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.
No, I think that it should be a part of the Mailet Specification, in order
to promote portable matchers and mailets. Just expressed as optional for a
container implementation, to cover the lightweight scenario.
> 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.
Please look at tomcat configuration. Probably the server.xml approach,
rather than what is in web.xml. We can pass a reference to a
"conf/jndi.xml" file to a JNDIService from config.xml.
<JNDIService enabled="true" configuration="file://conf/jndi.xml" />
4) Add MailRepositories to JNDI for use by James Mailets.
Leave this one alone for now. There are remaining nuances to be worked out.
We've got a good handle on resources, so let's start with resources, and get
to users and repositories after we have had time to work on those issues
further.
> this generic approach to putting values into JNDI as system startup is
> something that is valueable beyond the scope of James.
Considering that we're copying it from J2EE, that should not be surprising.
> I also intend to make is possible to approximate per-Mailet Contexts
Please do not do it as you've proposed. As I suggested earlier, there are
more appropriate ways to do this than what you are proposing. The
classloader is the key. This is vital not only because of the previously
discussed implications for JNDI, but because it is necessary if we want to
impose Java Security on matchers and mailets. If we decide that we need
separate (security) contexts for matchers and mailets, we will need to
define them using classloaders anyway. If we want dynamically (re-)loadable
processors, we will need classloaders. If/when we want to segment mailet
applications, we will have to use classloaders to implement the segmentation
on whatever boundaries we define.
> 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.)
The JNDIService will be, and should be, an Avalon component. Internally,
you can wrap a more generic class.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
