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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
