avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Date Mon, 26 Aug 2002 11:37:10 GMT

>>>>>>>> 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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message