Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>>
>>> We want to get an agreement on what to do for the present and future
>>> with regards to unified Component Model, Merlin, Fortress, Phoenix,
>>> et all.
>>>
>>> "Discussions get forgotten, just code remains."
>>>
>>> I will strongly oppose and veto any "compromise".
>>> I want the *solution*.
>>
>>
>>
>> The only real solution is to use the ContainerKit model. With it you
>> get will compatability between all the containers. Phoenix will use
>> it directly while Merlin will load it through its own Type loader. If
>> you choose to use Merlin specific xml format then you will be bound
>> to Merlin.
>> What is the problem with that?
>
>
> IIUC Merlin has features that Phoenix doesn't have (and viceversa).
Correct - Merlin is second generation container.
It's design leverages the strengths and and elimiates the limitations of
the Phoenix system.
Merlin reolves the facility management issue that has plaugesd Phoenix.
Merlin eliminates the very complex assembly declaration procedures in
Phoinix that limit adoption.
Merlin embrasses user requirements from across the Avalon sprctrum.
Merlin delivers a complete context management solution.
Merlin delivers a complete extension platform.
>
> If I write a component that uses these "features", it will not run in
> other containers.
Correct.
A component that includes extension depedencies currently requires the
Merlin/Fortress container model. Phoenix does not provide a validation
framework so it cannot tell you if a component will run or not - you
simply wait for the runtime exception.
>
> Thus, there is no full compatibility between containers.
I belive there are two levels:
* validation - the ability of a ALL containers to pass a validation
stage on the componet type they are supplied with and from that
information, fail gracefully, or, find another component solution. In
the Merlin case this ois possible because Merlin executes validation opf
compoennts in the creation of an assembly graph. In Phoneix there is no
equivalent process.
* deployment - deployment concerns the execution of a valid component.
Cross container deployment requires that there is concensus on things
like lifestyle policies. Merlin povides the complete lifestyle policies
based on the Fortress model. Phoneix is much more limited in this
respect - in fact, based on my kbnowege of Phoeix it's lifestylesupport
is limited to thread-safe components.
>
>
> On one hand, it seems that specifying how to extend the Container
> could solve the problems.
> But as you correctly point out, it's a too big commitment ATM. And a
> similar approach has already failed IIUC.
>
> We would all like Components that run in *all* Containers
> But we still have and want to have different Containers that have
> proprietary semantics. And this creates problems in portability, since
> it has happened that some James Components are tied to Phoenix
> specific things, and they didn't even realize it.
>
> - How can I run Merlin-specific components in Phoenix?
Merlin will be executable inside Phoeix in the very near future.
You will see Merlin as a SAR application managing the complete component
deployment solution. You will also be able to include the Merlin Kernel
as a componet within another application. Both solutions will allow the
embededing of a Foresss container inside Merlin and the managemnt of the
late binding approach used in ECM style compoents and Cocoon.
>
> - How can I run Phoenix-specific components in Merlin?
It's already possible.
I'm running several of the Corbnerstone components inside Merlin on a
day-to-day basis.
I have not provided support for Phoenix specifics such as BlckListener
or ApplicationListener on the grounds of (a) zero demand, and (b) that
the extension mechansisms provide the functionality neeed i a container
independent manner.
>
> - How can I be *aware* that I'm using Container specific stuff versus
> Avalon baseline?
The ONLY solution is to establish concensus on features that a container
needs to recognize.
Recognition of a feature is fundimentation to validation.
Validation is the criteria for Avalon wide container
minimal-quality-of-service.
>
>
> IMHO it would seem that the first two points can be done using a
> correct Container hierarchy.
>
> And that the last one by defining a standard way of *describing*
> extensions (ie in what "context" they are made and what they need) and
> keeping this description physically separate from the standard
> containerkit descriptor.
You still need containers to take responsibility about validation.
Introducing the obligation into Phoenix to validate that a component
does not expose extension or stage dependencies is something trivial to
implement. In fact it wa done in a couple hours by myself but deleted
by Pete. There is no rocket science here - just recognition of a common
set of fesatures and predictable behaiour from a container.
>
> Also the standard containerkit stuff would become part of the
> framework, since it would become mandatory.
It's probably a terminology thing - but "standard containerkit"is a
definate -1.
Containekit mixes into one package meta-info, meta-data and container
utilities that are not workable in a general envioronmenmt. If you mean
a standard meta-info model (which is what I think you mean), then I'm
totally in agreement.
Cheers, Steve.
--
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]>
