On Wed, 26 Jun 2002, Martin Cooper wrote:
> Date: Wed, 26 Jun 2002 15:55:19 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Planning for 1.1 beta 2
>
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 26, 2002 12:45 PM
> > To: Struts Developers List
> > Subject: RE: Planning for 1.1 beta 2
> >
> >
> >
> >
> > On Wed, 26 Jun 2002, Martin Cooper wrote:
> >
> > > Date: Wed, 26 Jun 2002 11:49:49 -0700
> > > From: Martin Cooper <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: 'Struts Developers List' <[EMAIL PROTECTED]>
> > > Subject: RE: Planning for 1.1 beta 2
> > >
> > > +1 on Beta 2 soon (although my company isn't shutting down
> > next week :).
> > >
> > > +1 also on reviewing the tags. I fixed one or two of these
> > a while ago -
> > > they showed up after I started using Resin 2.x - but there
> > are likely more
> > > that I didn't stumble across. A systematic review would be good.
> > >
> > > Related to the tag issue, I had the thought that perhaps we
> > should remove
> > > (almost) all of the release() implementations in the Struts
> > tags. I think
> > > many people are confused about when release() is (supposed
> > to be) called,
> > > and the implementations we have foster the belief that it
> > will be called to
> > > reset property values between uses of a tag instance. Or
> > would this be too
> > > drastic a change for now?
> >
> > Aside from the educational benefit (which I'm not sure that I
> > really buy
> > into), releasing object references when the page implementation calls
> > release() would seem to be a good thing to do anyway.
>
> I was thinking that release() is only going to get called when the tag
> instance itself is going away, so those object references will be released
> also. But you're right, it doesn't hurt to do this.
>
> However, I think it would be good to make sure we set everything to null,
> rather than to literals or defined constants, so that it's clear we're not
> trying to reset to a known state.
>
Except that we are ... even though the JSP page compiler doesn't know
anything about it. And that's actually part of the problem. Our docs
promise that some attributes will behave as if they have default values,
which we've implemented by pre-initializing the corresponding property
values.
Everything works fine if tags aren't reused, or the tag implementation
never modifies the values of the attributes set by the generated code of
the page. However, if either of these conditions is violated, we're going
to have problems with the wrong value the second time through the use of a
tag instance, if the value was not set from the tag but was modified the
first time through.
That's a long winded way of saying I think I agree with Martin that we
need to clear everything in release(). That also implies we need to
establish a convention to establish the initial state of things -- perhaps
by overriding setPageContext() which is guaranteed to be called each time.
> > I'd rather point people to the spec (which, in JSP 1.2, has very clear
> > lifecycle diagrams showing how it works, in section 10.1) and
> > ensure that
> > our tags take advantage of everything the spec lets us do to improve
> > performance.
>
> Yes, I've pointed numerous people to the JSP 1.2 spec on exactly this issue.
>
> --
> Martin Cooper
>
Craig
> >
> > >
> > > --
> > > Martin Cooper
> > >
> >
> > Craig
> >
> >
> > >
> > > > -----Original Message-----
> > > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, June 26, 2002 11:05 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Planning for 1.1 beta 2
> > > >
> > > >
> > > > I'd like to continue swatting the remaining bugs in 1.1, and
> > > > improve the
> > > > existing documentation, with a goal to release a beta 2 of
> > > > Strust 1.1 in
> > > > the near future (ideally by July 8 or so). Part of my
> > > > motivation for the
> > > > timing is that Sun is shutting down next week, so I will have
> > > > some quality
> > > > time hours available when I'm actually awake :-).
> > > >
> > > > Are the other committers interested in working towards
> > such a goal?
> > > >
> > > > One thing I'd like to add to the TODO list is a review of all
> > > > our custom
> > > > tag implementations versus the JSP spec requirements --
> > > > particularly in
> > > > the area of tag pooling and when the bodyContent can be
> > accessed. The
> > > > recent work on Jasper2 (in Tomcat 4.1.x), which will support
> > > > tag pooling,
> > > > has indicated we probably have some tags that don't
> > > > completely conform to
> > > > the contracts -- and we need to fix that before any final release.
> > > >
> > > > Craig
> > > >
> > > >
> > > >
> > > > --
> > > > 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]>
> > >
> > >
> >
> >
> > --
> > 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
