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, 26 Feb 2002 11:48:24 GMT
Peter,

<Cough/><cough/>.

Err, just realised that I have delivered on my side of this deal.... 
 This is created in  BlockInfoBuilder right?  I am example orientated 
Peter, could you point me to a working example of its use?  I have 
checked recent Cornerstone and Phoenix and can't see any....

- Paul

>Hi,
>
>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.
>>>
>




--
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