cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: component lifecycles
Date Mon, 28 Jun 2004 13:50:43 GMT
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

Mime
View raw message