Paul Hammant wrote:
> 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).
I am *definately* not either.
Phoenix has his very important space, Merlin/Fortress will have his.
The more they can work together and in *synergy* the better.
> 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.
You are saying that a container that wants to use Phoenix-compatible
Components use BlockContext?
Hmmm..., rephrasing: that a Container that uses Phoenix's blocks must
use other Phoenix stuff too?
Now, since Cornerstone is about Phoenix blocks IIUC, does this mean that
the Phoenix blocks are the standard Avalon Components?
If yes, they should be in framework IMNSHO.
If no, it should be clearly stated that they are Phoenix-only compatible.
And compatibility should not be attained by wrapping Phoenix stuff
artificially, but by hierarchically containing Phoenix, which is a much
cleaner solution.
I don't like your proposal.
>>>> 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).
So you are saying that the Phoenix BlockContext has to be regarded as
the standard Container Context?
This I understand, and I would like to see it become part of the
containerkit somehow or of the framework if this is the case.
Don't ask me why, it's obvious.
>>>> 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 :-))
I completely disagree.
*If* I understand what you are saying that is...
To be more clear, *what* are we discussing about?
A temporary solution for interoperability between Phoenix and
Merlin/Fortress or standard way of defining the Context?
If it's the first case, I agree; this is the easiest solution ATM and
the best given that Phoenix is mature while Merlin is still growing.
If it's the second case, I really fail to understand how you think that
all Containers must adopt Phoenix inventions.
I thought they had to adopt the framework.
IMHO this has come out from the fact that Phoenix has been defining (in
a concerted effort) and bringing forward the concept of Blocks and SARs.
These are becoming important concepts for Component reuse, and Peter is
correctly working with ContainerKit for better reusability.
Can we make this "spec" become more clearly defined and part of
framework somehow?
Do I understand correctly that ContainerKit is Peter's tentative in that
direction, and that Merlin is Stephen's?
I repeat myself, let's define the contracts and the boundaries well, and
I humbly suggest you to also tackle the block and SAR think, because I
think that they are valuable concepts that need to be integrated more at
a lower level.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
