You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Evan Koffler <ev...@codezodiac.com> on 2002/06/04 05:41:38 UTC
Turbine3 - RequestTools refreshing
I love the new pipeline. It's good to see it coming along.
I have a web flow that uses a request tool to capture inform/error
messages. In testing, it continued to grow. Basically, because the
request tools weren't being refreshed. I took a stab at implementing
the correction. All 10 lines of code. Below is the patch to existing
code and attached is a new java source file. I tried my best to
comply.
Thanks,
Evan
Index: conf/turbine-classic-pipeline.xml
===================================================================
RCS file:
/home/cvspublic/jakarta-turbine-3/conf/turbine-classic-pipeline.xml,v
retrieving revision 1.3
diff -u -r1.3 turbine-classic-pipeline.xml
--- conf/turbine-classic-pipeline.xml 18 Jan 2002 22:32:40 -0000
1.3
+++ conf/turbine-classic-pipeline.xml 4 Jun 2002 03:35:41 -0000
@@ -10,5 +10,6 @@
<valve
className="org.apache.turbine.pipeline.DefaultActionValve"/>
<valve className="org.apache.turbine.pipeline.RunModulesValve"/>
<valve
className="org.apache.turbine.pipeline.DefaultTargetValve"/>
+ <valve
className="org.apache.turbine.pipeline.DefaultReleaseRequestToolsValve"/>
</valves>
</pipeline>
Index:
src/java/org/apache/turbine/services/pull/TurbinePullService.java
===================================================================
RCS file:
/home/cvspublic/jakarta-turbine-3/src/java/org/apache/turbine/services/pull/TurbinePullService.java,v
retrieving revision 1.15
diff -u -r1.15 TurbinePullService.java
--- src/java/org/apache/turbine/services/pull/TurbinePullService.java
24 Apr 2002 20:03:25 -0000 1.15
+++ src/java/org/apache/turbine/services/pull/TurbinePullService.java
4 Jun 2002 03:35:42 -0000
@@ -631,6 +631,7 @@
context.remove(toolData.toolName);
if (tool != null)
{
+ ((ApplicationTool) tool).refresh();
pool.putInstance(tool);
}
}
Re: Turbine3 - RequestTools refreshing
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@collab.net> writes:
> So refresh()'ing on the way back into the pool would be the more
> correct behavior. Peter, if Fulcrum is not already doing this, would
> you be interested in submitting a patch
> <http://jakarta.apache.org/site/source.html> to make it so?
'Scuse me, s/Fulcrum/Turbine/.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine3 - RequestTools refreshing
Posted by John McNally <jm...@collab.net>.
You do not have to build pull tools so that they are poolable
(Recyclable). Whether a request scoped pull tool is pooled is
determined by whether it implements the Recyclable interface.
The refresh method of ApplicationTool is used with global and session
scoped tools.
The two interfaces are not related. And there probably is no reason to
> > refresh()
> > {
> > dispose();
> > }
>
over
refresh()
{
}
Unless its possible the tool could be used in different scopes. But as
long as the method must be implemented, and a useful implementation
already exists in another method, it can't hurt.
john mcnally
On Mon, 2002-06-10 at 19:05, Daniel Rall wrote:
> John McNally <jm...@collab.net> writes:
>
> > I think there is some confusion on refresh() at least there is for me.
> > The method that was called when an object is returned to the pool is
> > dispose(). I would generally write
> >
> > refresh()
> > {
> > dispose();
> > }
> >
> > or vice versa. and put all the logic in one method.
>
> This is rather confusing, as dispose() is not part of the
> ApplicationTool interface -- it's something from PoolService, I
> believe. If I'm using PullService, I shouldn't have to care about the
> details of the underlying object pooling implementation. Everything
> that I need to care about should be part of the ApplicationTool
> interface. Perhaps we just need more docs? Still, it is non-obvious.
>
> > On Thu, 2002-06-06 at 10:32, Daniel Rall wrote:
> > > "Peter Lynch" <pe...@mindspring.com> writes:
> >>
> >> > ----- Original Message -----
> >> > From: "James Taylor" <jt...@4lane.com>
> >> > To: <tu...@jakarta.apache.org>
> >> > Sent: Tuesday, June 04, 2002 5:02 AM
> >> > Subject: Re: Turbine3 - RequestTools refreshing
> >> >
> >> >
> >> >> On Mon, 2002-06-03 at 23:41, Evan Koffler wrote:
> >> >> > I love the new pipeline. It's good to see it coming along.
> >> >>
> >> >> Yay! I love the pipeline too, and am glad that it works for you.
> >> >>
> >> >> > I have a web flow that uses a request tool to capture inform/error
> >> >> > messages. In testing, it continued to grow. Basically, because the
> >> >> > request tools weren't being refreshed. I took a stab at implementing
> >> >> > the correction. All 10 lines of code. Below is the patch to existing
> >> >> > code and attached is a new java source file. I tried my best to
> >> >> > comply.
> >> >>
> >> >> As far as releasing tools, that is already done by DefaultTargetValve,
> >> >> which on line 199 calls Module::requestFinished, which in turn calls
> >> >> TurbinePull::releaseTools.
> >> >>
> >> >> As for refreshing, should this happen when the tools are released or
> >> >> when they are requested from the pool. Right now request tools always
> >> >> get initted when they are pulled from the pool, perhaps with the
> >> >> assumption that init makes refresh unnecessary.
> >> >>
> >> >
> >> > Never could understand why a pull tool would be returned to the pool, without
> >> > having it's internal object references cleaned up. Otherwise you get a bunch of
> >> > objects in the pool with stale references to other objects, but since it is in
> >> > the pool, what is the point.
> >> >
> >> > Seems a tool should be 'cleaned' or refreshed before going into the pool. Then
> >> > on the way out initing still makes sense by itself.
> >>
> >> So refresh()'ing on the way back into the pool would be the more
> >> correct behavior. Peter, if Fulcrum is not already doing this, would
> >> you be interested in submitting a patch
> >> <http://jakarta.apache.org/site/source.html> to make it so?
> >>
> >> - Dan
> >>
> >> --
> >> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >> For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
> > SPAM: ---- Start SpamAssassin results
> > SPAM: -4.4 hits, 5 required;
> > SPAM: * -4.4 -- 'In-Reply-To' line found
> > SPAM: * -0.0 -- AWL: Auto-whitelist adjustment
> > SPAM:
> > SPAM: ---- End of SpamAssassin results
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine3 - RequestTools refreshing
Posted by Daniel Rall <dl...@finemaltcoding.com>.
John McNally <jm...@collab.net> writes:
> I think there is some confusion on refresh() at least there is for me.
> The method that was called when an object is returned to the pool is
> dispose(). I would generally write
>
> refresh()
> {
> dispose();
> }
>
> or vice versa. and put all the logic in one method.
This is rather confusing, as dispose() is not part of the
ApplicationTool interface -- it's something from PoolService, I
believe. If I'm using PullService, I shouldn't have to care about the
details of the underlying object pooling implementation. Everything
that I need to care about should be part of the ApplicationTool
interface. Perhaps we just need more docs? Still, it is non-obvious.
> On Thu, 2002-06-06 at 10:32, Daniel Rall wrote:
> > "Peter Lynch" <pe...@mindspring.com> writes:
>>
>> > ----- Original Message -----
>> > From: "James Taylor" <jt...@4lane.com>
>> > To: <tu...@jakarta.apache.org>
>> > Sent: Tuesday, June 04, 2002 5:02 AM
>> > Subject: Re: Turbine3 - RequestTools refreshing
>> >
>> >
>> >> On Mon, 2002-06-03 at 23:41, Evan Koffler wrote:
>> >> > I love the new pipeline. It's good to see it coming along.
>> >>
>> >> Yay! I love the pipeline too, and am glad that it works for you.
>> >>
>> >> > I have a web flow that uses a request tool to capture inform/error
>> >> > messages. In testing, it continued to grow. Basically, because the
>> >> > request tools weren't being refreshed. I took a stab at implementing
>> >> > the correction. All 10 lines of code. Below is the patch to existing
>> >> > code and attached is a new java source file. I tried my best to
>> >> > comply.
>> >>
>> >> As far as releasing tools, that is already done by DefaultTargetValve,
>> >> which on line 199 calls Module::requestFinished, which in turn calls
>> >> TurbinePull::releaseTools.
>> >>
>> >> As for refreshing, should this happen when the tools are released or
>> >> when they are requested from the pool. Right now request tools always
>> >> get initted when they are pulled from the pool, perhaps with the
>> >> assumption that init makes refresh unnecessary.
>> >>
>> >
>> > Never could understand why a pull tool would be returned to the pool, without
>> > having it's internal object references cleaned up. Otherwise you get a bunch of
>> > objects in the pool with stale references to other objects, but since it is in
>> > the pool, what is the point.
>> >
>> > Seems a tool should be 'cleaned' or refreshed before going into the pool. Then
>> > on the way out initing still makes sense by itself.
>>
>> So refresh()'ing on the way back into the pool would be the more
>> correct behavior. Peter, if Fulcrum is not already doing this, would
>> you be interested in submitting a patch
>> <http://jakarta.apache.org/site/source.html> to make it so?
>>
>> - Dan
>>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> SPAM: ---- Start SpamAssassin results
> SPAM: -4.4 hits, 5 required;
> SPAM: * -4.4 -- 'In-Reply-To' line found
> SPAM: * -0.0 -- AWL: Auto-whitelist adjustment
> SPAM:
> SPAM: ---- End of SpamAssassin results
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine3 - RequestTools refreshing
Posted by John McNally <jm...@collab.net>.
I think there is some confusion on refresh() at least there is for me.
The method that was called when an object is returned to the pool is
dispose(). I would generally write
refresh()
{
dispose();
}
or vice versa. and put all the logic in one method.
john mcnally
On Thu, 2002-06-06 at 10:32, Daniel Rall wrote:
> "Peter Lynch" <pe...@mindspring.com> writes:
>
> > ----- Original Message -----
> > From: "James Taylor" <jt...@4lane.com>
> > To: <tu...@jakarta.apache.org>
> > Sent: Tuesday, June 04, 2002 5:02 AM
> > Subject: Re: Turbine3 - RequestTools refreshing
> >
> >
> >> On Mon, 2002-06-03 at 23:41, Evan Koffler wrote:
> >> > I love the new pipeline. It's good to see it coming along.
> >>
> >> Yay! I love the pipeline too, and am glad that it works for you.
> >>
> >> > I have a web flow that uses a request tool to capture inform/error
> >> > messages. In testing, it continued to grow. Basically, because the
> >> > request tools weren't being refreshed. I took a stab at implementing
> >> > the correction. All 10 lines of code. Below is the patch to existing
> >> > code and attached is a new java source file. I tried my best to
> >> > comply.
> >>
> >> As far as releasing tools, that is already done by DefaultTargetValve,
> >> which on line 199 calls Module::requestFinished, which in turn calls
> >> TurbinePull::releaseTools.
> >>
> >> As for refreshing, should this happen when the tools are released or
> >> when they are requested from the pool. Right now request tools always
> >> get initted when they are pulled from the pool, perhaps with the
> >> assumption that init makes refresh unnecessary.
> >>
> >
> > Never could understand why a pull tool would be returned to the pool, without
> > having it's internal object references cleaned up. Otherwise you get a bunch of
> > objects in the pool with stale references to other objects, but since it is in
> > the pool, what is the point.
> >
> > Seems a tool should be 'cleaned' or refreshed before going into the pool. Then
> > on the way out initing still makes sense by itself.
>
> So refresh()'ing on the way back into the pool would be the more
> correct behavior. Peter, if Fulcrum is not already doing this, would
> you be interested in submitting a patch
> <http://jakarta.apache.org/site/source.html> to make it so?
>
> - Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine3 - RequestTools refreshing
Posted by Daniel Rall <dl...@collab.net>.
"Peter Lynch" <pe...@mindspring.com> writes:
> ----- Original Message -----
> From: "James Taylor" <jt...@4lane.com>
> To: <tu...@jakarta.apache.org>
> Sent: Tuesday, June 04, 2002 5:02 AM
> Subject: Re: Turbine3 - RequestTools refreshing
>
>
>> On Mon, 2002-06-03 at 23:41, Evan Koffler wrote:
>> > I love the new pipeline. It's good to see it coming along.
>>
>> Yay! I love the pipeline too, and am glad that it works for you.
>>
>> > I have a web flow that uses a request tool to capture inform/error
>> > messages. In testing, it continued to grow. Basically, because the
>> > request tools weren't being refreshed. I took a stab at implementing
>> > the correction. All 10 lines of code. Below is the patch to existing
>> > code and attached is a new java source file. I tried my best to
>> > comply.
>>
>> As far as releasing tools, that is already done by DefaultTargetValve,
>> which on line 199 calls Module::requestFinished, which in turn calls
>> TurbinePull::releaseTools.
>>
>> As for refreshing, should this happen when the tools are released or
>> when they are requested from the pool. Right now request tools always
>> get initted when they are pulled from the pool, perhaps with the
>> assumption that init makes refresh unnecessary.
>>
>
> Never could understand why a pull tool would be returned to the pool, without
> having it's internal object references cleaned up. Otherwise you get a bunch of
> objects in the pool with stale references to other objects, but since it is in
> the pool, what is the point.
>
> Seems a tool should be 'cleaned' or refreshed before going into the pool. Then
> on the way out initing still makes sense by itself.
So refresh()'ing on the way back into the pool would be the more
correct behavior. Peter, if Fulcrum is not already doing this, would
you be interested in submitting a patch
<http://jakarta.apache.org/site/source.html> to make it so?
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine3 - RequestTools refreshing
Posted by Peter Lynch <pe...@mindspring.com>.
----- Original Message -----
From: "James Taylor" <jt...@4lane.com>
To: <tu...@jakarta.apache.org>
Sent: Tuesday, June 04, 2002 5:02 AM
Subject: Re: Turbine3 - RequestTools refreshing
> On Mon, 2002-06-03 at 23:41, Evan Koffler wrote:
> > I love the new pipeline. It's good to see it coming along.
>
> Yay! I love the pipeline too, and am glad that it works for you.
>
> > I have a web flow that uses a request tool to capture inform/error
> > messages. In testing, it continued to grow. Basically, because the
> > request tools weren't being refreshed. I took a stab at implementing
> > the correction. All 10 lines of code. Below is the patch to existing
> > code and attached is a new java source file. I tried my best to
> > comply.
>
> As far as releasing tools, that is already done by DefaultTargetValve,
> which on line 199 calls Module::requestFinished, which in turn calls
> TurbinePull::releaseTools.
>
> As for refreshing, should this happen when the tools are released or
> when they are requested from the pool. Right now request tools always
> get initted when they are pulled from the pool, perhaps with the
> assumption that init makes refresh unnecessary.
>
Never could understand why a pull tool would be returned to the pool, without
having it's internal object references cleaned up. Otherwise you get a bunch of
objects in the pool with stale references to other objects, but since it is in
the pool, what is the point.
Seems a tool should be 'cleaned' or refreshed before going into the pool. Then
on the way out initing still makes sense by itself.
-Peter
> Should we refresh before init?
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Turbine3 - RequestTools refreshing
Posted by James Taylor <jt...@4lane.com>.
On Mon, 2002-06-03 at 23:41, Evan Koffler wrote:
> I love the new pipeline. It's good to see it coming along.
Yay! I love the pipeline too, and am glad that it works for you.
> I have a web flow that uses a request tool to capture inform/error
> messages. In testing, it continued to grow. Basically, because the
> request tools weren't being refreshed. I took a stab at implementing
> the correction. All 10 lines of code. Below is the patch to existing
> code and attached is a new java source file. I tried my best to
> comply.
As far as releasing tools, that is already done by DefaultTargetValve,
which on line 199 calls Module::requestFinished, which in turn calls
TurbinePull::releaseTools.
As for refreshing, should this happen when the tools are released or
when they are requested from the pool. Right now request tools always
get initted when they are pulled from the pool, perhaps with the
assumption that init makes refresh unnecessary.
Should we refresh before init?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>