You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2003/08/31 20:40:14 UTC
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
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() ?
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
the disposal job. So this could be a ContinuationsManagerListener (which
can also be notified on creation).
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
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>>
>>
>> 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)
>
>
>
> 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.
>
yes!
in fact you just re-formulated my original proposal for doing this...
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105913410112209&w=2)
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
continuation-id
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?
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
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Marc Portier wrote:
>
>
> 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)
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
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Posted by Marc Portier <mp...@outerthought.org>.
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