Costin,
> > > - I have a
> > > <bean:define id="a" name="foo"/>
> > >
> > > The generated code is:
> > > a = (java.lang.Object) pageContext.findAttribute("a");
> > > a = (java.lang.Object) pageContext.findAttribute("a");
> > > a = (java.lang.Object) pageContext.findAttribute("a");
> > > ( i.e. 3 times the same line ).
> > >
> > > Not a bug, but strange.
> >
> > this turned out to be a bug inherited from the old jasper,
> > which did not synchronize scripting variables at the appropriate
> > places (as outlined in the "Synchronization Protocol" section
> > in JSP.10.5.9).
> >
> > I've just committed a fix for this, which should make jasper2
> > comply with the spec.
>
> This particular problem wasn't a 'compliance' problem - the result
> was still correct, even if computed 3 times.
actually, it has been a compliance problem.
For instance, AT_BEGIN variables used to be synchronized always after
doStartTag(), regardless of whether the tag handler implemented
BodyTag (according to the spec, those variables are supposed to be
synchronized after doStartTag() only if the tag handler does not
implement BodyTag).
Furthermore, AT_BEGIN variables were not synchronized after
doEndTag(), where they should have.
In addition, AT_BEGIN (and NESTED) variables are supposed to be
synchronized after doAfterBody() (if the tag handler implements
BodyTag). In the previous jasper, this requirement was not implemented
correctly (synchronization took place only once):
do {
...
} while (<tagHandlerVar>.doAfterBody() ==
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
}
// Synchronize AT_BEGIN variables
In jasper2, the synchronization is done after each call to
doAfterBody(), like this:
do {
...
int evalDoAfterBody = <tagHandlerVar>.doAfterBody();
// Synchronize AT_BEGIN and NESTED scripting variables
if (evalDoAfterBody != javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
break;
} while (true);
> The real compliance problem that worries me is the AT_END variables
> that get generated at the beginning of the file. I'm pretty sure
> it's quite easy to run into problems with tags that declare typed
> variables, and I'm pretty sure existing applications will brake
> ( mine did - I had to change some variable names ).
>
> And I would bet most jsp implementations in use are doing exactly
> what jasper1 is doing - and changing this will create big problems
> ( while still beeing non-compiant with the spec, and completely
> counterintuitive )
But there also could be applications that expect (based on the spec)
to have access to an AT_END variable where they currently don't (with jasper1).
Those apps will (rightfully) complain that jasper does not follow the spec.
In my opinion the whole scoping issue of scripting variables
is not carefully thought out in JSP 1.2, and it is up to us
to balance conflicting requirements. If there is large consensus
that jasper2 should treat AT_END scripting variables the way jasper1
did, I won't object.
Jan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
