See intermixed. On Wed, 26 Jun 2002, Martin Cooper wrote:
> Date: Wed, 26 Jun 2002 18:39:04 -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 4:44 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 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. > > If the tag implementation (not including release()) modifies the values of > properties, then yes, we're in big trouble. This is the case I've come > across before. > I thought we had caught all of those, but want to make very sure. For example, if the second use of a tag sets the same value for the same attribute on an instance being reused, the container has the right to assume that the previous setFoo() call is still in effect. > If I'm understanding you correctly, you're saying that release() also causes > a problem by modifying the values. The only way I can see this would happen > is if the container called release() and then reused the tag. At first, I > thought this wasn't legal, but looking at the spec again, I see that it is > in fact permitted. It wouldn't make much sense, performance wise, for a > container to do that, but it could, so I guess we have to deal with it. > True ... and it would be our code that is making the incorrect assumptions, not the container. > > 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 don't think we can use setPageContext(), though, or setParent(), without > some pain. As far as I can tell, the spec does not require that these be > called before the attribute properties are set. If they are, then we could > set the defaults there. However, if they're not, we'd have to keep track of > which properties were set, so that we would know which ones not to meddle > with. > Grumble, we can't use setPageContext() because it's not guaranteed to be called in between reuse, and setParent() won't work anyway for non-nested tags. > -- > Martin Cooper > Craig > > > > 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]> > > > > -- > 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]>
