james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE: [Bug 11235]
Date Wed, 14 Aug 2002 10:48:55 GMT

Noel J. Bergman wrote:

>What are the relationships between Merlin, Fortress and Phoenix?  

In the beginning there was ECM (Excalibur Component Manager) and 
Phoenix.  ECM was basically a component manager implementation running 
on steroids.  It came about as a result of the needs of the Cocoon 
community for dynamic service activation.  Phoenix went in a different 
direction, focussing much more of well structured service management 
(dependency control, etc).  About twleve months ago Fortress emerged - 
the next generation of the Cocoon style dynamic service management but 
formally structured as a container.  About the same time, Merlin 1.0 
arrived on the scene - basically a compoent runner along the lines of 
Phoneix (xinfo based management and so on - but with auto assembly 
abilities).  Three months ago some work was initiated on a common 
meta-model for all of these containers in a package called Containerkit. 
That got forked as part of the work relating to Merlin 2.0 - a next 
generation service management platform.  Merlin 2.0 is progressivly 
incorporating Fortress features concerning lifecycle and lifestlke 
management and Fortress is adopting the Merlin 2.0 meta-model.

>Are they all containers for Avalon Frameworks components?  

Yes - but with variations.

  * Fortress supports different component lifestyles (threadsafe,
    per-thread, pooled, etc.) but weak in respect to dependency
    management and formal meta-model.

  * Phoenix provides a reasonably complete app-server framework
    for a linear service management model.

  * Merlin provides a container hierachy, automated assembly,
    dynamic component installation, automated context management,
    package deployment profiles, and more.

>Cornerstone and Excalibre classes work with any of them?

Merlin will provide support for Phoenix blocks reasonably soon.  The DTD 
for Merlin xinfo files is very similar to a block info (but more stuff 
concerning lifecycle extensions, and extension depedencies).  In the 
near future Merlin will automatically build a meta-model from a Phoenix 
block defintion.  Things like BlockListeners may be provided as 
lifecycle extensions.  As Fortress moves forward with implemetation 
above the Merlin meta-model it will aquire the ability to run blocks as 

Merlin 2.0 lives in the following CVS:


>Feel free to post a link to an FAQ.

  Merlin Home Page

  Merlin FAQ

Cheers, Steve.

>	--- Noel
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@apache.org]
>Sent: Tuesday, August 13, 2002 23:24
>To: James Developers List
>Subject: Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams
>RE: [Bug 11235]
>Andrei Ivanov wrote:
>>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>You may want to hold off on this for a little while.  Currently over in
>Avalon land there is work going on concerning a standard "meta model"
>that will be described using an xinfo resource that has the potential to
>enable component deployment across a number of different containers.
> Currently James uses Phoenix as its container and describes component
>meta-info in a blockinfo descriptor.  It is expected that Phoenix will
>be enhanced to support a more standard meta info DTD in the near future.
> In the meantime there is work on-going with two other containers -
>Fortress and Merlin.  The authors of these containers are working
>together to ensure the establishment of a meta-model that completely
>addresses not only the defintions of component services and depenedecies
>along the lines of the blockinfo model, but addition contextn such as
>lifecycle extensions, lifestyle management, and so on.  When this all
>settles down I expect we will see support in Phoenix for the
>Fortress/Merlin meta-model and support for blockinfo declarations inside
>Cheers, Steve.
>Stephen J. McConnell
>digital products for a global economy
>To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>
>To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message