avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hamilton Verissimo de Oliveira (Engenharia - SPO)" <hamilton.olive...@agenciaclick.com.br>
Subject Re: Under Merlin's hood (WAS: RE: [avalon] roadmap - library crit eria )
Date Thu, 04 Mar 2004 17:05:46 GMT

> With that in mind, I decided to look at how I could start up Merlin
> _without_ using the repository.  So I started with the DefaultKernel class
> and started tracing back all the dependencies I would need.  I only
> considered constructor dependencies, just the bare minimum I would need to
> full fill the requirements of the DefaultKernel.

Thats only show how *we* still far away from a decoupled architecture. I'm
positive Steve agree with this point.

Hows things have been done in Avalon Castle

As you all know Avalon Castle is for sure being based on Merlin good ideas,
but its not a port of Merlin to C#. 


This is the container configuration. You can see it as lego pieces, and a
minimum amount of pieces is required to get everything up and running.

The Composition Model being intercept by a Runtime was a really nice idea of
Steve. I'm trying to have different Runtime implementations, a small/thin
one and a huge/thick. 

To actually deploy an application (set of components) you must provide a
ContainmentProfile. One could create it as he like it. The important thing
is to send Orchestrator a DeployContainmentProfile message passing on the
ContainmentProfile instance. An IRepository exists, but its not necessary:



My intention is:

Orchestrator will be responsible to invoke lifecycle phases on components.
The actual implementation of these phase could be changed by one only
altering the container configuration (see above the xml file). He can
actually disable one phase if he wants to, although I don't know why he
would need such a thing :-)

Repository and Deployers are/should be easy to replace or even don't have
any. That's my goal with 'a la carte' container. 

I don't like the all-or-nothing approach at all, except for transactions


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message