avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: SAR-INF/lib - interface/impl separation.
Date Tue, 05 Feb 2002 09:48:09 GMT

Ahh you just gave me a way/idea on how to do something with ClassLoaders that 
should make it all doable. I don't have time to explain it all now but ...

I will make you a deal - you document the recent addition of 
<management-access-point/> and I will implement a solution for you (or at 
least try to do so) this weekend. Sound fair ?

I think I can have a complete solution for you 

On Tue, 5 Feb 2002 18:41, Paul Hammant wrote:
> 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.



| "Computers are useless. They can only give you       |
|            answers." - Pablo Picasso                 |

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>

View raw message