> I have tested with 2.2 this new facility to deploy easily in > apps\james\SAR-INF\lib my mailets residing in my own jar: it works great!
Oh good :-) > Does it mean then that the following *mailet* code would not work in *v3*: <snip> > because > ComponentManager is in org.apache.avalon.framework.component, > DataSourceComponent is in org.apache.avalon.excalibur.datasource, > DataSourceSelector is in > org.apache.avalon.cornerstone.services.datasource Yes, exactly right. > and both UsersStore, UsersRepository and JamesUser are in > org.apache.james.services, then "in James"? These are refactored into Mailet v3 to overcome that problem. > Or it would be a valid code because such services come from > > getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER > ), then from the mailet context? No, that is the part that will *not* be accessable. To explain further, I've gone through all the mailets I could find and identified some references to code in James which is interfaces that are "on topic" to be included in Mailet. This action was precipitated by the identification (by myself and Peter Goldstein) of a number of "hidden" dependancies on Avalon, caused essentially by gaps in the Mailet API, that were undesirable because they made it effectively impossible to make all the existing James Mailets truly portable to other Mailet containers. There are others which introduce a dependance (direct or indirect) between effective mailets and Avalon, this is considered (by me at least) to break the design constraints for the Mailet API. In particular that the API shouldn't impose constraints on the nature of implementations, and should therfore aim to use nothing outside Mailet, J2SE and J2EE. There is an answer to some of this already in HEAD, in particular there is support for mail, spool and user repositories in Mailet v3 in Mailet and James' HEAD. The datasource selector is also replaced by a simple, temporary, fix, but is likely to be changed for a JNDI implementation at some stage before a release is ever made. > > Vincenzo > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
