Steve,
>Yes it's:
>
> java.lang.NoClassDefFoundError: javax/mail/internet/ParseException
>
>It can't work with mailet.jar in the phoenix/lib directory and
>mail_1_2.jar in the James SAR because this means that mailet.jar is
>loaded by the extenation ClassLoader and mail_1_2.jar is loaded by the
>Phoenix PolicyClassLoader. Since the PolicyClassLoader is higher in the
>delegation chain, mailet.jar cannot load any javax.mail.* classes.
>
Actaually, given that it is NoClassDefFoundError (and not
ClassNotFoundException) , it is dependancy of java/mail that cannot be
found, not the mailet jar itself. I'd say that is the activaton jar and
some shitty use of Class.ForName(..) on Sun's part.
For the record both of my containers publish a mailet.jar-like server to
their hosted components without requiring any mokying with Phoenix's lib
directory.
>I've since read Peter's mail which says he added the mailet classes into
>james.jar file and this approach also works, but only if the mailet.jar
>file does not also exist in the phoenix/lib. The current build.xml file
>builds a separate mailet.jar file and then copies it into ${dist}/lib,
>i.e. the target phoenix/lib dir.
>
>
As I say, this should not be necessary.
As long as we use ..
this.getClass().getClassLoader().loadClass(..)
.. instead of ...
Class.forName(..)
.. we should be fine (five occurences by the looks of things).
When we shift to hot installable mailets, you'll have a seperate
classloader per mailet archive (the norm for these things). Then you'll
do ..
mailetArchive.getClassLoader().loadClass(..)
.. or some such.
-ph
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
