Paul Hammant wrote:
> Nicola,
>
>>> 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.
>
>
> Kewl, it looks we're all on the same page then.
>
>> Phoenix has his very important space, Merlin/Fortress will have his.
>> The more they can work together and in *synergy* the better.
>
>
> I agree.
>
>>> 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?
>
>
> I'm uncomfortable with the word stuff Nicola. BlockContext for one,
> other classes from phoenix-client.jar too. I've suggested before that
> phoenix-client can be paired down a little further and think we should
> revisit that in a later discussion.
>
>> Now, since Cornerstone is about Phoenix blocks IIUC, does this mean
>> that the Phoenix blocks are the standard Avalon Components?
>
>
> People in this list for a while know I sway away from the use the of
> the word Avalon in anything other than a 'project' sense. Avalon is
> not a product it has not components. Avalon-Framework is a set of of
> interfaces (++) that define the way that a nomber of containers
> interoperate with lifecycle things. Some things in excalibur are
> simple A-F aware components that can be used like normal libraries
> jars by Java classes. Something are containers for special situations
> - ECM for Servlets (not exclusive). Tweety for play, Phoenix for
> enterprise. Some of these containers have different rules as the
> lacing together of components. Phoenix separates lacing-together into
> assembly.xml and configuration into config.xml. Others are less
> strict. A less strict one is EOB, which affords its components the
> runtime binding that Phoenix itself does not.
>
>> If yes, they should be in framework IMNSHO.
>
>
> I might agree that, given our time over that would be a better place.
> However that is off-topic. We are principally addressing one element
> of the recent disagreement. Namely the adding of GenericBlockContext
> to Phoenix CVS. Its author did so because he felt it was the only
> choice. Between us we have come up with an alternate solution that
> seems to be more inline with the original design of Phoenix. Nicola,
> please take a look at the contents of phoenix-client.jar - it is quite
> benign.
>
>> 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.
>
>
> Well that is a shame, but you are admitting that is a possible
> solution to the central issue of this thread which was the adding of
> GenericBlockContext tp Phoenix by Stephen.
>
> I do intend to adress the enhanced featuresof Merlin later. I also
> intend to be favourable to the concept of value-added. One issue at a
> time please.
>
>>>>>> 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?
>
>
> Yup, it seems that the multi-year-old BlockContext is part of a
> defacto API. If you look at phoenix-client.jar you'll see that it is
> quite small and given amazing accident or far-sighted design by
> Stefano/Fede and others marks a good division between interface and
> impl of Phoenix from the component writers point of view.
Strong disagreement!
This is the wrong approach. We have the framework and the framework we
have Context and Context defines a named value pair scheme.
Irrespective of what you change about BlocContext - that fact is that
it is a Context object and as such the keys that are used and the types
of objects retured are part of the contract. Resolving the question of
keys in the context of a common container-component contract is a
precusor to any convinience interface - and BlockContext is just a
convinience interface.
>
>
> Yes, it has the word phoenix in it, but as I have pointed out before
> does not mean that all of Phoenix has to be included. It is already a
> better interface/impl separation than Sun's JMX or Servlet APIs are
> which require forking by alternative container developers.
>
>> 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.
>
>
> Apart from backards compatability. Yes, I might agree to a move to
> A-F. No, I might agree that it we had our design time again, we'd have
> a hierarchy (or not) of Context in A-F. A move to containerkit is not
> going to please the Merlin folks as they are based on
> excalibur/container.
Minor note - the Merlin folks ;-) use the excalibur/meta pacikage for
the meta-info layer (whicbis what your referencing here).
> However the central point of this thread is to adress the need for
> GenericBlockContext in Phoenix CVS. Perhaps my suggested vote topic
> was wrong. It should have been "[Vote] GenericBlockContext in Phoenix
> CVS is the wrong solution +1"
>
>>>>>> 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 did not say that. Do not put words in my mouth. I am suggesting
> that all 'enterprise' containers that look to support blocks should be
> compatible with phoenix. I'm not covering ECM here. I'm not covering
> Servlet containers etc. I am covering containers who's stated aim is
> some level of interoperability with Pheonix. Could we try to keep
> discussion on the topic of GenericBlockContext.
But lets keep in mind that GenericBlockContext was introduced within the
scope of component portability.
:-)
>
>> I thought they had to adopt the framework.
>
>
> As well yes. That /is/ a prerequisite for all Lifecycle aware
> containers. Again though, that does not cover Servlet containers, or
> EJB containers. It also does not cover Applets (given they too are
> mounted in a container).
>
>> 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.
>
>
> With all due respect to Peter's effort there, Merlin is not using it.
> You will have a diffucult time convincing Stephen to move Merlin to
> containerkit. At a certain 'personal choice' level he should not have
> to.
Steve is really keen to see a comon solution - but he doesn't want the
containerkit architecture - it does not fit Merlin's requirements. The
excalibur/meta package represents an extended sub-set of containerkit
that addressed a more general requirement. The containerkit
architecture could very easily adapt to the meta-info model defined in
excalibur/meta. But that's not a real issue - the excalibur/meta
package can deal with containerkit based solutions just as containerkit
could easily deal with excalibur/meta solutions.
Cheers, Steve.
>
>
>> 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?
>
>
> No Merlin is a container that cn do the lot. Container kit is a
> reusable kit that a container writer may use as a part of a larger
> development which is a container.
>
>> 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.
>
>
> Could we try to keep discussion on the topic of GenericBlockContext.
>
> SAR, Block, Assembly, .xinfo later please.
>
> - Paul
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
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]>
