On Nov 22, 2007 8:53 PM, Tim Stephenson <[EMAIL PROTECTED]> wrote: > Thanks for so many quick replies. I will take a look at JSieve though > since I know Rhino I must confess that sounds quite attractive. > > From your comments I gathered a next generation API might on the cards > and also that a change to support multiple matchers (other than a > JSieve / Rhino option) might get quite extensive. So I should probably > say I have been considering writing a semi-clean-room mailet > container.
cool :-) the mailet API has been factored out into a separate sub-project to allow it to develop independently. as danny mentioned, there a separate list so that independent implementors can discuss the API without the JAMES server noise. it's a good time to get involved since IMHO the consensus is that the existing API is in need of a major overhall. > I had in mind these requirements: > > 1. support all existing matchers and mailets unchanged (if possible) > 2. use Spring for dependency injection but limit Spring coupling to the loader > class FYI JAMES (though still dependent on avalon) now has spring support. better support for IoC containers (whether spring or pico) is a priority for the improved API. hopefully you'll be able to provide feed back. > 3. Mail will be injected into the mailet container via a JMS Listener > and should run in: > a) stand-alone apps > b) Message-driven ejb > c) web-application embedding we talked about this @ apacheEU and it's a very good idea. this is on my wish list for JAMES 3.0 :-) there are some interesting wrinkles (pipelining, JTA POJOs vs JMS 1.2). i'd be interested in talking this over. > 4. depend on nothing from James except mailet sdk (ok maybe this is > too far, but anyway I want to eliminate the avalon dependencies) the avalon dependency is interesting: it does so much (though spring is now heading in the same direction now which is why i prefer pico). the socket, logging and object pooling libraries in james are provided by avalon/excalibur. JAMES 3.0 has support for spring assembly (the components are wired and configured by spring) but the library dependencies are more difficult. JAMES needs to support newer libraries such as MINA so these dependencies will need to be sorted out. ATM the servers for the various functions (smtp etc) inherit from AbstractJamesServer which subclasses the avalon/excalibur socket framework. IMHO this should be factored differently. logging is an issue. the JAMES standard is logkit requires avalon. one possibility would be to switch to injection of the commons-logging interface instead. the pheonix container could then use AOP to add avalon specific interfaces. > do you have any comments / advice on if this is a good idea or would > be of any interest within James 3 (or whatever it will be known as)? > if i do go ahead it will only be the mailet container not the > fetchmail, smtp (or other) services which i'd like to be pluggable. i'm definitely interested in JMS/JPA-mailet integration we're always interested in more developers and ISTM that you're ideas are heading in the same direction as JAMES 3.0 pluggable functions and components is definitely where JAMES is heading. not all components need to be a part of JAMES server. independent libraries (such as jsieve or mime4j) and APIs (such as mailet) work better as independent sub-projects imported into JAMES server as library dependencies. JAMES uses IoC (whether spring or avalon) for assembly so these components can be assembled in various ways to form a JAMES server. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
