cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow ContinuationsDisposer.java
Date Mon, 01 Sep 2003 09:06:19 GMT


Sylvain Wallez wrote:
> mpo@apache.org 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)


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


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



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


regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message