avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Merlin Container
Date Wed, 28 Aug 2002 20:10:44 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> > >>And the reason is:
> > >>
> > >>1. container are not peers when we are looking at them in 
> terms of 
> > >>component management frameworks - they a hierarchical and are 
> > >>subject to constraints concerning access to classloaders, kernel 
> > >>resources and so on.  However, when we get to the 
> management of the 
> > >>services that provide
> > >>    
> > >>
> > >
> > >Not all containers are peers though.  I need to throw together some
> > >real art (PNG or GIF for your preferred format?) to 
> > demonstrate what I
> > >mean.
> > >
> > 
> > GIF
> I will throw something together soon then.

The parentChild image shows the relationships of parents/children/peers.
As you can see, the two parents both have a set of children.  The
children are peers with each other, but the children of one container
are not peers with the other container.  That holds true even when we
have a root parent that acts as a parent to the two in the illustration.
The two parents in that case would be peers with each other, but there
is no change to the relationship of their children.

Using the childChart image, we have a hierarchy of "containers" we can
refer to.  Each container has a unique name so I don't have to refer to
a whole path when I am describing what I mean.

I have seen some emails to the affect that we want a component from
the container "sub1" to be able to access another component that is
hosted in the container "end".  With the hierarchy as is, that is an
impossibility--and it needs to remain so.  The Component/ServiceManager
lookup mechanisms allow us to defer a lookup to a parent XXXManager.
In affect, it lets us resolve UP the hierarchy of containers, but not
ACROSS.  This is by design.

If "end" needs to use the same component that "sub1" needs to use, then
the component needs to live in "root".  Both allow the lookup path to
go through "root/sub1" and "root/sub2/child1/end".  Another benefit of
this is to allow a child container to override the provided component
from the parent container.  That way, if "sub2" defined the "foo"
component to be implemented with "Default-foo", "child2" can override
the supplied implementation with "My-foo".  Here is how it would look:

Root:                 foo = undefinded
Root/sub1:            foo = undefinded
Root/sub2:            foo = Default-foo
Root/sub2/child1:     foo = Default-foo
Root/sub2/child1/end: foo = Default-foo
Root/sub2/child2:     foo = My-foo
Root/sub3:            foo = undefinded

If "end" or "child1" asked for a "foo" component they would get
"Default-foo".  If anything from "child2" asks for a "foo" component
they would get "My-foo".  If a component from any of the other
in the hierarchy higher up than "sub2" asks for a "foo" component, they
would not be able to find it.

Renaming these things to make sense in your need to use JAMES directly,
here is the problem you are facing:

Phoenix/:            mailServer = undefined
Phoenix/JAMES:       mailServer = JAMES
Phoenix/OSM.planet:  mailServer = undefined

Each application is hosted in its own separate container.  Your
include using the JavaMail API (connecting through SMTP), or to promote
mailServer interface to the Phoenix level.

So components that expose a management interface need a way of being
or at least proxied into the root container level.  I think that Proxy
is the
best solution in this case, but the two applications are loaded with
classloaders.  The proxy would expose the interface in the root
space, and allow you to use the application specific classloader to
the management interfaces.

View raw message