I might need some direction in the next few days

[Berin Loritsch <bl...@apache.org>]

I want to get this Merlin/Fortress merging working.  Since Both projects
have their own notion of loadable containers, I am going to look at how
to create my own container in Merlin.  I will commit the source code to
Fortress CVS--adding a new requirement.

However, here is where we have some overlap, and different ways of doing
things:

ContainerManager vs. Merlin Kernel
----------------------------------
* ContainerManager takes care of dynamically creating services if they
  do not already exist, and deferring to a parent if the services exist.
* ContainerManager does all its work with a Context object.
* Merlin does all its work with (surprise!) meta-info passed around
* The Merlin Kernel acts as a central management point--like Phoenix
* Fortress has no central management point and was left to the developer
  (of course for simple systems no management point is necessary).

Fortress Container vs. Merlin Container
---------------------------------------
* They are essentially the same thing in both areas
* Merlin has somewhat stricter requirements to make the Kernel and
  container talk to each other.
* Fortress has its Container interface that strictly acts as a way
  for the Service/ComponentManagers to talk to the container itself.
* Both Merlin and Fortress containers directly handle the mapping of
  request to resolution--although in very different ways.

Because Fortress essentially has fewer requirements for its Container,
it only seems natural to try and make the Fortress Container fit the
Merlin model--and see if we can have an interroperable container.

One thing that I would like to know:

Can the kernel have a set of kernel level services?  Already logging
is implemented that way, and I want to put stuff like the CommandManager
in the kernel.  We really only need one--although if necessary, I will
maintain it in the Fortress Container.


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: I might need some direction in the next few days

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

>I want to get this Merlin/Fortress merging working.  Since Both projects
>have their own notion of loadable containers, I am going to look at how
>to create my own container in Merlin.  I will commit the source code to
>Fortress CVS--adding a new requirement.
>

The is an example of a container specialization in the demo package - 
its called CustomContainer.  To get Merlin to use this you just need to 
include the class attribute in the root container declaration in the 
kernel.xml file.

>
>However, here is where we have some overlap, and different ways of doing
>things:
>
>ContainerManager vs. Merlin Kernel
>----------------------------------
>* ContainerManager takes care of dynamically creating services if they
>  do not already exist, and deferring to a parent if the services exist.
>* ContainerManager does all its work with a Context object.
>* Merlin does all its work with (surprise!) meta-info passed around
>* The Merlin Kernel acts as a central management point--like Phoenix
>

General speaking yes - but a Kernel is a little bit more subtile bacause 
the
overall container hierachy can container a kernel as a component in which
case the sub-kernel behaves a little differently (i.e. does'nt attempt to
create a new logging manager, etc).

>
>* Fortress has no central management point and was left to the developer
>  (of course for simple systems no management point is necessary).
>
>Fortress Container vs. Merlin Container
>---------------------------------------
>* They are essentially the same thing in both areas
>

(providing we ignore the hirachical container structure, type 
management, profile management, automated asembly, .... )
:-)

>* Merlin has somewhat stricter requirements to make the Kernel and
>  container talk to each other.
>

This is actually more to do with subsidiary container to parent 
container communications and the synchronization of initialization, 
started, suspended, stopped and disposed states.

>* Fortress has its Container interface that strictly acts as a way
>  for the Service/ComponentManagers to talk to the container itself.
>* Both Merlin and Fortress containers directly handle the mapping of
>  request to resolution--although in very different ways.
>

Don't think I agree with that.  In Fortress there are request resolution 
operations on the Container interface.  In Merlin you can get reference 
to components but the component may or may not exist at the time the 
reference is returned.  Its the reference object that hindes the 
instantiation and lifecycle machinery.

>
>Because Fortress essentially has fewer requirements for its Container,
>it only seems natural to try and make the Fortress Container fit the
>Merlin model--and see if we can have an interroperable container.
>
>One thing that I would like to know:
>
>Can the kernel have a set of kernel level services?  Already logging
>is implemented that way, and I want to put stuff like the CommandManager
>in the kernel.  We really only need one--although if necessary, I will
>maintain it in the Fortress Container.
>  
>

The intention is to treat additional services a pure components. You 
would add a component defintion of your service inside a container, 
declare another container with a dependency on the first container, and 
when the second container goes about providing stuff, it will be 
supplied with a reference to the first container automatically.  The 
second container get the get the reference instances and access the 
services it needs.  However, that's the interntion - not the practice 
just at the moment.  This is stuff right on the borderline of what's 
bootstrap and what's not.

Cheers, Steve.

>
>"They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
>                - Benjamin Franklin
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>