cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow
Date Wed, 03 Sep 2003 09:50:01 GMT

Sylvain Wallez wrote:
> Marc Portier wrote:
>> Sylvain Wallez wrote:
>>> wrote:
>>>> mpo         2003/08/26 02:04:39
>>>>  Added:       src/java/org/apache/cocoon/components/flow
>>>>  Log:
>>>>  Adding the new ContinuationsDisposer interface declaring the 
>>>> callback for implementation specific Clean-up of continuations.
>>>>  See initial proposal of 
>>> Sorry for being late on this, but is this new ContinuationsDisposer 
>>> interface really needed ? The use case explains that the interpreter 
>>> will implement ContinuationsDisposer. Since it's the interpreter that 
>>> creates WebContinuation instances, why can't it create a specialized 
>>> subclass that does the call back on invalidate() ?
>> there is a small nuance to be made: If we would make a subclass, then 
>> still the current WebContinuation management implementation 
>> (ContinuationsManagerImpl) would not use it.
>> Here is what goes on:
>> When the 'interpreter' (specific flow impl) needs to 'start' a flow it 
>> just makes his own kind of continuation objects (which do NOT need to 
>> comply to any interface!)
>> After creation of that own object the interpreter asks the 
>> ContinuationsManager to wrap this 
>> interpreter-specific-continuations-object into a common purpose 
>> WebContinuation object. (the thing that has an invalidate())
>> From there the ContinuationsManager starts managing the life of the 
>> WebContinuation without giving much attention to possible live-cycle 
>> needs of the wrapped specific-continuation-object.  (precisely this 
>> was changed by this commit, admittedly only in the event of the 
>> invalidate())
>> For completeness: When the interpreter needs to 'continue' a flow it 
>> gets the continuation-id for which it can ask the ContinuationsManager 
>> the corresponding WebContinuation object from where it can obtain the 
>> original wrapped continuation object. (which it then typically 
>> downcasts to its own specific implementation class) 
> Ah, ok. I didn't knew this two-step mechanism.

no pro, happy to be explaining,

actually the recent issues with the commandmanger versus cleanup of the 
webcontinuations made me look at this again and now I noticed that the 
thread checking for expire continuations will only remove them, but not 
call the invalidate()

so expect some more changes in this class

in fact: does anybody know about special side-effects of invalidation of 
flowscript continuations?

is there a reason why invalidation isn't called a the time of expiration?

>>> And if finally this proves to be really needed, the name doesn't seem 
>>> adequate, as this interface is notified of the disposal and doesn't do 
>> Doesn't do the disposal? It does!
>> What I mean is: sure the ContinuationsManager cleanes up the 
>> WebContinuation, but this interface offers the opportunity to dispose 
>> and clean up the orginal implementation specific continuation object.
>> In other words: The one implementing this interface is interested in 
>> the event and should be for one purpose: organizing the disposal of 
>> the wrapped continuation.
>> I hope this accumulates to some argumentation in favour of the current 
>> name.
> If it does the disposal, then it makes sense. But let's consider it 
> another way : what if in WebContinuation.invalidate() we checked if the 
> wrapped object is Disposable ? This would allow to cleany dispose the 
> interpreter-specific object without requiring a callback interface.

in fact you just re-formulated my original proposal for doing this...

given the fact that nobody reacted then I just went for a less intrusive 
way to add this feature... (I still needed it and assumed lazy consensus 
had been waiting long enough)

less intrusive in the sense that the leading flow-implementation doesn't 
need this, so I guess people using that would rather see a test for null 
in stead of an instanceof test since the enclosed body doesn't need to 
be executed for them?

>> Trying to foresee the next step in the discussion:
>> my first idea was to have this
>> ContinuationsDisposer.disposeContinuation(WebContinuation 
>> webContinuation);
>> method take the wrapped object as an argument directly.  However the 
>> full wrapping WebContinuation gives access to e.g. the userObject and 
>> continuation-id which seemed logical to have access to in this case...
> Is the continuation-id needed for disposal ?

probably not:
- flowscript isn't using this
- if an an apple would need it then it should just grab his id during 
contextualize() and use that during his own dispose()

this could only be useful for 'Interpreters' (ie flow implementations) 
that maintain own stores of specific information based on the 

note that next to the continuation-id there remains the mysterious 
userObject that might be used/needed. (precisely to prevent own stores 
like mentioned above)

but I have to say I haven't seen practical use for this userObject yet: 
I would just put that kind of stuff inside the own specific continuation 
object, but maybe this does make sense for script-interpreters?

>>> the disposal job. So this could be a ContinuationsManagerListener 
>>> (which can also be notified on creation).
>> As things are today I don't think the solution needs another name for 
>> this component specifically....
>> IMHO The naming confusion we encounter here really starts in having a 
>> method public Object getContinuation() on the WebContinuation class. 
>> (which is the method returning the wrapped specific implementation.)
>> Calling them both (Web)Continuation, not declaring an interface for 
>> the wrapped object, not considering more formal lifecycle management 
>> on these stateful objects... etc etc are all sensible remarks to make
>> At this stage I was just trying to 'go with the flow' as they say, 
>> trying not to revolutionise too much, I very much welcome deeper 
>> thought and considerations in this area... (but have to concede that 
>> my previous attempts at starting some discussion did not yield the 
>> desired result) 
> ;-)

yeah, I realize :-)

less jokingly I have to say I keep on hoping this is caused by my bad 
timing or else my wrong style... if not I could get slightly worried by 
seeing so little people interested in these parts of cocoon (given the 
media attention were putting on it)... or am I just jumping to conclusions?


Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message