avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: BlockContext & Merlin.
Date Sun, 25 Aug 2002 13:32:17 GMT

Paul Hammant wrote:

> Peter,
>>>>>>> 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!

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

>> 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 iremains in 
> phoenix-client.jar and the impl is left to the container in question.  
> I think Stephen is comping 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

  2. and that we should recognize that these issues are directly
     attributed to the exposure of container specific APIs

     - this can be addressed within Phoenix
     - this can be corrected within Cornerstone



Stephen J. McConnell

digital products for a global economy

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