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 10:28:08 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 ...
:-))))) Just on this issue or our long (and currently avoided) 
discussion on K/CAPI/HC and seamless sharing of services (division over 
Remote/RemoteException) between sars.

>I will make you a deal - you document the recent addition of 
I like deals.....

... but don;t knwo what I am commiting to.  I'll check out CVS and see 
if I can see what you are talking of.

>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 
One that I will like...? Hmmm I suspect yes.  Don't get run over dude. 
 This could be like Fermat's last Theorum all over again.

- Paul

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

View raw message