You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by mp...@apache.org on 2003/08/26 11:04:39 UTC
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow ContinuationsDisposer.java
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
PR:
Obtained from:
Submitted by:
Reviewed by:
CVS: ----------------------------------------------------------------------
CVS: PR:
CVS: If this change addresses a PR in the problem report tracking
CVS: database, then enter the PR number(s) here.
CVS: Obtained from:
CVS: If this change has been taken from another system, such as NCSA,
CVS: then name the system in this line, otherwise delete it.
CVS: Submitted by:
CVS: If this code has been contributed to Apache by someone else; i.e.,
CVS: they sent us a patch or a new module, then include their name/email
CVS: address here. If this is your work then delete this line.
CVS: Reviewed by:
CVS: If we are doing pre-commit code reviews and someone else has
CVS: reviewed your changes, include their name(s) here.
CVS: If you have not had it reviewed then delete this line.
Revision Changes Path
1.1 cocoon-2.1/src/java/org/apache/cocoon/components/flow/ContinuationsDisposer.java
Index: ContinuationsDisposer.java
===================================================================
/*
============================================================================
The Apache Software License, Version 1.1
============================================================================
Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modifica-
tion, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must
include the following acknowledgment: "This product includes software
developed by the Apache Software Foundation (http://www.apache.org/)."
Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear.
4. The names "Apache Cocoon" and "Apache Software Foundation" must not be
used to endorse or promote products derived from this software without
prior written permission. For written permission, please contact
apache@apache.org.
5. Products derived from this software may not be called "Apache", nor may
"Apache" appear in their name, without prior written permission of the
Apache Software Foundation.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
package org.apache.cocoon.components.flow;
/**
* ContinuationsDisposer declares the contract for the clean-up of specfic
* continuations.
* <p>
* Typically a {@link Interpreter} implementation that produces continuation
* objects which require proper clean up will implement this interface to get
* a call-back in the event of the ContinuationsManager deciding to invalidate
* a WebContinuation.
*/
public interface ContinuationsDisposer {
/**
* Disposes the passed continuation object.
* <p>
* This method is called from the ContinuationsManager in the event of
* the invalidation of a continuation upon the {@link ContinuationsDisposer}
* object passed during the creation of the WebContinuation.
*
* @param kont the {@link WebContinuation} value representing the
* continuation object.
*/
public void disposeContinuation(WebContinuation webContinuation);
}
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
Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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