Re: [phoenix] RT: ClassLoader hierarchy

[Paul Hammant]

Peter,
For the sake of example - can we talk in terms of Jesktop (my bizarre
GUI app hoster).  Jesktop hosts GUI apps that need Swing, some
DesktopKernel access and some "Frimble" access for abstraction of
Windowlike containment.
What we are talking about is the following. Almost all container based 
systems define ClassLoader pattern using the following model

System ClassLoader <--- Client API ClassLoader <--- + --- Container
                                                   |
                                                   |
                                                   + --- Component1
                                                   |
                                                   |
                                                   + --- Component2
                                                   |
                                                   |
                                                   + --- Component3
                                                   |
                                                   |
                                                   + --- Component4

And in the context of my example, Container is Phoenix Impl & Excalibur 
etc,  Component 1,2,3,4 are Jesktop JAMES, DB & Ftpserver?

The diagram above is too simple for me Peter.  I think you hinting that 
this pattern exists many times in a tree.  At top level for Phoenix, and 
lower down for Phoenix App.

The client API contains the essential interfaces needed for the components to 
talk to the Container. In the case of servlets, servlet.jar would be in 
client API ClassLoader, catalina.jar in container classloader, and 
turbine.jar, cocoon.jar, velocity would each be in separate classloaders.

Phoenix itself follows above model. Eventually the client API will be made up 
of just the phoenix-client.jar and avalon-framework.jar libraries. The 
container is in separate ClassLoader from all the different .sar files.

It has been a while since I looked at jesktop but from what I recall the 
Client API ClassLoader would contain classes for Frimble, DesktopAware, 
ConfigletAware etc (or whatever they are called).

However the problem arises because Phoenix follows this model. Usually you 
use phoenix to build the "container" part of another application (be it 
James: the Mailet container, Jesktop the ...frimble???... container). Thus we 
need some way to inject the Client API ClassLoader for hosted apps into the 
equation so that it is a parent ClassLoader of the ClassLoader via which 
blocks are loaded.

Small point:  Jesktop's hosted client API is in in simplest form the who 
of Swing.  Some Jesktop apps require access to a Frimble Factory.

That any clearer ? ;)
In places.  But I really need to see a big picture tree with named nodes.
System Class Loader
Phoenix Client API (phoenix-client.jar and avalon-framework.jar) (PCA)
Phoenix Impl (PI)
Phoenix Hosted App Client API (PHA CAPI)
Phoenix Hosted App Impl (PHA I)
Phoenix Hosted App Hosted App (PHA A1, PHA A2 etc)
Sorry bro, but its kinda needed by my graphical mind.
Regards,
- Paul H
--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>