Leo Sutic wrote: > >>From: Berin Loritsch [mailto:[EMAIL PROTECTED]] >> >>Leo Sutic wrote: >> >>>>From: Leo Simons [mailto:[EMAIL PROTECTED]] >>>> >>>>Basically, what you are proposing is to create a hierarchy of >>>>ECMs/ECS rather than a single-level-deep structure, IIUC. The >>>>advantage of this is that using a tree instead of a map results >>>>in better maintainability in larger projects. Right? >>>> >>>> >>>That would be one possiblity, and I could make some arguments >>>for this, but what I want is to factor out the "this component >>>can have subcomponents" behavior from ECM/ECS. That is the primary goal. >>> >>>Both ECM and ECS now have a getComponentHandler method, for example. >>>Both of them implements LogKitManageable, Contextualizable etc. for >>>the sole purpose of passing on the obtained LogKitmanager, Context, etc. >>>to the component handlers. >>> >>>What I want to do is create a common superclass for ECM and ECS >>>and move that code there. >>> >>>So to split the questions: >>> >>> 1) Should the common code of ECM and ECS be factored out? >>> This would make it easier to write ComponentSelectors >>> and ComponentManagers. >>> >> >>Yes, but don't call it AbstractContainer. It will confuse things >>when the new ContainerManager/Container code is ready for prime >>time. >> > > Berin, > > what is your estimate for the ContainerManager/Container code? I > just found it in excalibur.system (had been looking in > excalilbur.container before), and if I'd much rather we got that > stuff going than waste my time with ECM/ECS. > > Just a quick check that I understand the code correctly (it is beautiful, > BTW): > > If I write a servlet, I'd first grab some parameters from > some file (like, number of threads per CPU, etc...). Since > I want to use the MyComponentManager class, I set CONTAINER_CLASS > to "MyComponentManager", which is a FQCN. Then I do: > > ContainerManager containerManager = new ContainerManager (parameters); > > And I now have a completely initialized component manager > inside the containerManager. Then I do a: > > ComponentManager myManager = > (ComponentManager) containerManager.getContainer ();
I want to move this part to a ContextManager, so that it makes it easier to reuse instances of PoolManager et. al. from a parent container. > and when I want to process a request, I can look up the Processor > (for example) component in myManager and pass it the required parameters. The way I would envision it for something like Cocoon where the Cocoon object *IS* a processor, I would do this in the servlet code: Processor cocoon = (Processor) containerManager.getContainer(); I would not expose the ComponentManager to the outside world (Subversion of Control you know). > And now, I want to write a component that holds several other components. > > I take it then, that this would be done just as above. The component > would have a CM created via the ContainerManager. THere is an AbstractContainer class that takes care of the default implementation of this. It builds all the component handlers and such for the Container. The COntainerManager merely manages the instance of the Container. It has its ComponentManager to help resolve config files. > Questions: > > 1) How do I pass a parent CM to the new CM that I create via the > ContainerManager? :) I am working on that. Basically, if I pass it in the constructor, or the ContextManager, I can handle that quite easily. > 2) How do I pass a non-file Configuration to the ContainerManager? (Useful > in > the second case.) Good question. My thoughts are to make the ContainerManager use the ContextManager. It would retrieve the URI from the context and retrieve a Configuration, and store the configuration in the Context. Next, it would pull that configuration and generate the resource. That way, if you short-circuit the normal path, directly providing the Configuration object, it can pick up from there. > 3) Will the Container interface be a marker interface? (See question 7). NO! It is not required, but it is available to easily manage the contents of the Context object. > 4) Is it your intention to not use the Lifestyle interfaces ThreadSafe etc. > any more > and replace them with handler attributes in the configuration file? YES! Absolutely. I want to remove the dependancies on marker interfaces in general. > 5) CONTAINER_CLASS isa component? Not necessarily--but it can be. > 6) CONTAINER_CLASS isa Container? Always / must be? Again, not necessarily, but it can be. Since we are trying to move away from requiring marker interfaces in general, I do not want to enforce this restriction. The only requirement is that the Container is extends Object (the default). > 7) Will a component that implements Container be treated in a special way by > the > Container that contains it? (See question 3). No. A Container is a Container is a Container. If you implement lifecycle interfaces, you have them applied. If not, then nothing special happens. It is preferred for the Container to at least implement Contextualizable so that it can get a reference to all the helpful managers passed in. >>Nothing stops you from directly using the ComponentHandler classes. I >>would suggest you make all of them ThreadSafe, so you don't have any >>funny logic and make things easy on yourself.... >> > > That's pretty much my conclusion, too. > > But for future work I will need the ContainerManager or something > exactly like that. :) I'm working as fast as I can, but if you want to help, I would appreciate it. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>