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
interfaces
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
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
