You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jakob Praher <jp...@yahoo.de> on 2002/12/27 23:11:55 UTC

cocoon.xconf component-selector and Composable

hi all,

first of all: happy holidays!

I am working on extending xmlforms to be able to plug in
formlifecycelisteners.

for simplicity's sake I use a component-selector right now for
registering the listeners.

I know that there is a CocoonComponentManager which is, as I found out,
allocated on a per request basis (though haven't looked too much in the
details right now (time you know...) ).

To make a long story short: 
I found out that I always get new instances from the component-selector
(using tracing and the plain Object.hashCode( ) ) for a specific hint.
The component-instances are not pooled (as far as I know - I haven't
found Poolable or something like that it in the
ExcaliburComponentSelector). 

My question is this safe:

class SelectorComponent implements Composable {
	ComponentManager _manager;
	public void compose( CompoentManager amanager ) {
	}

	public void doIt( int param,... ) { 
		_manager.lookup ( ... ) ;
		_manager.release( ... ) ; 
	}
} 

since it produces some kind of conversational state between calls, or
should I better use this:

class SelectorComponent implements Component {

	public void doIt( ComponentManager manager, int param,... ) { 
		manager.lookup ( ... ) ;
		manager.release( ... ) ; 
	}
} 

since the component itself does not depend on any state information - it
is perfeclty thread safe by its definition.


thanks

-- Jakob


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org