avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merlin Container
Date Thu, 29 Aug 2002 07:57:14 GMT

Berin Loritsch wrote:
>>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.  

My experience shows that a conflict of interest assises here.  Take the 
James example taking the approch of class isolation - putting common 
resources higher in the container hierachy, depedent resource lower in 
the hierachy.  You end nicely isolating the james package which is good 
from a class management perspective but problamatic if you apply the 
same principals to service publication.

     /cornerstone <-- cornerstone classes
        - datasource selector
        - repository manager
        - time scheduler
        - sockets
        /james <-- james classes
          -- dns
          -- nns
          -- nntp
          -- nntp-auth
          -- nntp-server
          -- users
          -- mailstore
          -- james
          -- spool
          -- smtp-server
          -- remote

What is desirable in the above scenario is to consider the complete 
picture as a complex system in which only a few specific services are 
actually published by the root container.

The conceptually desirable solution is to take the above container 
graph, put in a block box, expose the service interfaces of interest, 
and asset the result as a dynamic component.  This gives you benefit of 
good internal structure combined with the benefits of encapsulation. 
However, as things stand today, the notion of encapsulation does not 
exist within the container defintion.

Cheers, Steve.

> 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>


Stephen J. McConnell

digital products for a global economy

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

View raw message