Paul Hammant wrote:
> Stephen,
>
>>> Hmmm...
>>
>>
>>
>>
>> The only issue is for Phoenix to throw the exception
>>
>> try
>> {
>> // do classic Phoenix stuff
>> }
>> catch( ValidationException ve )
>> {
>> final String error =
>> "Sorry, Phoenix isn't as advanced as some other Avalon
>> containers."
>> + "Phoenix does not support"
>> + " * extensions"
>> + " * dynamic context"
>> + " * default configuration"
>> + " * auto assembly";
>>
>> throw new ValidationFailure( error );
>> }
>
>
> OK, ignoring for the time being that this is a little rude to Phoenix
> and its authors,
True - please accept my appologies as no offense was intended.
> there is something positive here. Especially as you have in another
> mail said that Merlin can (or will be soon) be run inside Phoenix.
>
> Given some basic assumptions:
>
> 1) From the laymans point of view, Merlin is apparently an alternate
> container to Phoenix providing extensions, dynamic xontext, default
> configuration and auto assembly beyong the abilities of Phoenix
>
> 2) Phoenix is likely not to support directly those features.
>
> Perhaps we have some positive things to do here:
>
> 1) DTD unified, for Merlin specific elements, basic Phoenix refuses
> to run with a polite message.
The same thing applies to Merlin.
Merlin does not currently provide support for management access point
declarations and should fail validation gracefully. The management
entry point declarations are supported in the Type DTD in order to
ensure compatability across both containers.
>
> 2) Compatibility elements added .xinfo files and assembly.xml.
> A euphamism like <avalon-container-compatability> might be good.
I have thought about this but ran into lots of IOC issues. Basically
its the container that should be handling the poblem - it knows what it
is capable of suppporting and the level of support my be dynamic.
>
> 3) Merlin coded to have distributions for all of these:
> i) standalone
> ii) in Phoenix,
> iii) replacement Phoenix kernel components (refer kernel.conf).
>
> 4) basic Phoenix coded to exlicitly not handle Merlin specific features.
This is possible without including any reference or depedency on Merlin
providing we settle the.xinfo DTD.
I would like at add another couple of points:
5) utilities enabling component migration
One of the problems I have had to deal with concerning existing
components are references to things like BlockContext. Merlin can
work around this through its context management system. A container
indepedent solution called GenericBlockContext was added to the
Phoneix CVS. This seemed the correct thing to do as opposed to
creating a Phoenix depedency in the Merlin CVS.
The original contribution is under the Phoenix CVS (Attic).
org/apache/avalon/phoenix/tools/export/GenericBlockContext.
Are there any objections/issues to bringing this class back into
action?
6) management of components that assume block-listener and application
listener support - my impression is that this could be managed as a
lifestyle extension but I would really need to think more about it
(any thoughts appreciated)
>
>
> We have a way to placate steve's quest for a new generation, Peter
> feeling that phoenix itself should be stable. Please folks if we are
> going to shoot this idea/compromise down, could we do so without
> heated emotion. Could we also try to do so in a summarial way, with
> accompanying detailed explanation: "This will not work because
> Phoenix is a bird that rises from the ashes; Refer to mythalogical
> blah blah blah blah." Some of us demi-management types want to see a
> managerial summary and trust that we don't have to wade through pages
> of justification. If the managerial summary is concisely put, and
> fairly represents the accompanying explanation, then it is a good
> point of reference. This whole Merlin/Phoenix thing has been clouded
> by too much detail, that kinda precludes the involvement of those of
> us who have not written one of the two or swallowed the "Software
> architecture for geniuses". Please -> short, fair and concilliatory
> chatter from now on?
Sounds good.
Steve.
>
>
> - Paul
>
> - 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]>
