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. -- Cheers, Pete *------------------------------------------------------* | "Computers are useless. They can only give you | | answers." - Pablo Picasso | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
