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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
