Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
mpo 2003/08/26 02:04:39
Added: src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Log:
Adding the new ContinuationsDisposer interface declaring the callback for implementation specific Clean-up of continuations.
See initial proposal of http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105948225805344&w=2
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
