Nicola Ken Barozzi wrote:
> 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?
This is primary purpose of establishing the excalibur/container package.
To iniate actions focussed on clearly defining the spec for container
to component contracts. Much of this is framework independent - you
think of the framework as the client side of the container/component
architecture. We don't have the container side of the Avalon
architecture. I would like that architecture to arrise as a result of
progressive solutions build through collaboration across different
containers. I don't want to see one view of a container architecture
(such as conterkit) being forced upon us. Instead, I want to see
inovation, well-defined contracts, documented semantics, .etc.
>
> Do I understand correctly that ContainerKit is Peter's tentative in
> that direction, and that Merlin is Stephen's?
More correctly ....
* containerkit is Pete's iniative to define a container architecture
* excalibur/meta is a small package that defines a meta-info model as
a seperate concern from a container architecture
* escalibur/container is the result of work between Fortress and
Merlin that has led to the establishment of a set of container
indepedent interfaces (currently the lifecycle extension interfaces),
together with documentation on specific issues and proposal dealing with
component portability (context keys, meta-info attributes, etc.).
* excalibur/assembly is the Merlin 2 container that uses the
excalibur/meta and excalibur/container resorouces
Cheers, Steve.
>
>
> 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.
--
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]>
