avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Classpath question
Date Fri, 31 May 2002 20:04:03 GMT

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).


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 )


- Paul

>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 ;-)
>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
>        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
>        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
>        at org.apache.avalon.phoenix.tools.verifier.SarVerifier.verifyBlocks
>        at org.apache.avalon.phoenix.tools.verifier.SarVerifier.verifySar(Sa
>        at org.apache.avalon.phoenix.components.deployer.DefaultDeployer.dep
>        at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep
>        at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep
>        at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep
>        at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.dep
>        at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.exe
>        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
>        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA
>        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:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message