Noel, The impact is that the spool manager creates a new classloader for mailets and another for matchers which add SAR-INF/classes to the classpath and scan SAR-INF/lob for jars which are also added to the classpath. These loaders are used to load mailet & matcher classes, and therefore are also the classloaders used by those classes.
So.. two points to note: 1/ mailets and matchers don't share a common classloader, but do have a common classpath. I'm not sure if this is right, nor if it would ever be a problem. 2/ mailets and matchers can load dependant classes from jars in SAR-INF/lib not as stated on the wiki (which I'll change) if this isn't true it is a bug. .. and one heads up .. The classloaders created inherit the same loader used by the spoolmanager, and hence have access to all the same classes in the same loader as James does. This allows mailets to access the underlying Avalon services via the mailet context. This breaks the intended design for the v3 mailet context, which should be unable to be used to get details of the context implementation. However this classloader seperation is not applicable to v2, so the changes conform to James & mailet v2. But I would STRONGLY URGE mailet developers not to access the underlying avalon services directly where at all possible (or make this code easily maintainable) because this access WILL be restricted in future versions for security reasons. It is our stated intention that we will improve mailet deployment by supporting "mailet applications" which will run in an isolated classloader space, thereby preventing access from those mailets to James and other mailet applications running in the same James instance. Therfore in James v3 and Mailet v3 the only services available will be accessed via mechanisms explicitly provided by the mailet context. d. > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: 02 June 2003 03:39 > To: James-Dev Mailing List > Subject: Classloader code from HEAD to v2.2 > > > Danny, > > Could you elaborate on the impact of the change? What I have from your > original post is: > > > In a nutshell you can now put mailets and matchers and their > dependancies > > into ~/apps/james/SAR-INF/classes or in jars in > ~/apps/james/SAR-INF/lib. > > The Wiki page describing how to deploy custom matcher/mailet classes is at > http://nagoya.apache.org/wiki/apachewiki.cgi?James/CustomMailetPackages. > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
