> From: Marcus Crafter [mailto:[EMAIL PROTECTED]]
>
> Hi All,
>
> Hope all is well.
>
> Couple of questions about Fortress.
>
> 1. How should a Container get a reference to its own CM/SM - via
> getComponentManager() or via compose()/service().
The CM/SM is merely a lookup interface for the internals of the
Container. The getComponentManager()/getServiceManager() methods
are factory methods so that each client can have its own copy.
This is a plus, because we can safely delay thread contention
issues
until the last possible minute.
> public void initialize() throws Exception
> {
> super.initialize();
> m_manager = getComponentManager();
> }
?!
Danger Will Robinson! Danger! Subversion of Control is bad.
If an AbstractContainer is Composable or Serviceable it will get
the parent manager from the compose()/service() methods. It is
the ContainerManager's responsibility to provide one. If it
doesn't
then there is a bug.
> IMHO, I think it would be better if the
> component/service manager
> was available in a protected m_componentManager variable at the
> AbstractContainer level, after compose()/service() is called.
There is a huge difference between a parent CM and the managed
component's CM. The AbstractContainer creates a new
ServiceManager
All the components created and managed by Fortress are given a
FortressComponentManager or a FortressServiceManager. If the
container does not handle that type of component, it will lookup
in the parent component manager.
Don't confuse the two CMs.
> 2. Composable and Serviceable - how are they meant to
> work together ?
They are mutually exclusive. They should not be used together.
> Currently in Fortress you can only have a Composable or
> a Servicable
> Container, not both *but* it is possible to have an external
> ServiceManager parenting a ComponentManager inside the
> container and
> vice versa.
We have a way of wrapping the ComponentManager or ServiceManager
so that they can be used interchangeably.
>
> I feel that this could be dangerous - should we
> actually allow this
> mixing of Service and Component managers ?
No!
> 3. Asynchronous initialization of component handlers seems to be
> broken.
We need to fix it.
>
> From what I can see the asynchronous initialization code within
> Fortress isn't working. When I trace through the code
> the component
> handlers aren't initialized until components are
> actually lookup()'d.
Hmm. :/
Lazy initialization != asynchronous initialization. What happened?
It used to work?
> In the ContextManager a default CommandQueue object is
> created if one
> is not specified (and also if setCommandQueue(null) is
> given to the
> ContextBuilder (which seems suspicious)) and there
> seems to be no
> ThreadManager associated with the CommandQueue, so
> initialize()'s are
> only done inside FortressComponent/ServiceManager.lookup().
>
> Unfortunately I don't know the event and queue code
> well enough to
> fix this problem if my analysis is correct. Any
> thoughts from the
> more experienced developers there ?
We need to make the CommandManager initialize a default ThreadManager
if one isn't provided.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
