JNDI Mailet Configuration

[Aaron Knauf]

The more that I think about the idea of configuration via JNDI, the more I like the idea. Only, I am not so sure that my thinking is going in the same direction as that of others. Noel mentioned that the Mailet API tends toward a pull model, rather than the push model advocated by IOC converts. My current thinking is closer to IOC than to pull, but not entirely the same. I'll lay it out here for people to think about.

Essentially this email is intended to straighten out the fairly random thoughts that were represented in my previous config-related post.

Essentially, this idea is based around the concept that the Mailet will document the resources that it needs and the names under which it expects to find them. It is then up to the container to provide the specified resources under the specified names. It is assumed that a given Mailet container implementation will provide administrators with a mechanism for setting up the required resources under the names specified by the mailet. What manner of resources the container can be expected to provide is not addressed here. (In fact, the container need not provide all of the requierd resources at all, if they can be added to the jndi context through some other mechanism.)

When a mailet wishes to obtain a resource, it would use code similar to the following:

------------------------------------------------------------------
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.sql.DataSource;
import java.util.List;

public void init() {
// The context returned here *is* our configuration.
Context myContext = new InitialContext();
// What is the name of our widget server?
String widgetServerName = (String)myContext.lookup("widgetServerName");

// Obtain a datasource for the widget sales database
DataSource salesDb = (DataSource)myContext.lookup("salesDb");

// Get a list of all of the addresses to send sales new sale notifications to
List addressList = (List)myContext.lookup("notifyees");

// Obtain a reference to a custom mail repository used by this mailet
MailRepository repository = (MailRepository)myContext.lookup("myRepository");
}
-------------------------------------------------------------------

The Context returned by new InitialContext() is specific to this Mailet. The resources obtained from this context are put there through some administrative means (such as editing config.xml). JNDI supports the concept of links, so there could be an aggregation, rather than a composition relationship between the Context and the resources. (e.g. Many mailets could reference the same datasource, under whatever name they chose, by simply putting a link to it in each of their contexts.)

It would be possible to provide our own InitialContext subclass, as is done with "javax.naming.directory.InitialDirContext", in order to provide more convenient accessors to configuration properties.

It strikes me that this system has enormous flexibility. IOC is there in spirit, as the mailet is handed all of its resources in the Context and cannot pull in anything that is not linked into its Context. Reconfiguration could be supported by use of "javax.naming.event". Links to Contexts from other JNDI trees (on remote servers) could easily be provided for access to (e.g.) EJB home objects. This could also be used by mailets that want access to avalon resources not provided through the mailet API, without polluting the API. (e.g. some other block, written by the mailet author.)
One thing I like about this is the huge scope that container implementers have for providing access to value-add features. The ability to pull an actual DataSource out of the context, rather than just a JDBC url is a good example. On the surface, this may seem like an invitation to sabotage mailet portability. I think that quite the opposite is true. Container vendors will alway try to differentiate themselves by adding useful features that aren't provided in the spec. This is true of every extension interface in Java. Any developer is constantly required to decide whether or not to sacrifice portability for convevience. This JNDI interface provided by this proposal reduces the impact of this sacrifice by specifying how these extended features should be provided and accessed. e.g. Looking up a DataSource in JNDI requires that the container provider actually makes DataSources available via JNDI. This is alot more portable than if the container provider were to implement some sort of proprietory mechanism for obtaining a DataSource, as it makes it easy and natural for other vendors to substitute their own implementation of the same feature with no code change required in the mailet.

Another good thing about this is the absence of any specification for how these things get in to JNDI. That allows container vendors to differentiate themselves in this area without affecting mailet portability.

What do you think?

ADK




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]