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 JNDI Mailet Configuration
Date Sat, 01 Feb 2003 11:05:55 GMT
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 = 

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?


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

View raw message