> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > >Outward flows of information include: > > > >* getName() (not setName()) > > > > This was a convinience operation only used in logging messages by a > parent container. Its easily removed. > > >* Container createContainer(...) > > > > Can be removed from the interface.
:) That would make me happy. > >* getState() > > > > This one is more complicated. Invoking suspend on a > container results > in the invocation of supend on all subsidiary containers and > the parent > basically waits for all subcontainers to achieve suspension before > considering itself suspended. This was not in the interface > before but > the introduction of the ability to plug-in a foreign container in a > heirachy complicated things. I've got some ideas but I need to think > some more first. Right. This stems from the decision to have each and every container run in its own thread. The simple solution would be to have the suspend() and resume() methods to block until they are completed. It is perfectly reasonable to do that, and manage the number of threads you want to use for the purpose of simultaneously suspending and resuming the containers within the parent container. > > >* getResources() > > > > This is part of the service functionalityb of a container. > Keep in mind > that a container acts as a factory of services derived from the > component implemetation it is managing. The getResources() method > isolates managed compoents from the services they provide. > There is an > alternative - namely the publishing of the established > service back to > the component manager (classloader) which may be more > consitent however > - I think this operation will still be needed in management > applications > (but that could be split out to a different interface). In my mind service == component, so could you help me understand your distinction between the two? Also understand that not all containers will want to expose any "resources" (is that supposed to be the same as management interfaces?) so it should be moved into a separate interface. > >>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. > There is some enhancements that need to be applied to the > thread model - > basically moving thread establishment from the container to > its parent. Right. > That's going to have some impact on the control mechanisms > and should > enable some simplification of the interfaces (and > implementation indise > DefaultContainer). correct. > >However, there are many ways to publish a component, and to mark a > >component as publishable. > >Keep in mind that the container does not have to respect the > publishable > >attribute. It is perfectly valid to be more restrictive, but it is > >definitely not valid to be more lenient. > > > > > > Absolutely - the intention concerning the getResource() operation is > that a container is always in control of the resources it > exposes. I'm > also working on a URL based container access mechanism - its working > with remote containers at the moment and I have in mind a > generalization > of this that could replace the getResources() operation. It would > basically provide similar functionality to the ECM lookup semantics - > but service instances would be packaged under a java.net.URL. > Different > URL handler then take care of the interaction with a local or remote > containers during service resolution. It sounds interesting to say the least. I still don't have the "big picture" of exposing the resources that you describing. Some of the clouds have moved out of the way, but it seems we have some heavy cloud cover on this one. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
