> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
