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