RE: IMAP2, Maildir, JNDI/LDAP progress update...

[Danny Angus <Da...@slc.co.uk>]

w.r.t JNDI
I spent the bankholiday w/e writing jndi context and classloader separation
for mailet "applications" and it kind-of works.

The basic design I've implemented puts stores and datasources into JNDI on
a per-James basis, much as we have now.
Mail Stores and User Stores are revealed through JNDI and exposed in the
Mailet API, rather than the more demanding task of binding and exposing
individual repositories based on URI's, cheap and cheerful. (I'm not using
naming from the directory project just now, but rolling my own so I
understand whats going on.)

The thing I'm working on right now is application separation, what I'm
attempting is to extract processor configurations into individual named
archives, optionally including classes,jars&resources.
These will be extracted at runtime and for each processor the spoolmanager
will create a delegating classloader containing the archived resources, and
also a local JNDI initial context, this initial context will contain
refrences to all the resources in the "real" intial context plus
potentially the mailet equivalent of "java:comp/env/"
A processor, mailet or matcher can then bind things to this context and
they will only be revealed to the mailets and matchers in that one
processor.

This relies upon processors being "pass through" at least optionally, and
preferably by default, so that processor applications can be invoked using
toProcessor and mail continue through the calling processor if it isn't
explicitly ghosted in the callee.

In this way it will be possible to deploy pre-configured functional units
by simply copying a jar to the deployment directory and adding a "to
processor" to a config.

Of course it means I'm likely to want to add mailepackages and
matcherpackages declarations to processor nodes, and probably a few others
as well.

The basic thrust of this message is to let you know that "mailet
applications", classloader separation and JNDI are looking achievable
fairly soon.





|---------+---------------------------->
|         |           "Noel J. Bergman"|
|         |           <noel@devtech.com|
|         |           >                |
|         |                            |
|         |           21/05/2004 08:57 |
|         |           PM               |
|         |           Please respond to|
|         |           "James Developers|
|         |           List"            |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------|
  |                                                                                                               |
  |       To:       "James Developers List" <se...@james.apache.org>                                         |
  |       cc:                                                                                                     |
  |       Subject:  RE: IMAP2, Maildir, JNDI/LDAP progress update...                                              |
  >---------------------------------------------------------------------------------------------------------------|




> I'm very leery of distracting a push to get IMAP implemented to
> another extended design thread.

As long as we can keep it isolated, sure.  I just want us to have the
flexiblity to look at our design decisions coherently down the road.

> > I would also like to see the system support better optimization [...]
> I think all this entails adding a move (or copy?) method to a mail
> store.  Where would you put this functionality?

Oh, I think it does need to be in the store.  Probably a public API, and
then some means for the store(s) to decide if it/they can do the
optimization.

             --- Noel


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






***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************


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