Peter,
More on this topic. With EOB I am mounting beans in the machine and
completely separating them re classloaders. For each of those
classloaders I am making the parent the primordial, so they cannot see
anything from the underlying EOB server. It works well.
In the same SAR file I am trying to mount Jo!. Jo! names a number of
things in its SAR-INF/lib dir including the servlet API. Given that
Phoenix has also put AltRMI jars in there for EOB's use, Jo! Servlets
have classloader visibility of the AltRMI classes in SAR-INF/lib whci
overrides the same jars that I have put in WEB-INF/lib. It barfs at
runtime invocation of the servlet because of this contradiction (and
deserialization of AltRMI classes by AltRMI).
Now I have three choices
1) Remove AltRMI from SAR-INF/lib and dynamicly create a classloader for
it's use in EOB
2) Have phoenix differentiate betwen classes/jars that are interface and
impl
3) Keep Jo in a separate SAR and use JMX to publish the WAR file, via
Jo!s service API.
I think (2) though simply desirable, raises loads of issues. It would
allow Hendrik to place Jo-service and servlet.jar at interface level,
and name that as the parent classloader to the his custom
ServletClassLoader (remember servlet spec).
There is related issue. We consider EOB's six blocks as one app and
Jo!'s one block as another app. We tape them together in one SAR file
to make a super-app. The design is great and it allowed me to implent
(nearly) WebApp capability in a matterof hours. However, Phoenix just
consideres them blocks and as compeltely equal. The intellectual
grouping we afford them has not equivalence for Phoenix. Perhaps we may
mull a concept of "block-group" Where we could separate Jo and EOB (or
other) a little inside the machine. SoC applied to classloaders perhaps?
Consider this tree:
Webapps * Beans *
--------- -------------
Jo-Impl jar EOB-impl, AltRMI jars
(Jo block grp) (EOB block group)
-----------------------------
SAR1, Jo & EOB interfaces Pheonix Impl
----------------------
Phoenix interfaces etc
Primordial
* both the webapps and the beans havespecial classloader considerations,
in that they hide much of the parent structure.
They are shown here slightly incorretly.
My proposition is to consider a new concept "block-group". I would hope
in assembly.xml we could have an attribute for it in each <block> :
<block class="org.enterpriseobjectbroker.core.DefaultBeanRepository"
name="beanrepository" group="eob-group"/>
And it's own element:
<block-group name="eob-group"/>
Thoughts?
- Paul
I am wanting to separate my interface and impl for the sake of the
hosted beans. This is the K/CAPI/HC dicussion again.
Do you have a pointer to the mail where that was discussed?
It was "RT: ClassLoader Hierarchy" in the avalon list in November. Or
just search for "CAPI"
I may have mislead, interface/impl separation in SAR-INF/lib was not
dicussed, just the separation of comps.
