Stephen, >>>>>>>> 1) Merlin includes phoenix-client.jar and provides alternate >>>>>>>> implemetations of the BlockContext interface. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Thats the only real solution at this stage. >>>>>>> >>>>>> >>>>>> >>>>>> There could be some reason why that is not possible. >>>>>> >>>>> >>>>> >>>>> It will become a lot more difficult in the future when classLoader and >>>>> interceptor stuff get integrated but it should be possible to >>>>> no-op those >>>>> features - not sure. >>>>> >>>> >>>> >>>> Well let's tackle future features in the future. For now though I >>>> think >>>> that useing a Phoenix jar to be Phoenix compatible is perfectly >>>> possible. >>>> >>> >>> >>> >>> I am not sure what you are saying. If you want to implement >>> BlockContext then that is fine but the implementation is inherently >>> container specific. The implementation should not even be in the >>> same classloader as the interface. >> >> > > The GenericBlockContext provides a solution for any Avalon container > to workaround the Phoenix BlockContext dependency issue. It deals > with the very situation you mention below - the inclusion of container > specific APIs - in this case a Phoenix specific APIs. > What GenericBlockContext does is to provide a mechanism for any > container to be able to deal with the legacy of Phoenix dependent > components that include references to the BlockContext interface. The > implementation solves the problem by allowing a container to handle > the association of keys and values using java.util.Map and the Context > class. Boyond this it has to implement the BlockContext interface in > order to solve the issue of Phoenix API exposure towards components. > Relative to a container, the GenericBlockContext depedencies are on > Map, Context, String and a client supplied classpath. Relative to the > component the dependency is on Phoneix and the A-F. > GenericBlockContext provides the bridge between the two.
> Everything about this is solving a Phoneix issue. But, yes - the > solution can be included inside Merlin. Yes we can create artificial > depedencies between the Merlin Project and the Phoenix Project. Yes > we can oblige Merlin installations to include APIs to another > container for those occasions where the client is dealing with Phoenix > legacy and already have phoenix-client.jar in place. Yes, we could > write this up in the FAQ and explain why its a good thing - but I may > need some help on that! Refering to "..artificial dependencies between the Merlin Project and the Pheonix Project" and "..Phoenix legacy..":- Phoenix compatability is what we are talking about here unless I am wrong. It could be we are talking about Phoenix obsolesence (I am not). We have an agreement a way forward for on the BlockContext issue. It is simply to include the BlockContext class (via phoenix-client.jar) in second and subsequent Phoenix compatible containers. Given K/HC/CAPI conversation of the past, and the need for separation of CAPI and K, GenericBlockContext in Phoenix CVS is the wrong solution, I think we all agree that. Given also that the home for GenericBlockContext is not certain (A-F is mooted above, but Phoenix is where it was added). Given also that the content of GenericBlockContext was nothing special - nothing that could not be added to another kernel's CVS tree. My feeling is that this single issue is nothing to do with the attributes thread. That attributes need to be handled correctly designed properly and due consideration given to backards compatability is paramount. Can multiple containers handle attribute changes (well additions reeally) as they are rolled out? Yes, in my opinion. Should attribute strings be added to BlockContext, yes in my opinion. *** Vote *** As such, can we vote on the recommendation : (*) The Avalon team recommends that Phoenix compatile container include phoenix-client.jar in their distribution and make it visible to hosted components at runtime. The Avalon team recommends that Phoenix compatible containers hide their implementations of BlockContext in the kernel's classloader and further hide the impl via use of a Refelection's dynamic proxy. >>> Look at the Servlet/EJB/other APIs. They all follow this pattern and >>> I believe some (servlet API 2.1+) actually mandates that no >>> container specific classes can be in same classloader. >> >> > > Such a policy concerning Avalon containers is also appropriate. In > general we should not be exposing container specific APIs to > components. It locks the component to a particular container and > introduces the problems we are currently dealing with. For Phoenix, given its separation of interface and impl, it is only the word phoenix that is objectionable in the phoenix-client.jar and its attendant package names. If we had our time over we could have moved these classes to another tree/package. Like with othr packages in Avalon, we are keeping there where they are for compatability reasons. This line of discussion deviates from (*) above and its central discussion point alternatives for GenericBlockContext (being added to Phoenix CVS). >>> And we don't want to limit our evolution in future for so little a >>> gain as having a generic implementation. It is rare that the >>> implementations are more than 20-30 lines of code, so I am not sure >>> what the great technical difficulty is. >>> >> Err I agree with you Peter. The interface remains in >> phoenix-client.jar and the impl is left to the container in >> question. I think Stephen is coming round to the possibility of that >> fact. > > > > I'm comming around to the conclusion that : > > 1. the first step is to resolve the context key issue > > - context keys are part of the Avalon component contract > - contract are intended to be maintained > - solving this issue has to be addressed as a higher > priority than convinience interfaces, Phoenix fixes, > or other actions such as defining additional > interfaces I completely disagree. We have got so far on the GenericBlockContext (the need for it in Phoenix CVS) issue. Please don't switch conversational threads when we are on the cusp of an agreement. Please let me tackle these issues one by one. I'll move on to attributes, meta info and other issues in time. It is important for a sense of progress during mediation to resolve an issue. Please try to meet me on this simple goal Stephen. Just because this is against you original posting of GenericBlockContext does not mean all things in this process are going to fall against you. Besides, you see the logic of the BlockContext argument don't you :-)) - Pau -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
