avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces ApplicationContext.java Kernel.java
Date Sat, 07 Sep 2002 17:37:16 GMT

Paul Hammant wrote:

> Nicola,
>>>> There is now 2 -1s on BlockContext.
>>> I like BlockContext. +1
>>> ( By my reckoning you are now at only -1 )
>> Naa, he withdrew them.
> Yup bloody partially threaded mail (poor substiture for NNTP).
>> Paul, it's not about what I like or what you like or what John Doe 
>> likes.
>> BlockContext is a dependency to Phoenix, and *if* we want to make 
>> cross-container compatible components, it's not a solution.
> BlockContext is a dependancy to Phoenix's hosted compoent API 
> (phoenix-client.jar).  You do not need the rest of Phoenix to mount 
> blocks. It is easy to be compatible,
>> It binds you to Phoenix, but I assume that it's not a problem for 
>> you, you also made a GUI in Phoenix, so I understand you don't see 
>> the point.
> It does not bind you to phoenix per se.  It binds you to the small 
> redistrubitable phoenix-client.jar and the classes it contains.  This 
> is true interface/impl separated API, and not a 'blessed' API like 
> Sun's Servlet or JMX (and other I presume).

And today with Phoenix as is - it defines a variant of a the Avalon 
Component Model.  That's ok providing the users of the API understand 
the implications of coding against a container specific API. Those 
implications are generally bad and should be documeted as 

>> But Avalon is not only Phoenix, and as Peter pointed out he would 
>> like to be able to use Cocoon components.
>> I would like to use Phoenix components.
> There is no reason that a container could not afford a contextualize() 
> that supports castability to BlockContext, CocoonContext, FooContext 
> and BarContext. 

Only if (a) you have a meta-info model in place that declares the 
context derivative, and (b) the derivatibve implementation documents its 
contract relative to the pure Context interface.  Without those two 
things in-place there is one good reason - your component will not run 
outside of the Phoinix environment.

>> If I make the Cocoon components dependent on CocoonContext, it would 
>> not make reuse by Phoenix possible.
> Maybe an kernel extended Phoenix could support CocoonContext and 
> BlockContext (see above).

I think that is the wrong way to look at the problem.  User's should not 
be consered with "workarounds" - that should be able to build and deploy 
components without concern for the containerment environment.  In the 
rare cases where something additional is needed, a good container will 
provide plug-in mechanisms that provide a means for extension of the 
container.  In the long term its possible for such containement 
extensions to become standard - but only with the emergence of several 
different contains and a vested interest by respective champions to 
achieve a common platform. Out there in the real world there are clear 
economic reasons for doing that - in the open-source world things are a 
lot more gray.

>> Think about this, instead of just saying "I like it".
> You unfairly trivialize my posting.
>> Let me be more clear if I can: Phoenix has a specific Context that it 
>> only can use. It's needed, regardless to how itthere; it's needed, 
>> and from a functionality POV I like it too.
> You make your case well.  You are wrong that it is the only container 
> than can use the years old BlockContext.  I have outlined a number of 
> times ways that aloternate containers can be compatible with 
> BlockContext.  The committer have taken a vote on the recommendation 
> that phoenix-client.jar be considered the way that these alternate 
> containers be compatible with BlockContext.  I really don't see where 
> the problem is. 

Phonieix today does not provide any support for context declaration 
which means Phoenix depedency components are locked into (a) using the 
client jar file AND providing an alternative implemetation of 
BlockContext.  Paul - that's a big "AND" that I think you may have 
forgotten about.  Every addition to the BlockContext interface is 
another problem to be dealt with. The practicle solution is for other 
container to fall-back to common denominator position - the Avalon 
Framework - Context interface.  This at least places the responsibility 
onto component authors to be careful about containment depedencies.

>> So the thing should be dealt with on two levels, which we are doing:
>> 1) define common attributes and possibly common Context keys to 
>> access common functionality
>> - thus we need to have a simpèle way of telling in the descriptor 
>> what Context is needed.
> Personally I am only willing to get embroiled in an attributes 
> discussion if you will cede to and honor a simple often repeated point
>  Other containers *can* be compatible with BlockContext, it is not 
> tied to the Phoenix impl, it is reimplementable.

Sure - and I could join the Republican Party - but is it a good idea?.

>> 2) provide a "standard" implementation for "standard" containers of 
>> concrete implementations of the framework, which is Containerkit.
>> - Now it seems to me that BlockContext would be an excellent 
>> candidate for the containerkit Context.
>> I would humbly propose to maybe put the BlockContext in containerkit, 
>> deprecate the one in Phoenix, make the Phoenix one extend the 
>> containerkit one for compatibility, and make Cornestone blocks, which 
>> IIUC Peter also would like to see a components in excalibur (or 
>> something like that), use the containerkit context.
> This is perfectly possible.  

Anything is possible.

> It would work as a strategy, 

A strategy towards what objective ?
With the seperation of the meta-info content from containerkit - 
containerkit is just another container API that will probably end up 
inside Phoenix.

> It might please people who don't want any phoenix package imports in 
> their components.  However, there is no proven need for it given the 
> fact that phoenix-client.jar is usable by alternative containers.

Providing every other container provides the implemetations for Phonix 
specific stuff - can someone explain to me why this is good thing?


> - Paul
> -- 
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-dev-help@jakarta.apache.org>


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