Stephen McConnell wrote:
>
>
> 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?
As nobody has objected to this I'll go ahead an re-commit
GenericBlockContext.
Steve.
>
>
> 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]>
