Danny,
There are two phoenix apps of precident to maillet & James. The first is Jesktop (18 months old now). The second is EOB. The reason I cite them as similar, is that they have the concept of hosted components against an API. They are the same in that respect, but differ in one - Jesktop allows hot installation of its hosted comps, EOB does not (they have to be in situ at Phoenix boot). Jesktop apps compile against swing (JCompoent) plus option jesktop api. EOB comps compile against Avalon Framework interfaces, but may assume they can use any excalibur comp available in pheonix's lib dir (to possibly change later).
Advice....
1) First of all you should separate interface and impl of maillets. 2) The maillet developer should compile completely outside a JAMES/phoenix distribution. The maillet-api.jar should be in that developer's lib directory. The maillet should be (if not already) zipped into a jar file with a special manifest JAMES-INF/maillets.xml
3) James should dynamically load maillet jars from a directory within the sar file
4) James should also dynamically load maillet jars via a service api (for other Phoenix blocks)
5) James should mount each mailet jar in a separate classloader (see Jesktop and EOB). The parent of the classloader should be the system classloader (which has all the J2SE packages in it plus the those in phoenix/lib. The impl of James is hidden from the maillet.
Now we've had one drawn out conversation on the subject of hosted components over the last year. Go to google and search for K/HC/CAPI and K/CAPI/HC for an overview of one of our quandries.
Now, in answer o your original question, classpath as a concept does not apply to a kernel hosting classloader-separated servers (each sar in a diff classloader). Even more so when those hosted servers host their own comps.
It's a big task, but you'll be really pleased you did it. You can copy as much code as you like from Jesktop and EOB as they are both Apache licensed ( jesktopimpl.sourceforge.net & eob.sourceforge.net )
Regards,
- Paul
Guys, I hate classpath issues, and don't have much of a clue about classloaders.. so bear with me if I seem slightly at odds with this..
Where can I put jar files, outside of the sar file, and have their contents picked up by the classloader for this context? The reason I want to do this is as follows..
I'd like to have a James distribution which is organised to make life easy for mailet developers, but if the SAR-INF/lib contents are not accessible except when its running, and even then the work directory name is not predictable, they will need another "visible" copy of the mailet api to compile against. I'd rather put the Mailet API jar file elsewhere to start with than distribute two copies.
Next, once some geezer has written his mailets he wants to drop class files or a jar containing his package into james for testing.
Perhaps for IP reasons, or because they are destined for some other application tarring them into James is not an option.
I dont know if there's some way I can configure the James classpath (cf the phoenix one), I've tried meddling to no avail.
Feel free to talk down to me, as long as it gets me my answer ;-) d.
PS I've tried putting jars into $PHOENIX_HOME/lib but get this exception:
java.lang.NoClassDefFoundError: org/apache/mailet/MailetContext at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:509) at java.security.SecureClassLoader.defineClass(SecureClassLoader.jav 3) at java.net.URLClassLoader.defineClass(URLClassLoader.java:246) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at org.apache.avalon.phoenix.components.classloader.PolicyClassLoade ndClass(PolicyClassLoader.java:98) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:262) at org.apache.avalon.phoenix.tools.verifier.SarVerifier.verifyBlockT SarVerifier.java:352) at org.apache.avalon.phoenix.tools.verifier.SarVerifier.verifyBlocks (SarVerifier.java:335) at org.apache.avalon.phoenix.tools.verifier.SarVerifier.verifySar(Sa ifier.java:124) at org.apache.avalon.phoenix.components.deployer.DefaultDeployer.dep DefaultDeployer.java:281) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep ile(DefaultEmbeddor.java:486) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep ile(DefaultEmbeddor.java:479) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep iles(DefaultEmbeddor.java:467) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep efaultApplications(DefaultEmbeddor.java:457) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.exe (DefaultEmbeddor.java:220) at org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:151) at org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:
at org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:91) at org.apache.avalon.phoenix.launcher.Main.main(Main.java:44)
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
