You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/03/04 20:05:52 UTC
ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer)
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Composition vs Inheritance (RE: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer))
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>>>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.
>>>
>
> not commenting on the rest, here's a question: is this really a
> place where inheritance/abstract classes is smart? (me, I always
> use composition by default and switch to inheritance when it is
> neccessary. A maintainability issue...)
>
> Actually, I've been wondering whether this should be at least
> mentioned in the framework documentation.
>
> I generally prefer:
>
>
> interface SomeInterface
> interface SomeInterfaceHelper
>
> class DefaultSomeInterfaceHelper implements SomeInterfaceHelper
> class DefaultSomeInterface implements SomeInterface
> class Alternate1SomeInterface implements SomeInterface
> class Alternate2SomeInterface implements SomeInterface
>
> DefaultSomeInterface --uses--> DefaultSomeInterfaceHelper
> Alternate1SomeInterface --uses--> DefaultSomeInterfaceHelper
> Alternate2SomeInterface --uses--> DefaultSomeInterfaceHelper
>
>
> to:
>
>
> interface SomeInterface
>
> abstract class AbstractSomeInterface implements SomeInterface
>
> class DefaultSomeInterface extends AbstractsomeInterface
> class Alternate1SomeInterface extends AbstractsomeInterface
> class Alternate2SomeInterface extends AbstractsomeInterface
>
>
> while the first one generally means more code, it improves
> code readability. For the most part, Framework and Excalibur
> follow this approach. Pete's been known to do it differently
> in places =)
>
> thoughts?
The ContainerManager and Container handle two different concerns.
The ContainerManager's responsibility is to manage the Container
instance, and all the other helper managers in the system. It is
also meant to reuse existing Managers if they are already created.
The Container is designed to manage the Component instances. The
AbstractContainer does make use of other managers and components
to do its job. But it's purpose is to map components between the
different component instances. I.e. it can be so fine grained as
to allow some components to be available to one component but not
another.
The concrete example would be the following scenario:
Components:
DataSourceComponent
Store
Monitor
Store may be able to obtain a reference to the DataSourceComponent
and the Monitor, but the DataSourceComponent wouldn't be able to
obtain a reference to anything else. Furthermore, the Monitor might
be able to reference the DataSourceComponent but not the Store.
In the ECM, everything is accessible to everything else.
The AbstractContainer provides all the basic logic and hooks to allow
you to enforce whatever policy you want and still maintain the same
configuration format. The AbstractContainer defaults to the same
behavior as the ECM, but allows you to have more fine control.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Composition vs Inheritance (RE: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer))
Posted by Leo Simons <ma...@leosimons.com>.
> > 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.
not commenting on the rest, here's a question: is this really a
place where inheritance/abstract classes is smart? (me, I always
use composition by default and switch to inheritance when it is
neccessary. A maintainability issue...)
Actually, I've been wondering whether this should be at least
mentioned in the framework documentation.
I generally prefer:
interface SomeInterface
interface SomeInterfaceHelper
class DefaultSomeInterfaceHelper implements SomeInterfaceHelper
class DefaultSomeInterface implements SomeInterface
class Alternate1SomeInterface implements SomeInterface
class Alternate2SomeInterface implements SomeInterface
DefaultSomeInterface --uses--> DefaultSomeInterfaceHelper
Alternate1SomeInterface --uses--> DefaultSomeInterfaceHelper
Alternate2SomeInterface --uses--> DefaultSomeInterfaceHelper
to:
interface SomeInterface
abstract class AbstractSomeInterface implements SomeInterface
class DefaultSomeInterface extends AbstractsomeInterface
class Alternate1SomeInterface extends AbstractsomeInterface
class Alternate2SomeInterface extends AbstractsomeInterface
while the first one generally means more code, it improves
code readability. For the most part, Framework and Excalibur
follow this approach. Pete's been known to do it differently
in places =)
thoughts?
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Leo Sutic wrote:
>>
>>>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.
>>>
>>
>>Why? What does it gain?
>>
>
> The current AbstractContainer puts all components in a hashmap and accesses
> them through that map. It also contains code to implement ComponentManager
> functions (ContainerComponentManager).
>
> I'd like to factor out the parts dealing with aquiring the component
> handlers and separate it from the code dealing with how to manage
> those handlers once aquired.
>
> As it is now, AbstractContainer has a lot of good, useful code, but it comes
> with too many strings attached. While it is possible to subclass it and
> override methods to get any behavior, the contract between AbstractContainer
> and its subclasses is a bit too big for me to be able to get "any behavior"
> via subclassing.
Ok. I would like to see your proposal.
>>>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
>>>
>>There are defaults for these values--but they are meant to be overriden.
>>
>
> What I want to achieve is that global settings should propagate down the
> hierarchy of containers. So if you set THREAD_TIMEOUT to 15000 for the
> root container, that should propagate to any child container.
That is exactly what I am working on. When a Container is given its
context, it will be able to use that same context as the parent context
for the child container. Basically, the hierarchy would go like this:
m_childContainerManager = new ContainerManager( m_context );
ContextManager cmanager = m_childContainerManager.getContextManager();
cmanager.setClassName( "org.apache.cocoon.sitemap.InterpretedSitemap" );
cmanager.setContextDirectory( new File(
(File) m_context.get( Context.CONTEXT_DIRECTORY ),
"mount/location/" )
);
m_childContainerManager.initialize();
As you see, you only need to override certain values. The rest are
obtained from the parent context. I am working in a fresh class to
provide this functionality (DefaultContainerManager).
>>If a container has child containers, it would have a ContainerManaager
>>for each child, and override the CONTEXT_DIRECTORY for each one.
>>
>
> Yes, and probably set it to CONTEXT_DIRECTORY (as given in its own context)
> +
> childContainerName. So CONTEXT_DIRECTORY must be available to the container.
Of course.
>>>>YES! Absolutely. I want to remove the dependancies on marker
>>>>interfaces in general.
>>>>
>>>>
>>>I think marker interfaces are great
>>>
>>The problem is when you have a deep implementation or interface
>>hierarchy. If any superclass implements one lifestyle interface, then
>>you cannot change it down the line.
>>
>
> You'd have an ordering ThreadSafe < PerThread < Poolable < SingleThreaded,
> but yeah, I can see that we're trying to be a little too smart here.
Not to mention that it is quite awkward when some of those classes are
in framework, some are in Excalibur, but they are not all in one
package. Furthermore, this way we don't have to change the library if
we find a new way to manage component instances (like I did with the
Per-Thread policy).
>>>I'm in.
>>>
>>Excellent! I can send you the current rework progress (that has come to
>>a standstill due to some fires I have to put out at work) off line,
>>maybe you can flesh it out and get it committed.
>>
>
> Bring it on.
>
> I'll have to start off by figuring out just what your intentions are for
> the different classes, so we don't get some skewed evolution.
It's in CVS now. I didn't mean to commit it, but once I did, I figured
we might as well work on it there. The DefaultContainerManager is where
the new stuff will be--but it isn't functioning yet.
>>BTW, ContainerManager crushes ExcaliburComponentManager in scalability.
>>Part of this is due to asynchronous management
>>
>
> Like the InitComponentHandlerCommand? I searched but couldn't find where
> it was used. Maybe I have an older version.
:) Yes. The InitComponentHandlerCommand is (or supposed is to be)
issued to the Command Queue. The queue is attached to the
CommandManager which in turn executes the command.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> >
> > 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.
>
>
> Why? What does it gain?
The current AbstractContainer puts all components in a hashmap and accesses
them through that map. It also contains code to implement ComponentManager
functions (ContainerComponentManager).
I'd like to factor out the parts dealing with aquiring the component
handlers and separate it from the code dealing with how to manage
those handlers once aquired.
As it is now, AbstractContainer has a lot of good, useful code, but it comes
with too many strings attached. While it is possible to subclass it and
override methods to get any behavior, the contract between AbstractContainer
and its subclasses is a bit too big for me to be able to get "any behavior"
via subclassing.
> I was actually in the process of performing this change. Basically
> allowing for the exchanging of ContainerManager implementations--that
> are specific to a certain platform. You can override methods to
> remove the need for reflection--although the default implementation
> is available.
>
> Also, the ContainerManager is being split into interface and
> implementation....
Cool.
> > 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
>
> There are defaults for these values--but they are meant to be overriden.
What I want to achieve is that global settings should propagate down the
hierarchy of containers. So if you set THREAD_TIMEOUT to 15000 for the
root container, that should propagate to any child container.
> If a container has child containers, it would have a ContainerManaager
> for each child, and override the CONTEXT_DIRECTORY for each one.
Yes, and probably set it to CONTEXT_DIRECTORY (as given in its own context)
+
childContainerName. So CONTEXT_DIRECTORY must be available to the container.
> >>YES! Absolutely. I want to remove the dependancies on marker
> >>interfaces in general.
> >>
> >
> > I think marker interfaces are great
>
> The problem is when you have a deep implementation or interface
> hierarchy. If any superclass implements one lifestyle interface, then
> you cannot change it down the line.
You'd have an ordering ThreadSafe < PerThread < Poolable < SingleThreaded,
but yeah, I can see that we're trying to be a little too smart here.
> > I'm in.
>
> Excellent! I can send you the current rework progress (that has come to
> a standstill due to some fires I have to put out at work) off line,
> maybe you can flesh it out and get it committed.
Bring it on.
I'll have to start off by figuring out just what your intentions are for
the different classes, so we don't get some skewed evolution.
> BTW, ContainerManager crushes ExcaliburComponentManager in scalability.
> Part of this is due to asynchronous management
Like the InitComponentHandlerCommand? I searched but couldn't find where
it was used. Maybe I have an older version.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer)
Posted by Berin Loritsch <bl...@apache.org>.
Sorry for the noise earlier, I meant to print, and I hit reply/send ?!?
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Leo Sutic wrote:
>>
>>>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.
Why? What does it gain?
>>>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.
Yep. see below.
>
>
>>>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 )
I was actually in the process of performing this change. Basically
allowing for the exchanging of ContainerManager implementations--that
are specific to a certain platform. You can override methods to
remove the need for reflection--although the default implementation
is available.
Also, the ContainerManager is being split into interface and
implementation....
> 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.
:) In essence yes, that is what is happening.
> 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
There are defaults for these values--but they are meant to be overriden.
I.e. THREADS_CPU defaults to 2, THREAD_TIMEOUT defaults to 15 seconds,
LOGKIT_CONFIG defaults to "context://logkit.xconf", work directory
defaults to "/tmp", and context directory defaults to "./".
If a container has child containers, it would have a ContainerManaager
for each child, and override the CONTEXT_DIRECTORY for each one.
>>>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.
The problem is when you have a deep implementation or interface
hierarchy. If any superclass implements one lifestyle interface, then
you cannot change it down the line.
Given a situation where you have an interface that is threadsafe
according to its signature (i.e. only one method, or a stateless
component), we might have in implementation that is declared ThreadSafe.
Someone else might come along and extend it, but the new implementation
must be PerThread or Poolable at the least.
You cannot safely change it. Therefore by declaring it in the "handler"
attribute, you don't loose that very important information in the
inheritance hierarchy. In the end, this approach is more predictable,
and scales better in large projects.
>>>>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.
Excellent! I can send you the current rework progress (that has come to
a standstill due to some fires I have to put out at work) off line,
maybe you can flesh it out and get it committed.
BTW, ContainerManager crushes ExcaliburComponentManager in scalability.
Part of this is due to asynchronous management, and part of this has
to do with special attention given to reduce thread contention in the
critical path. ECM brought us a long way, but ContainerManager will
bring us to the next level of ease of use and scalability.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>