On Tue, 6 Nov 2001 20:32, Paul Hammant wrote:
> 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 above diagram holds for any container style API. In the specific instance
of the Phoenix container then it would be as you indicated.
> 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.
Sorta. It happens in implementations of most Container style APIs. So if we
had an immaginary Meeplet API. It would probably require a separate
ClassLoader for the actual Meeplet API (ie client API), another ClassLoader
for the Meeplet Container and separate ClassLoaders for every Meeplet
application. Now replace Meeplet with Servlet or Mailet or Block or whatever
and the above sentence should still make sense.
Now I am saying that the pattern *should* exist at multiple places in a
Phoenix ClassLoader tree - unfortunately it doesn't atm.
The reason is that we still use hierarchial ClassLoader. Any application
hosted in Phoenix uses something like
System <--- Phoenix API <--- .sar ClassLoader
Currently "Phoenix API" includes excalibur, phoenix-client, framework and
logkit and anything in ${phoenix.home}/lib. In the future the "Phoenix API"
will be reduced to framework + phoenix-client.
Now if I wanted to implement a Servlet engine then presumably the .sar
ClassLoader would be the "Servlet Container" ClassLoader for the
servlet engine. Currently it is not possible to specify the "Servlet API"
ClassLoader that just contains servlet.jar and is a parent of the
.sar/"Servlet Container" ClassLoader. However this is reqiuired by the
servlet spec.
> In places. But I really need to see a big picture tree with named nodes.
If only there was a web-enabled whiteboard that we could use ;)
> Sorry bro, but its kinda needed by my graphical mind.
I think best in pictures too ;)
This is what I would like to do if I was going to be creating a Mailet engine.
SC = System ClassLoader
PCA = Phoenix Client API (phoenix-client.jar, avalon-framework.jar and also
logkit and excalibur atm)
PK = Phoenix Kernel/Container implementation
MA = Mailet API
JA = Mailet Engine AKA James
MIA = Mailet Instances Application (set of mailets that form an application)
And heres the pretty picture
+ <--- PK
|
|
SC + <--- PCA + <--- + <--- JA
| |
| |
+ <--- MA + <--- +
|
|
+ <--- MIA
Now using the following categorization scheme
K = Container/Kernel
CAPI = Client API
HC = Hosted Component
If you look at the "Phoenix" container level then the above would breakdown as
K == PK
CAPI == PCA
HC == JA
If you look at the "Mailet" container level then
K == JA
CAPI == MA
HC == MIA
Does that make it easier to grok ? ;)
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
