Unico Hommes wrote:
Jeremy Quinn wrote:
Hi All
I am making a (non-SiteMap) Avalon Component that allows you to manage LDAP Entries from FlowScript. (LDAPEntryManager).
I am loading the Component in FlowScript using it's Interface:
var users = cocoon.getComponent (EntryManager.ROLE);
and disposing it using:
cocoon.releaseComponent (users);
The Component implements the following lifecycle Interfaces:
Configurable, Serviceable, Initializable, Disposable, ThreadSafe
Configurable works as expected, the configuration in cocoon.xconf is correctly read when Cocoon starts up.
I am not sure I need Serviceable as I do not need to lookup other components.
Initializable, Disposable are not triggering when expected.
My assumption was that 'initialize' would be called at the time of cocoon.getComponent and 'dispose' would be called at the time of cocoon.releaseComponent, but this is not happening.
'initialize' is being called at Cocoon startup, and 'dispose' is being called at Cocoon shutdown.
The Component is managing a Naming Context on behalf of the FlowScript. The Naming Context cannot be shared by multiple Threads AFAIU.
I am sorry, I am sure these basic lifecycle questions bore the bejesus out of you, but, what Interfaces should I implement to have my methods called by cocoon.getComponent and cocoon.releaseComponent ?
So, experimenting ..... I removed ThreadSafe and Serviceable.
What happens now is that the Component is Configured, Initialised and Disposed for every use, which is safer, but I do not need it Configured for every usage, this only needs to be done once.
How can I get it Configured only once, but Initialised and Disposed for every cocoon.getComponent/cocoon.releaseComponent pair?
Instead of Disposable implement org.apache.avalon.excalibur.pool.Recyclable. ECM will call the recycle method when it releases the instance back to the pool. As for activating your component upon acquirement there is currently no real support for that in Cocoon AFAIK. You could lazy-activate your component when its service methods are called.
Forgot to mention: when implementing Poolable (Recyclable extends Poolable) don't implement ThreadSafe. These interfaces are contrary. In avalon speak they define the 'lifestyle' of a component, where ThreadSafe means singleton (one instance per container) and Poolable means single threaded (stateful) and pooled (duh :-). Poolable components also have some extra configuration semantics. Attributes pool-min, pool-max, pool-grow control ECMs pool behavior.
-- Unico
