> 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*:
> because
> ComponentManager is in org.apache.avalon.frame
Danny,
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!
Let me understand though the following: you say:
> The classloaders created inherit the same loader used by the
> spoolmanager, and hence have access to
I agree that it'd be worth getting some independant verification, but I've been using
this for mailet deployment since it went into the HEAD with no problems
(Well ok, one problem but I fixed it ;-)
d.
> I'd like to see Marco, for example, test his Jamailet code
> with the new classloader (in
Danny,
Thanks. :-)
FWIW, the Wiki page was Steve Short's description of pre-classloader
changes, IIRC. I'd like to see Marco, for example, test his Jamailet code
with the new classloader (in latest/), and adjust his documentation to
reflect the new code.
--- Noel
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 als
