Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>
>>Leo Sutic wrote:
>>
>>>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.
>>
>
> I would like to split this one and break out the get and has methods.
>
> AbstractContainer: Provides methods for obtaining handlers to components.
> AbstractManager : Provides methods for accessing component handlers.
>
> Basically, AbstractContainer.m_mapper would be AbstractManager.m_mapper,
> and the rest of the class follows as needed to compile.
>
>
>>>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.
>>
>
> Or pass it in if the created container implements Composable as the
> container
> is being put through the lifecycle steps. The container would
> get the parent cm in compose. The parent cm is passed to the
> ContainerManager via the Context (see below).
>
> I think the ContainerManager must allow for more overrides - one should, as
> with the configuration below, always be able to pass in a pre-generated
> CM, or Context, or Configuration.
>
>
>>>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.
>>
>
> Or:
>
> public class ContextManager {
>
> ...
>
> public void buildConfigurationFromFile (String path) {
> ...
> // Build the configuration from the path, resolving it relative to the
> // context base URI and so on.
> ...
> setConfiguration (newlyBuiltConfiguration);
> }
>
> public void setConfiguration (Configuration configuration) {
> // put the configuration into the context
> ...
> }
>
> ...
>
> }
>
> and replace the constructors of ContainerManager with:
>
> public ContainerManager( final Context initParams,
> final Logger primordialLogger )
>
> The ContainerManager will then use the objects in the initParams to
> initialize the container. That is, initParams contains a configuration,
> it contains Parameters, a ComponentManager and so on. It also
> contains a Context that will be passed on to the created container.
>
> That Context needs some post-processing, since the created container must
> be able to use the Context it recieved in contextualize to create its
> own sub-container.
>
> Therefore, the Context actually passed on to the container is
>
> Context as given in the initParams parameter to the
> ContainerManager constructor
> +
> some elements of initParams itself.
>
> The parts of initParams that should be passed on to the container are
> basically those that the container can not guess itself, but that
> are needed to create a sub-container:
>
> CONTEXT_DIRECTORY
> WORK_DIRECTORY
> LOGKIT_CONFIG
> THREADS_CPU
> THREAD_TIMEOUT
>
>
>>>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.
>>
>
> I think marker interfaces are great: You will need to document the type
> of handler a component uses anyway, so why not make it part of the component
> class? C#, for example, allows attributes to be set for every object in the
> system. Java has interfaces. It would be unwise to throw it away.
>
> I'd go for a handler="..." override and an autodetect based on marker
> interfaces.
>
> No big deal - the ContainerManager is such an improvement that this is
> trivial.
>
>
>>>>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.
>>
>
> I'm in.
>
> /LS
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
"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]>
