You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2004/06/28 13:17:05 UTC
component lifecycles
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?
Thanks for any suggestions.
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: component lifecycles
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
Many thanks
regards Jeremy
On 29 Jun 2004, at 17:48, Ralph Goers wrote:
>
> See below
>
> Jeremy Quinn said:
>>
>> On 29 Jun 2004, at 02:39, Ralph Goers wrote:
>>
>>> Not to throw a wrench in the works, but if I was to implement
>>> something like this (I have, in fact), I would make it ThreadSafe and
>>> create a new naming context every time it is accessed.
>>
>> OK, I have it create a new Context when you instantiate the Component
>> in Flowscript using cocoon.getComponent (EntryManager.ROLE);
>> However, that same Context gets re-used for each call you make to the
>> Component, until you dispose of it.
>> As the Component is pooled (implements Recyclable), each simultaneous
>> access gets a new one.
>> Is this what you meant ?
>
> No. ThreadSafe components are only created once (there is only a single
> instance) and are not pooled so they have much less overhead - but they
> have to be written to be threadsafe.
>>
>>> Then set the system property that allows the JVM to pool JNDI LDAP
>>> contexts and forget about it.
>>
>> This sounds interesting ..... do you have any pointers ?
>
> http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html
>
>>
>> Thanks
>>
>> regards Jeremy
>>
>
>
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: component lifecycles
Posted by Ralph Goers <Ra...@dslextreme.com>.
See below
Jeremy Quinn said:
>
> On 29 Jun 2004, at 02:39, Ralph Goers wrote:
>
>> Not to throw a wrench in the works, but if I was to implement
>> something like this (I have, in fact), I would make it ThreadSafe and
>> create a new naming context every time it is accessed.
>
> OK, I have it create a new Context when you instantiate the Component
> in Flowscript using cocoon.getComponent (EntryManager.ROLE);
> However, that same Context gets re-used for each call you make to the
> Component, until you dispose of it.
> As the Component is pooled (implements Recyclable), each simultaneous
> access gets a new one.
> Is this what you meant ?
No. ThreadSafe components are only created once (there is only a single
instance) and are not pooled so they have much less overhead - but they
have to be written to be threadsafe.
>
>> Then set the system property that allows the JVM to pool JNDI LDAP
>> contexts and forget about it.
>
> This sounds interesting ..... do you have any pointers ?
http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html
>
> Thanks
>
> regards Jeremy
>
Re: component lifecycles
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 29 Jun 2004, at 02:39, Ralph Goers wrote:
> Not to throw a wrench in the works, but if I was to implement
> something like this (I have, in fact), I would make it ThreadSafe and
> create a new naming context every time it is accessed.
OK, I have it create a new Context when you instantiate the Component
in Flowscript using cocoon.getComponent (EntryManager.ROLE);
However, that same Context gets re-used for each call you make to the
Component, until you dispose of it.
As the Component is pooled (implements Recyclable), each simultaneous
access gets a new one.
Is this what you meant ?
> Then set the system property that allows the JVM to pool JNDI LDAP
> contexts and forget about it.
This sounds interesting ..... do you have any pointers ?
Thanks
regards Jeremy
> At 6/28/2004 04:17 AM, you wrote:
>> Hi All
>>
>>
>> The Component is managing a Naming Context on behalf of the
>> FlowScript. The Naming Context cannot be shared by multiple Threads
>> AFAIU.
>
>
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: component lifecycles
Posted by Ralph Goers <Ra...@dslextreme.com>.
Not to throw a wrench in the works, but if I was to implement something
like this (I have, in fact), I would make it ThreadSafe and create a new
naming context every time it is accessed. Then set the system property
that allows the JVM to pool JNDI LDAP contexts and forget about it.
Ralph
At 6/28/2004 04:17 AM, you wrote:
>Hi All
>
>
>The Component is managing a Naming Context on behalf of the FlowScript.
>The Naming Context cannot be shared by multiple Threads AFAIU.
Re: component lifecycles
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 28 Jun 2004, at 14:52, Stephan Coboos wrote:
> Jeremy Quinn wrote:
>
>> How would I organise this differently, in the situation where I had
>> several of these Components, each differently configured, that I
>> wanted to be able to load in FlowScript in a similar way. Maybe we
>> want one setup for read-only privs and another setup for read-write
>> privs etc.
>
> Use the ServiceSelector like for DataSources. I dont't know where
> documentation about this can be found, but the sources of Cocoon
> should contain many lines of that kind and a search on
> "ServiceSelector" should help.
>
> Using a ServiceSelector, a entry in cocoon.xconf looks like:
>
> <your-selector>
> <component-instance class="bar.Foo" name="foo1">
> <parameter ...../>
> </component-instance>
> <component-instance class="bar.Foo" name="foo2">
> <parameter .../>
> </component-instance>
> </your-selector>
>
> In a java class the code to retrieve the component foo1 should be
> something like:
>
> ServiceSelector selector =
> (ServiceSelector)this.serviceManager.lookup(Foo.ROLE);
> ...
> Foo foo1 = (Foo)selector.select("foo1");
> ...
>
> Hope this few lines helps.
Thanks for this.
I had seen ServiceSelector, but was not sure how it could be used from
FlowScript,
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: component lifecycles
Posted by Stephan Coboos <cr...@gmx.net>.
Jeremy Quinn wrote:
> How would I organise this differently, in the situation where I had
> several of these Components, each differently configured, that I
> wanted to be able to load in FlowScript in a similar way. Maybe we
> want one setup for read-only privs and another setup for read-write
> privs etc.
Use the ServiceSelector like for DataSources. I dont't know where
documentation about this can be found, but the sources of Cocoon should
contain many lines of that kind and a search on "ServiceSelector" should
help.
Using a ServiceSelector, a entry in cocoon.xconf looks like:
<your-selector>
<component-instance class="bar.Foo" name="foo1">
<parameter ...../>
</component-instance>
<component-instance class="bar.Foo" name="foo2">
<parameter .../>
</component-instance>
</your-selector>
In a java class the code to retrieve the component foo1 should be
something like:
ServiceSelector selector =
(ServiceSelector)this.serviceManager.lookup(Foo.ROLE);
...
Foo foo1 = (Foo)selector.select("foo1");
...
Hope this few lines helps.
Regards
Re: component lifecycles
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 28 Jun 2004, at 14:50, Unico Hommes wrote:
> Jeremy Quinn wrote:
>
>>
>> On 28 Jun 2004, at 12:43, Unico Hommes wrote:
>>
>>> 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.
>>
>>
>> Hi Unico,
>>
>> Many thanks for your suggestions.
>>
>> I now have it working more as expected .....
>>
>> I implement Parameterizable, Disposable, Recyclable.
>> I made my initialize() method private.
>> I call the initialize method (to lazily initialize) from each
>> (non-lifecycle) method that can get called from the FlowScript.
>>
>> On the first call, I see the code being Parameterized, my method is
>> called, it is initialized, used then Recycled. When Cocoon is
>> shutdown it is Disposed.
>>
>> Each time I run the same pipeline again, I only see it being
>> initialized and Recycled.
>>
>> If I hit the same Pipeline twice simultaneously, I see another
>> instance of the Component being Parameterized etc.
>>
>> Just what the Dr. ordered, thanks.
>>
>> BTW. I have not setup any of the Poolable parameters that you
>> mentioned, but it seems to behave without them. How important is this
>> ?
>>
> Looking around for an answer to your question I came across this:
> http://avalon.apache.org/excalibur/api/org/apache/avalon/excalibur/
> component/PoolableComponentHandler.html which suggests my answer was a
> bit outdated. Personally I never have experimented with pool settings
> a lot myself. Default settings have been sufficient for me.
Thanks, I will have a closer look at that.
>> My next question .....
>>
>> I have my Component setup like this in cocoon.xconf :
>>
>> <component class="org.our.component.LDAPEntryManager"
>> logger="flow.ldap" role="org.our.component.EntryManager">
>> <parameter name="ldap-host" value="ldap://our.org:389"/>
>> <parameter name="ldap-base"
>> value="ou=users,o=project,dc=our,dc=org"/>
>> <parameter name="ldap-user" value="cn=admin,dc=our,dc=org"/>
>> <parameter name="ldap-pass" value="**********"/>
>> </component>
>>
>> And as mentioned above, I load the component in FlowScript like this:
>> cocoon.getComponent (EntryManager.ROLE);
>>
>> How would I organise this differently, in the situation where I had
>> several of these Components, each differently configured, that I
>> wanted to be able to load in FlowScript in a similar way. Maybe we
>> want one setup for read-only privs and another setup for read-write
>> privs etc.
>>
>
> Use separate role names for different component deployments. For
> instance:
>
> <component role="org.our.component.EntryManager/ReadOnly" class="..">
> <!-- read-only configuration -->
> </component>
> <component role="org.our.component.EntryManager/ReadWrite" class="..">
> <!-- read-only configuration -->
> </component>
>
> Then in your flowscript
> var readOnlyEntryManager = cocoon.getComponent(EntryManager.ROLE +
> "/ReadOnly");
>
Gosh!! Nice and simple !!
Many thanks
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: component lifecycles
Posted by Unico Hommes <un...@hippo.nl>.
Jeremy Quinn wrote:
>
> On 28 Jun 2004, at 12:43, Unico Hommes wrote:
>
>> 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.
>
>
> Hi Unico,
>
> Many thanks for your suggestions.
>
> I now have it working more as expected .....
>
> I implement Parameterizable, Disposable, Recyclable.
> I made my initialize() method private.
> I call the initialize method (to lazily initialize) from each
> (non-lifecycle) method that can get called from the FlowScript.
>
> On the first call, I see the code being Parameterized, my method is
> called, it is initialized, used then Recycled. When Cocoon is shutdown
> it is Disposed.
>
> Each time I run the same pipeline again, I only see it being
> initialized and Recycled.
>
> If I hit the same Pipeline twice simultaneously, I see another
> instance of the Component being Parameterized etc.
>
> Just what the Dr. ordered, thanks.
>
> BTW. I have not setup any of the Poolable parameters that you
> mentioned, but it seems to behave without them. How important is this ?
>
Looking around for an answer to your question I came across this:
http://avalon.apache.org/excalibur/api/org/apache/avalon/excalibur/component/PoolableComponentHandler.html
which suggests my answer was a bit outdated. Personally I never have
experimented with pool settings a lot myself. Default settings have been
sufficient for me.
> My next question .....
>
> I have my Component setup like this in cocoon.xconf :
>
> <component class="org.our.component.LDAPEntryManager"
> logger="flow.ldap" role="org.our.component.EntryManager">
> <parameter name="ldap-host" value="ldap://our.org:389"/>
> <parameter name="ldap-base" value="ou=users,o=project,dc=our,dc=org"/>
> <parameter name="ldap-user" value="cn=admin,dc=our,dc=org"/>
> <parameter name="ldap-pass" value="**********"/>
> </component>
>
> And as mentioned above, I load the component in FlowScript like this:
> cocoon.getComponent (EntryManager.ROLE);
>
> How would I organise this differently, in the situation where I had
> several of these Components, each differently configured, that I
> wanted to be able to load in FlowScript in a similar way. Maybe we
> want one setup for read-only privs and another setup for read-write
> privs etc.
>
Use separate role names for different component deployments. For instance:
<component role="org.our.component.EntryManager/ReadOnly" class="..">
<!-- read-only configuration -->
</component>
<component role="org.our.component.EntryManager/ReadWrite" class="..">
<!-- read-only configuration -->
</component>
Then in your flowscript
var readOnlyEntryManager = cocoon.getComponent(EntryManager.ROLE +
"/ReadOnly");
--
Unico
Re: component lifecycles
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On 28 Jun 2004, at 12:43, Unico Hommes wrote:
> 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.
Hi Unico,
Many thanks for your suggestions.
I now have it working more as expected .....
I implement Parameterizable, Disposable, Recyclable.
I made my initialize() method private.
I call the initialize method (to lazily initialize) from each
(non-lifecycle) method that can get called from the FlowScript.
On the first call, I see the code being Parameterized, my method is
called, it is initialized, used then Recycled. When Cocoon is shutdown
it is Disposed.
Each time I run the same pipeline again, I only see it being
initialized and Recycled.
If I hit the same Pipeline twice simultaneously, I see another instance
of the Component being Parameterized etc.
Just what the Dr. ordered, thanks.
BTW. I have not setup any of the Poolable parameters that you
mentioned, but it seems to behave without them. How important is this ?
My next question .....
I have my Component setup like this in cocoon.xconf :
<component class="org.our.component.LDAPEntryManager"
logger="flow.ldap" role="org.our.component.EntryManager">
<parameter name="ldap-host" value="ldap://our.org:389"/>
<parameter name="ldap-base" value="ou=users,o=project,dc=our,dc=org"/>
<parameter name="ldap-user" value="cn=admin,dc=our,dc=org"/>
<parameter name="ldap-pass" value="**********"/>
</component>
And as mentioned above, I load the component in FlowScript like this:
cocoon.getComponent (EntryManager.ROLE);
How would I organise this differently, in the situation where I had
several of these Components, each differently configured, that I wanted
to be able to load in FlowScript in a similar way. Maybe we want one
setup for read-only privs and another setup for read-write privs etc.
regards Jeremy
--------------------------------------------------------
If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !!!!!
--------------------------------------------------------
Re: component lifecycles
Posted by Unico Hommes <un...@hippo.nl>.
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
Re: component lifecycles
Posted by Unico Hommes <un...@hippo.nl>.
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.
--
Unico