struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Planning for 1.1 beta 2
Date Thu, 27 Jun 2002 02:01:59 GMT
See intermixed.

On Wed, 26 Jun 2002, Martin Cooper wrote:

> Date: Wed, 26 Jun 2002 18:39:04 -0700
> From: Martin Cooper <martin.cooper@tumbleweed.com>
> Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> To: 'Struts Developers List' <struts-dev@jakarta.apache.org>
> Subject: RE: Planning for 1.1 beta 2
>
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > 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 <martin.cooper@tumbleweed.com>
> > > Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> > > To: 'Struts Developers List' <struts-dev@jakarta.apache.org>
> > > Subject: RE: Planning for 1.1 beta 2
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > > > 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 <martin.cooper@tumbleweed.com>
> > > > > Reply-To: Struts Developers List <struts-dev@jakarta.apache.org>
> > > > > To: 'Struts Developers List' <struts-dev@jakarta.apache.org>
> > > > > 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:craigmcc@apache.org]
> > > > > > Sent: Wednesday, June 26, 2002 11:05 AM
> > > > > > To: struts-dev@jakarta.apache.org
> > > > > > 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:struts-dev-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <mailto:struts-dev-help@jakarta.apache.org>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <mailto:struts-dev-help@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <mailto:struts-dev-help@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:struts-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message