excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <siegfried.goes...@it20one.at>
Subject Re: How is responsible for avalon-framework-api and avalon-framework-impl?
Date Mon, 13 Dec 2004 17:54:43 GMT
Hi Niclas,

your first point is beyond my comprehension ... ;-)

Moving the responsibilty to the components to be compatible with 
multiple containers is IMHO the wrong way. Following my simple line of 
thinking I assumed that looking at the context someone could determine 
the container type (in the case of "urn:avalon:container" is politically 
not feasable) and provide a little converter to setup the proper 
context. But any magic not being part of the official distribution is a 
waste of time.

I appreciate that you are going to support AF4 contracts in Metro but I 
have a hard time accepting that two libraries being the core of 
"countless" avalon container implementations are now without a owner. 
And being a newbie it is difficult to appreciate the political 
consideration without a stepping on everyone's toes (btw, I'm quite good 
at that).

So, how to proceed from here?! - I would appreciate if Jakarta folks 
could coordinate themselves to make the components reusable across 
different containers. From a programming point of view this would 
involve Fulcrum and Excalibur while Metro is following its own path.


A toe stepping and un-political

Siegfried Goeschl



Niclas Hedhman wrote:

>On Tuesday 14 December 2004 01:03, Siegfried Goeschl wrote:
>
>  
>
>>thinking along Avalon component reuse with different Avalon containers
>>.... who is actually making changes and release of
>>avalon-framework-[api|impl] nowadays?
>>    
>>
>
>Noone !
>When Avalon was operational, even changes to the documentation what 
>constituted 4.2 container compliance in respect of constructors, resulted in 
>a storm I haven't seen before. IIRC, Leo Simons even managed to prove (at 
>least to himself) that the change in the docs would make an incompatible 
>change to components that tried to be compatible with many containers.
>
>  
>
>>I checked out http://wiki.apache.org/avalon/AvalonContextSurvey and this
>>is the point where the various Avalon containers are really ehmm
>>improvable.. Each container has its own ideas about naming the entries
>>of the context and there is no "exists()" to facilitate querying the
>>context apart from catching the exceptions when you are plainly wrong.
>>Not a big deal but I'm just curious ....
>>    
>>
>
>In my personal opinion, you are absolutely right. However, it was not 
>political feasible 6 months ago to try to make such unifications from the 
>specifications point of view, and I don't think that has changed much.
>You instead end up of having to write components that works in many 
>containers, i.e. the headache is moved to the component author instead of the 
>container author.
>To achieve that you need to stay away from context entries and service lookups 
>that are more complex than a single component by classname.
>
>The most capable of the containers, Merlin, is no longer actively developed as 
>an Avalon container. We have decided in Metro to evolve the AF4 contract 
>separately, and keep runtime compatibility against the Merlin specification.
>
>
>Cheers
>Niclas
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Mime
View raw message