james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron.Kn...@vodafone.co.nz
Subject RE: JNDI Mailet Configuration
Date Tue, 04 Feb 2003 20:57:49 GMT

Hi Noel,

I don't have a problem with any of this.  I am, however, a little unclear
of your meaning on one point:

> I also intend to make is possible to approximate per-Mailet Contexts

[Noel]
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.


Do I take it that you are advocating that we go back to the idea that "new
InitialContext()" will provide a mailet-specific context?  (Well, actually
classloader-specific, by the sound.)  If so, I do not disagree.  However,
as a first step, treating JNDI as a single tree, to which all mailets have
access is easier than playing with classloaders - particularly because the
manner in which we use (and scope) classloaders is not yet fully defined.
(Unless Danny is further along with this than I realise?)  Basically, I am
saying that step one should be to get it working - step two can make it
fancy.

[Noel]
The JNDIService will be, and should be, an Avalon component.  Internally,
you can wrap a more generic class.

This is precisely my intent.  The reason I mentioned that generic aspect is
just to point out that it will be necessary to maintain that border.  It
might otherwise be tempting to abandon genericity for the convenience of
giving James/Avalon direct hooks into the JNDI code.  If that happens,
I'll be stuck re-writing those non-generic bits when I go to use the code
elsewhere.


Cheers

ADK

--------------------------------------------

There is no magic.


                                                                                         
                                       
                    "Noel J.                                                             
                                       
                    Bergman"             To:     "James Developers List" <james-dev@jakarta.apache.org>
                         
                    <noel@devtech.       cc:                                          
                                          
                    com>                 Subject:     RE: JNDI Mailet Configuration   
                                          
                                                                                         
                                       
                    05/02/2003                                                           
                                       
                    06:23                                                                
                                       
                    Please respond                                                       
                                       
                    to "James                                                            
                                       
                    Developers                                                           
                                       
                    List"                                                                
                                       
                                                                                         
                                       
                                                                                         
                                       




> 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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org






-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz

CAUTION: This correspondence is confidential and intended for the named recipient(s) only.
If you are not the named recipient and receive this correspondence in error, you must not
copy,
distribute or take any action in reliance on it and you should delete it from your system
and
notify the sender immediately.  Thank you.

Unless otherwise stated, any views or opinions expressed are solely those of the author and
do
not represent those of Vodafone New Zealand Limited.

Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962

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