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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> writes:
> >>
> >> > ----- Original Message -----
> >> > From: "James Taylor" <[EMAIL PROTECTED]>
> >> > To: <[EMAIL PROTECTED]>
> >> > 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: <mailto:[EMAIL PROTECTED]>
> >> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
> > 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: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
