(Not so much Mailets v3 and James v3) I'd like to add improved JMX management capabilities, e.g to monitor spool queues via JMX.
> -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 27, 2002 5:55 AM > To: James Developers List > Subject: Re: Mailets v3 > > > 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: > <mailto:james-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
