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:41:10 GMT
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> 
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > So components that expose a management interface need a way
> > of being hosted, 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 different 
> > classloaders.  The proxy would expose the interface in the 
> > root container space, and allow you to use the application 
> > specific classloader to invoke the management interfaces.
> > 
> 
> You have it pretty much spot-on what I want.
> 
> Would the subcontainers inform the root container what components they
> allow to be proxied, or does the root container tell the subcontainers
> what components they should proxy? What about sub-sub-containers?
> 
> Unless we get one big ├╝ber-container, Nicola's view of containers-
> as-adapters require this to work.


For things like this to work, it has to be an attribute to the Service
definition that lets the container know that it is meant to be exposed
as a management interface.  The Container would then either do nothing
because all children are trusted at the container's level, or proxy the
service into its namespace.

Keep in mind that you would not host an App as a child of an App in
most cases, so the reason for this to happen is really only under
special circumstances.  The contract with the exposure has to do with
the service interface and the the container.  It cannot and should
not propogate endlessly up the hierarchy chain.

Using this solution, and the images I supplied, if "child2" was exposed
as a management interface then it can be accessed by "sub2", "child1",
and "end".  However, none of the other "sub"s would be able to see it.
It forces you to be smart about what you expose and where.

In the example hierarchy I sent in the previous mail, if "root" isolates
all its children, then you can only see what is exposed as a management
interface.  On the other token, if "root" has all of its children in the
same namespace, then "sub3" can access "sub2" and "sub1", but none of
their children.  Either case is good.


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


Mime
View raw message