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().
getComponentManager() currently means you have to write code like:
public void initialize() throws Exception
{
super.initialize();
m_manager = getComponentManager();
}
(compose()/service() currently aren't invoked if there's no parent
manager given to the container so that above code can't be placed
there).
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.
Something like (in AbstractContainer):
protected ComponentManager m_componentManager;
public void compose(ComponentManager cm)
throws ComponentException
{
// parent component manager specified)
if (cm != null)
{
m_componentManager =
new FortressComponentManager(this, cm);
}
// no parent component manager specified
else
{
m_componentManager =
new FortressComponentManager(this);
}
}
and something similar in service().
An alternative would be where the CM passed into compose() is
actually the container's CM, with any specified parent-CM parenting it.
(but perhaps this breaks Composable's contract ?)
Either way, it would be good if it could all be set up during
compose()/service(), but from what I see, this is difficult to do due
to the possible presence of Composable *or* Servicable.
(ie. a container can currently have a Composable or Servicable parent)
Which leads to:
2. Composable and Serviceable - how are they meant to work 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.
This can occur when one specifies a ServiceManager as parent to the
container, but uses ComponentManager inside the container
(and vice versa).
On one side this is advantageous as it means you can supply a parent
CM/SM to a container, without knowing whether it uses a CM or SM
internally, but on the other side it sets up the container for
potential runtime problems, eg. if a ServiceManager parent returns a
non-Component castable object to a component manager inside of the
container.
I feel that this could be dangerous - should we actually allow this
mixing of Service and Component managers ?
3. Asynchronous initialization of component handlers seems to be
broken.
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.
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 ?
That's it for the moment! Any ideas, feedback would be much
appreciated :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
