Mailets v3

[Aaron Knauf <ak...@xtra.co.nz>]

It strikes me that perhaps I should add the following separately to the 
"JAMES SMTP API" thread.

The commercial projects in which I have direct involvement would find 
the following three features to be most useful:

* 
Standard (supported) access to mail repositories (in any form).
* 
Improved Mailet deployment.  Hot deployment is a nice-to have, but not 
essential. What is essential is for me to be able to build a simple 
deployment unit that is easily inserted into JAMES in a clear and 
defined manner.
* 
Improved Mailet configuration.  Pluggability of config sources, in 
particular.  I would like to be able to get my config from (variously) a 
RDBMS, an XML file, or the JAMES init params.

Cheers

ADK


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Mailets v3

[Serge Knystautas <se...@lokitech.com>]

Danny Angus wrote:
>>Improved Mailet deployment.  Hot deployment is a nice-to have, but not 
>>essential. What is essential is for me to be able to build a simple 
>>deployment unit that is easily inserted into JAMES in a clear and 
>>defined manner.
> 
> 
> +1 this too is on the agenda, I've been looking at new Phoenix classloader configuration classes, this gives us/you the opportunity to configure classloaders (in otherwords class paths & jars) fron an xml file. In theory we can use this both to build a default mailet classloader path, and allow "power users" the ability to alter this to include/exclude jars and paths.
> 
> 
> 
>>Improved Mailet configuration.  Pluggability of config sources, in 
>>particular.  I would like to be able to get my config from (variously) a 
>>RDBMS, an XML file, or the JAMES init params.
> 
> 
> again +1, there has been talk for *ages* about the desirability of "hot" reconfiguration of the spoolmanager.
> 
> I would like to allow processors to have their own configuration, in seperate files, and have these files discovered by james at runtime, much like tomcat discovering context configuration files. I would like to think that we could abstract this so that James would know how to look for processor configurations in different configuration loaders, but I'd be cautious about how popular this feature would actually be, particularly if the real problem is dynamic re-configuration, and is already addressed.
> 
> d.

Hot mailet deployment and configurability are two of my top agenda items 
for the next mailet version.  I actually wrote a decent part of the 
hot-deployment stuff months and months ago and can revisit when we agree 
how to do it.  How hot-deployment works is really dependent on 
configuration (if we do add support for different kinds of processors). 
  Both of these are largely James issues and only would slightly affect 
the mailet API (as I envisioned them).

-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Mailets v3

[Danny Angus <da...@apache.org>]

> Standard (supported) access to mail repositories (in any form).

+1 this is on the agenda

> Improved Mailet deployment.  Hot deployment is a nice-to have, but not 
> essential. What is essential is for me to be able to build a simple 
> deployment unit that is easily inserted into JAMES in a clear and 
> defined manner.

+1 this too is on the agenda, I've been looking at new Phoenix classloader configuration classes, this gives us/you the opportunity to configure classloaders (in otherwords class paths & jars) fron an xml file. In theory we can use this both to build a default mailet classloader path, and allow "power users" the ability to alter this to include/exclude jars and paths.


> Improved Mailet configuration.  Pluggability of config sources, in 
> particular.  I would like to be able to get my config from (variously) a 
> RDBMS, an XML file, or the JAMES init params.

again +1, there has been talk for *ages* about the desirability of "hot" reconfiguration of the spoolmanager.

I would like to allow processors to have their own configuration, in seperate files, and have these files discovered by james at runtime, much like tomcat discovering context configuration files. I would like to think that we could abstract this so that James would know how to look for processor configurations in different configuration loaders, but I'd be cautious about how popular this feature would actually be, particularly if the real problem is dynamic re-configuration, and is already addressed.

d.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>