avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: SAR-INF/lib - interface/impl separation.
Date Tue, 05 Feb 2002 07:41:49 GMT
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.




--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message