avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@fztig938.bank.dresdner.net>
Subject Fortress questions
Date Mon, 08 Jul 2002 16:46:06 GMT
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
		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

	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
				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
	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

	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 :)
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message