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
It was "RT: ClassLoader Hierarchy" in the avalon list in November. Or just search for "CAPI"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?
I may have mislead, interface/impl separation in SAR-INF/lib was not dicussed, just the separation of comps.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
