> From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > >>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 containers 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 solutions include using the JavaMail API (connecting through SMTP), or to promote the mailServer interface to the Phoenix level. 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.
childChart.gif
Description: GIF image
parentChild.gif
Description: GIF image
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
