cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow
Date Wed, 03 Sep 2003 07:24:42 GMT
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.

>> 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.

> 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 ?

>> 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) 



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message