On Tue, 6 Nov 2001 11:30, Paul Hammant wrote:
> Peter
>
> I'll reply to other points more fully in the morning, but for now (given
> this paragraph is what I think is your central wish)...

;)

> >Essentially what I want to be able to do is to create a
> >servlet/mailet/whateverlet server that abides by all the rules but does
> > not need to resort to ugly classloader hacks to get working. Not sure -
> > may need more gestation time ;)
>
> 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



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.

That any clearer ? ;)

-- 
Cheers,

Pete

------------------------------------
The two secrets to success:
   1- Don't tell anyone everything.
------------------------------------

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to