james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: JNDI Mailet Configuration
Date Sat, 01 Feb 2003 23:26:48 GMT

Aaron:

You have lost me - can you expand on something for me?

           Context myContext = new InitialContext();

How does a container control what is in the instance myContext?

Cheers, Steve.


Aaron Knauf wrote:

>
>
> Nicola Ken Barozzi wrote:
>
>>
>> This is not true IOC. The Mailet asks for something, it is not given it.
>> IOC in practice means that the container calls a method on the child. 
>> This is not the case here... 
>
>
> :-)
>
> From my previous post - "My current thinking is closer to IOC than to 
> pull, but not entirely the same."   ...   "IOC is there in spirit".
>
> The calling of a particular method on the child is an implementation 
> detail.  The salient point in my proposal is that the container is 
> still in control of what resources the Mailet has access to, because 
> it has to put them in the mailet's context.
>
> I agree that this is not true IOC, as defined by the Avalon designers, 
> however the major benefit (having the container maintain control of 
> resources used by the component) is still there - I just have a 
> different way of achieving it.
>
>>> 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. 
>>
>>
>>
>> Then this is not a configuration, but a ComponentManager. Avalon has 
>> separated the concepts, here they are intermixed.
>>
>> There is a place when this still happens which is the Context, but 
>> it's also the most controversial part of the Framework and the most 
>> unportable one. This is basically a Context as I see it.
>>
> Yes, this is basically a context.  I do not believe that this is a bad 
> thing.  We are specifying a contract between the Mailet and its 
> Container that says that the mailet container must place everything 
> that the mailet desires into the mailet's context.  (Kinda like your 
> own personal djinni!)  Essentially, the Context becomes a facade into 
> whatever mechanisms the underlying appserver wishes to use to provide 
> these resources.
>
> As mentioned in my previous post, I believe that this enhances 
> portability.  It does this in the following manner:
> 1)    It uses a standard API (JNDI) for access to resources.  It is 
> more reasonable to expect that an alternative mailet container will 
> provide JNDI, than it is to expect that the Avalon ComponentManager 
> interface will be provided.
> 2)    It provides a layer of indirection between the way that the 
> Mailet refers to a resource and the way that an appserver provides 
> it.  The container serves as the translator here.
>
> Here is an example of how the ToRepository mailet might differ if 
> written with this system
>
> ---------------  Current ToRepository mailet ----------------------
> public void init() {
>        repositoryPath = getInitParameter("repositoryPath");
>        try {
>            passThrough = new 
> Boolean(getInitParameter("passThrough")).booleanValue();
>        } catch (Exception e) {
>            // Ignore exception, default to false
>        }
>
>
>            try {
>                repository = 
> getMailetContext().getMailRepository(repositoryPath);
>            } catch (MessagingException e) {
>                log("Initialisation failed can't get repository 
> "+repositoryPath);
>            }
>
>
>    }
> ------------------------------------------------------------------------------ 
>
>
>
> ----------------- New ToRepository mailet -----------------------------
> public void init() {
>        try {
>            Context myContext = new InitialContext();
>            passThrough = 
> ((Boolean)myContext.lookup("passThrough")).booleanValue();
>            repository = myContext.lookup("repository");
>        } catch (NamingException ne) {
>            log("Initialisation failed");
>        }
>    }
> ------------------------------------------------------------------------------- 
>
>
>
> As you can see, there is now no need to supply the repository name as 
> an init param.  The mailet always refers to the repository by the same 
> name.  The name will always be unique because each instance of a 
> mailet has its own Context and therefore its own namespace.  If you 
> have multiple instances of the same mailet, the context for each 
> instance is configured separately.  The fully qualified name of the 
> context is, of course, different for each instance.
>
> In what way does this reduce portability?  This is certainly more 
> portable than using Avalon API's.  It is also completely 
> implementation agnostic.  The actual contents of the context may come 
> from an XML file, a database, or may be generated on the fly by the 
> container, or a combination of all of the above.
>
> Another advantage is that it is easier for new Mailet authors to 
> learn, because developers will often already be familiar with JNDI.
>
> I agree that this is a very different approach to that currently used 
> by Avalon.  Reproducing Avalon was not (and is not) the goal.  In fact 
> quite the opposite is true.  We want to keep Avalon out of the Mailet 
> API, but we still want to provide access to all of the useful 
> resources that Avalon provides.  (That is kinda the point of using an 
> appserver.) This proposal provides a portable facade into the 
> resources provided by any appserver.
>
> Cheers
>
> ADK
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




---------------------------------------------------------------------
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