Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 16359 invoked from network); 29 Aug 2002 07:57:23 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Aug 2002 07:57:23 -0000 Received: (qmail 26953 invoked by uid 97); 29 Aug 2002 07:58:02 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 26927 invoked by uid 97); 29 Aug 2002 07:58:02 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 26911 invoked by uid 98); 29 Aug 2002 07:58:01 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3D6DD3DA.3080107@apache.org> Date: Thu, 29 Aug 2002 09:57:14 +0200 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Merlin Container References: <007101c24ed3$3e97ffd0$ac00a8c0@Gabriel> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > For additional commands, e-mail: > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: