Re: cvs commit:jakarta-tomcat/src/share/org/apache/jasper/compilerIncludeGenerator.java

[Craig McClanahan <cm...@mytownnet.com>]

Danno Ferrin wrote:

> > mandar      99/10/17 11:40:07
> >
> >   Modified:    src/share/org/apache/jasper/compiler IncludeGenerator.java
> >   Log:
> >   spec compliance:
> >
> >    params in jsp:include to be taken out after return from the include.
> >
>
> Shouldn't the old values be stored and then restored insted of deleted?
> This code will not only allow the new value to over-writer the older value,
> but then all reace of it is gone.  I haven't spent much time looking at it
> and it doesn't seem to be there, but couldn't the old attributes hashtable
> be cloned and pushed off so that when the include returned it could be poped
> back on?  Honestly I could counjure up some degenerate and not so degenerate
> cases where this could come into play.
>

One not-so-degenerate case is nested includes.  If I'm reading the code change
correctly, in the scenario "A includes B, which includes C", the B page can see
the special attributes up to the point where it includes C, but after that it
cannot.

Craig McClanahan

Re: cvs commit:jakarta-tomcat/src/share/org/apache/jasper/compilerIncludeGenerator.java

[Hans Bergsten <ha...@gefionsoftware.com>]

Craig McClanahan wrote:
> 
> Danno Ferrin wrote:
> 
> > > mandar      99/10/17 11:40:07
> > >
> > >   Modified:    src/share/org/apache/jasper/compiler IncludeGenerator.java
> > >   Log:
> > >   spec compliance:
> > >
> > >    params in jsp:include to be taken out after return from the include.
> > >
> >
> > Shouldn't the old values be stored and then restored insted of deleted?
> > This code will not only allow the new value to over-writer the older value,
> > but then all reace of it is gone.  I haven't spent much time looking at it
> > and it doesn't seem to be there, but couldn't the old attributes hashtable
> > be cloned and pushed off so that when the include returned it could be poped
> > back on?  Honestly I could counjure up some degenerate and not so degenerate
> > cases where this could come into play.
> >
> 
> One not-so-degenerate case is nested includes.  If I'm reading the code change
> correctly, in the scenario "A includes B, which includes C", the B page can see
> the special attributes up to the point where it includes C, but after that it
> cannot.

If I'm not completely mistaken, there's another problem here as well: the
<jsp:param> values are attached to the request as "attributes" but the spec
says they should be "parameters", i.e. can be retrieved with getParameter in
the target servlet/JSP.

The Servlet 2.2 spec defines that parameters expressed as a query string in
a getRD URI will be merged with the original request params for the length
of the include/forward call. So my suggestion is that JSP rides on the
servlet container functionality instead of messing with this itself. Just
take all <jsp:param>s and add them as a query string for the "page" attribute.
getRD will then take care of all of this.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com