You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Reinhard Pilz <rp...@faw.uni-linz.ac.at> on 2000/03/30 15:11:05 UTC
When calling another servlet/jsp from a .jsp-file with
<jsp:include....>
<jsp:param.../>
</jsp:include>
or with
pageContext.include("page.jsp?param=value")
Tomcat seems the overwrite the old values of already existing request
parameters with the values specified with the page to include.
According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the included
page should see the old AND the new values.
Am I right?
Or is Tomcat right?
thanks, reinhard
Re:
Posted by "Anil K. Vijendran" <An...@eng.sun.com>.
alex,
thanks for your test case. i'll look into it soon.
Alex Yiu wrote:
> Hi,
>
> I have checked with Tomcat 3.1 beta 1.
> The problem still exists. It does not conform to the spec. Jasper folks,
> maybe you want to add this to the Watchdog test case. Thanks.
>
> Here is a test case:
> =======================================================
> incl01.jsp:
> =======================================================
> <pre>
> incl01.jsp
> <%= new java.util.Date() %>
> <%= request.getParameter("abc") %>
> <jsp:include page="incl02.jsp" flush="true" />
> <jsp:include page="incl02.jsp?abc=ghi" flush="true" />
> <jsp:include page="incl02.jsp?abc=ghi&abc=jkl" flush="true" />
> <jsp:include page="incl02.jsp" flush="true" >
> <jsp:param name="abc" value="jkl" />
> </jsp:include>
> <jsp:include page="incl02.jsp" flush="true" >
> <jsp:param name="abc" value="jkl" />
> <jsp:param name="abc" value="mno" />
> </jsp:include>
> <jsp:include page="incl02.jsp" flush="true" />
> </pre>
> =======================================================
> incl02.jsp:
> =======================================================
> incl02.jsp
> <%= request.getParameter("abc") %>
> <%
> String s[]=request.getParameterValues("abc");
> if (s!=null)
> for (int i=0; i<s.length; i++)
> {
> out.println(i+"="+s[i]);
> }
> %>
> =======================================================
> The result:
> =======================================================
> incl01.jsp
> Thu Mar 30 14:04:30 PST 2000
> def
> incl02.jsp
> def
> 0=def
>
> incl02.jsp
> ghi
> 0=ghi
>
> incl02.jsp
> ghi
> 0=ghi
> 1=jkl
>
> incl02.jsp (* wrong behavior here #A *)
> jkl
> 0=jkl
>
> incl02.jsp (* wrong behavior here #B *)
> jkl
> 0=jkl
> 1=mno
>
> incl02.jsp
> def
> 0=def
> =======================================================
> Right behavior:
> =======================================================
> incl02.jsp (* right behavior here #A *)
> jkl
> 0=jkl
> 1=def
>
> incl02.jsp (* right behavior here #B *)
> jkl
> 0=jkl
> 1=mno
> 2=def
> =======================================================
>
> Thanks.
>
> Regards,
> Alex Yiu
>
> Hans Bergsten wrote:
> >
> > Reinhard Pilz wrote:
> > >
> > > When calling another servlet/jsp from a .jsp-file with
> > >
> > > <jsp:include....>
> > > <jsp:param.../>
> > > </jsp:include>
> > >
> > > or with
> > >
> > > pageContext.include("page.jsp?param=value")
> > >
> > > Tomcat seems the overwrite the old values of already existing request
> > > parameters with the values specified with the page to include.
> > >
> > > According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the included
> > > page should see the old AND the new values.
> > >
> > > Am I right?
> > > Or is Tomcat right?
> >
> > Have you tested this with Tomcat 3.1 Beta? I know there were a lot of
> > problems in this area in Tomcat 3.0, but as far as I know they have all
> > been fixed in 3.1 Beta.
> >
> > Hans
> > --
> > Hans Bergsten hans@gefionsoftware.com
> > Gefion Software http://www.gefionsoftware.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
>
> --
> ==================================================================
> Alex Yiu
> Java Product Group, LORT, ST Email: ayiu@us.oracle.com
> Oracle Corporation Phone: (650) 506-4522
> Mailstop: 4op9 Fax: (650) 633-2349
> 500 Oracle Parkway,
> Redwood Shores, CA 94065
> ==================================================================
>
> **----------------- I think, therefore I am. ----------------**
> ** The statements and opinions expressed here are my own and **
> ** do not necessarily represent those of Oracle Corporation. **
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
Peace, Anil +<:-)
Re:
Posted by Costin Manolache <co...@eng.sun.com>.
Hi Alex,
The nightly ( or hourly ) script is back on line, can you please check the latest
one ?
It seems to work better, except:
> <jsp:include page="incl02.jsp?abc=ghi" flush="true" />
Will print out:
ghi
0=ghi
1=def
> <jsp:include page="incl02.jsp?abc=ghi&abc=jkl" flush="true" />
0=ghi
1=jkl
2=def
Same for <jsp:param/> case.
Let me know if we can close the bug.
( Craig fixed a related bug )
Costin
Re:
Posted by pauly <pa...@x-radio.com>.
I don't know if there's a separate jetspeed mailing list -- i looked on
the site but didn't see one, but here's a bug i found.
i downloaded the latest jetspeed-1.1 distribution and tried to compile it
with ant, but it didn't work -- it kept creating a null directory and then
ending with success. so.....
i noticed that there seemed to be a dependency missing. i added the
following lines...
<project name="JetSpeed" default="dist" basedir=".">
####> <target name="init">
<property name="version" value="1.1"/>
...
END Stylebook support
-->
###>>> </target>
and added the "init" dependency to the core target, as such:
<target name="core" depends="init">
it works now. you might want to fix this.
Re:
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Alex Yiu wrote:
>
> Hi,
>
> I have checked with Tomcat 3.1 beta 1.
> The problem still exists. It does not conform to the spec. Jasper folks,
> maybe you want to add this to the Watchdog test case. Thanks.
Please log it as a bug in Bugzilla as well so it can be tracked.
Thanks,
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re:
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Alex Yiu wrote:
>
> Hi,
>
> I have checked with Tomcat 3.1 beta 1.
> The problem still exists. It does not conform to the spec. Jasper folks,
> maybe you want to add this to the Watchdog test case. Thanks.
Please log it as a bug in Bugzilla as well so it can be tracked.
Thanks,
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re:
Posted by Alex Yiu <ay...@us.oracle.com>.
Hi,
I have checked with Tomcat 3.1 beta 1.
The problem still exists. It does not conform to the spec. Jasper folks,
maybe you want to add this to the Watchdog test case. Thanks.
Here is a test case:
=======================================================
incl01.jsp:
=======================================================
<pre>
incl01.jsp
<%= new java.util.Date() %>
<%= request.getParameter("abc") %>
<jsp:include page="incl02.jsp" flush="true" />
<jsp:include page="incl02.jsp?abc=ghi" flush="true" />
<jsp:include page="incl02.jsp?abc=ghi&abc=jkl" flush="true" />
<jsp:include page="incl02.jsp" flush="true" >
<jsp:param name="abc" value="jkl" />
</jsp:include>
<jsp:include page="incl02.jsp" flush="true" >
<jsp:param name="abc" value="jkl" />
<jsp:param name="abc" value="mno" />
</jsp:include>
<jsp:include page="incl02.jsp" flush="true" />
</pre>
=======================================================
incl02.jsp:
=======================================================
incl02.jsp
<%= request.getParameter("abc") %>
<%
String s[]=request.getParameterValues("abc");
if (s!=null)
for (int i=0; i<s.length; i++)
{
out.println(i+"="+s[i]);
}
%>
=======================================================
The result:
=======================================================
incl01.jsp
Thu Mar 30 14:04:30 PST 2000
def
incl02.jsp
def
0=def
incl02.jsp
ghi
0=ghi
incl02.jsp
ghi
0=ghi
1=jkl
incl02.jsp (* wrong behavior here #A *)
jkl
0=jkl
incl02.jsp (* wrong behavior here #B *)
jkl
0=jkl
1=mno
incl02.jsp
def
0=def
=======================================================
Right behavior:
=======================================================
incl02.jsp (* right behavior here #A *)
jkl
0=jkl
1=def
incl02.jsp (* right behavior here #B *)
jkl
0=jkl
1=mno
2=def
=======================================================
Thanks.
Regards,
Alex Yiu
Hans Bergsten wrote:
>
> Reinhard Pilz wrote:
> >
> > When calling another servlet/jsp from a .jsp-file with
> >
> > <jsp:include....>
> > <jsp:param.../>
> > </jsp:include>
> >
> > or with
> >
> > pageContext.include("page.jsp?param=value")
> >
> > Tomcat seems the overwrite the old values of already existing request
> > parameters with the values specified with the page to include.
> >
> > According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the included
> > page should see the old AND the new values.
> >
> > Am I right?
> > Or is Tomcat right?
>
> Have you tested this with Tomcat 3.1 Beta? I know there were a lot of
> problems in this area in Tomcat 3.0, but as far as I know they have all
> been fixed in 3.1 Beta.
>
> Hans
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
==================================================================
Alex Yiu
Java Product Group, LORT, ST Email: ayiu@us.oracle.com
Oracle Corporation Phone: (650) 506-4522
Mailstop: 4op9 Fax: (650) 633-2349
500 Oracle Parkway,
Redwood Shores, CA 94065
==================================================================
**----------------- I think, therefore I am. ----------------**
** The statements and opinions expressed here are my own and **
** do not necessarily represent those of Oracle Corporation. **
Re:
Posted by Alex Yiu <ay...@us.oracle.com>.
Hi,
I have checked with Tomcat 3.1 beta 1.
The problem still exists. It does not conform to the spec. Jasper folks,
maybe you want to add this to the Watchdog test case. Thanks.
Here is a test case:
=======================================================
incl01.jsp:
=======================================================
<pre>
incl01.jsp
<%= new java.util.Date() %>
<%= request.getParameter("abc") %>
<jsp:include page="incl02.jsp" flush="true" />
<jsp:include page="incl02.jsp?abc=ghi" flush="true" />
<jsp:include page="incl02.jsp?abc=ghi&abc=jkl" flush="true" />
<jsp:include page="incl02.jsp" flush="true" >
<jsp:param name="abc" value="jkl" />
</jsp:include>
<jsp:include page="incl02.jsp" flush="true" >
<jsp:param name="abc" value="jkl" />
<jsp:param name="abc" value="mno" />
</jsp:include>
<jsp:include page="incl02.jsp" flush="true" />
</pre>
=======================================================
incl02.jsp:
=======================================================
incl02.jsp
<%= request.getParameter("abc") %>
<%
String s[]=request.getParameterValues("abc");
if (s!=null)
for (int i=0; i<s.length; i++)
{
out.println(i+"="+s[i]);
}
%>
=======================================================
The result:
=======================================================
incl01.jsp
Thu Mar 30 14:04:30 PST 2000
def
incl02.jsp
def
0=def
incl02.jsp
ghi
0=ghi
incl02.jsp
ghi
0=ghi
1=jkl
incl02.jsp (* wrong behavior here #A *)
jkl
0=jkl
incl02.jsp (* wrong behavior here #B *)
jkl
0=jkl
1=mno
incl02.jsp
def
0=def
=======================================================
Right behavior:
=======================================================
incl02.jsp (* right behavior here #A *)
jkl
0=jkl
1=def
incl02.jsp (* right behavior here #B *)
jkl
0=jkl
1=mno
2=def
=======================================================
Thanks.
Regards,
Alex Yiu
Hans Bergsten wrote:
>
> Reinhard Pilz wrote:
> >
> > When calling another servlet/jsp from a .jsp-file with
> >
> > <jsp:include....>
> > <jsp:param.../>
> > </jsp:include>
> >
> > or with
> >
> > pageContext.include("page.jsp?param=value")
> >
> > Tomcat seems the overwrite the old values of already existing request
> > parameters with the values specified with the page to include.
> >
> > According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the included
> > page should see the old AND the new values.
> >
> > Am I right?
> > Or is Tomcat right?
>
> Have you tested this with Tomcat 3.1 Beta? I know there were a lot of
> problems in this area in Tomcat 3.0, but as far as I know they have all
> been fixed in 3.1 Beta.
>
> Hans
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
==================================================================
Alex Yiu
Java Product Group, LORT, ST Email: ayiu@us.oracle.com
Oracle Corporation Phone: (650) 506-4522
Mailstop: 4op9 Fax: (650) 633-2349
500 Oracle Parkway,
Redwood Shores, CA 94065
==================================================================
**----------------- I think, therefore I am. ----------------**
** The statements and opinions expressed here are my own and **
** do not necessarily represent those of Oracle Corporation. **
RE:
Posted by Reinhard Pilz <rp...@faw.uni-linz.ac.at>.
I've downloaded the latest source of 3.1 beta.
> -----Original Message-----
> From: Hans Bergsten [mailto:hans@gefionsoftware.com]
> Sent: Thursday, March 30, 2000 8:14 PM
> To: general@jakarta.apache.org
> Subject: Re: <jsp:param>
>
>
> Reinhard Pilz wrote:
> >
> > When calling another servlet/jsp from a .jsp-file with
> >
> > <jsp:include....>
> > <jsp:param.../>
> > </jsp:include>
> >
> > or with
> >
> > pageContext.include("page.jsp?param=value")
> >
> > Tomcat seems the overwrite the old values of already existing request
> > parameters with the values specified with the page to include.
> >
> > According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6,
> the included
> > page should see the old AND the new values.
> >
> > Am I right?
> > Or is Tomcat right?
>
> Have you tested this with Tomcat 3.1 Beta? I know there were a lot of
> problems in this area in Tomcat 3.0, but as far as I know they have all
> been fixed in 3.1 Beta.
>
> Hans
> --
> Hans Bergsten hans@gefionsoftware.com
> Gefion Software http://www.gefionsoftware.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re:
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Reinhard Pilz wrote:
>
> When calling another servlet/jsp from a .jsp-file with
>
> <jsp:include....>
> <jsp:param.../>
> </jsp:include>
>
> or with
>
> pageContext.include("page.jsp?param=value")
>
> Tomcat seems the overwrite the old values of already existing request
> parameters with the values specified with the page to include.
>
> According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the included
> page should see the old AND the new values.
>
> Am I right?
> Or is Tomcat right?
Have you tested this with Tomcat 3.1 Beta? I know there were a lot of
problems in this area in Tomcat 3.0, but as far as I know they have all
been fixed in 3.1 Beta.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Re: ANT tag
Posted by William Uther <wi...@cs.cmu.edu>.
Hi,
This 'fix' doesn't work on some systems. I'm not sure which system
caused problems for Costin, but it fails on a Mac.
File.getCanonicalPath() is system dependant. In particular, on a Mac,
the filename returned ends in a '/'. This is different to the behaviour of
File.getAbsolutePath(). Hence, these will never be equal on a mac. You
can fix this by normalizing for the existance of a '/' at the end of the
paths.
Also, the simple existance test shown below tests if there is a symlink
anywhere in the path, NOT if the path target is a symlink. I believe there
was other code elsewhere that got the canonical path when you started to
remove all other symlinks but, based on Costin's report, this didn't work
all the time.
later,
\x/ill :-}
--On Tuesday, April 4, 2000 12:11 AM -0700 ja@almery.com wrote:
> jon * writes:
> > on 4/2/00 10:27 PM, ja@almery.com <ja...@almery.com> wrote:
> >
> > > I can't convince cvs to allow me to log in (anonymously) to get the
> > > latest source, but at one time this also happened to me. I submitted
> > > a patch, which tested to see if the "directory" was a symlink, and
> > > ignored it if it was. The patch was committed by someone, and all
> > > seemed well.
> >
> > submit the patch again...i will get it checked in.
> >
> > really this conversation should be going on the ant-dev mailing list.
>
> I looked at the source via cvsweb (I wonder why my logins time out
> with "regular" anonymous cvs?) and noticed that costin commented out
> the "fix"
>
> // if
> (dir.getCanonicalPath().equals(dir.getAbsolutePath())) { //
> (costin) It will not work if /home/costin is symlink to
> /da0/home/costin ( taz // for example )
>
> So, it looks as though the dangerous behaviour of Deltree has
> returned.
>
> --
> Jay Doane | doane@acm.org
Re: ANT tag
Posted by ja...@almery.com.
jon * writes:
> on 4/2/00 10:27 PM, ja@almery.com <ja...@almery.com> wrote:
>
> > I can't convince cvs to allow me to log in (anonymously) to get the
> > latest source, but at one time this also happened to me. I submitted
> > a patch, which tested to see if the "directory" was a symlink, and
> > ignored it if it was. The patch was committed by someone, and all
> > seemed well.
>
> submit the patch again...i will get it checked in.
>
> really this conversation should be going on the ant-dev mailing list.
I looked at the source via cvsweb (I wonder why my logins time out
with "regular" anonymous cvs?) and noticed that costin commented out
the "fix"
// if (dir.getCanonicalPath().equals(dir.getAbsolutePath())) {
// (costin) It will not work if /home/costin is symlink to /da0/home/costin ( taz
// for example )
So, it looks as though the dangerous behaviour of Deltree has
returned.
--
Jay Doane | doane@acm.org
Re: ANT tag
Posted by jon * <jo...@clearink.com>.
on 4/2/00 10:27 PM, ja@almery.com <ja...@almery.com> wrote:
> I can't convince cvs to allow me to log in (anonymously) to get the
> latest source, but at one time this also happened to me. I submitted
> a patch, which tested to see if the "directory" was a symlink, and
> ignored it if it was. The patch was committed by someone, and all
> seemed well.
submit the patch again...i will get it checked in.
really this conversation should be going on the ant-dev mailing list.
-jon
ANT tag
Posted by ja...@almery.com.
pauly writes:
> Quick question: Does Ant follow symlinks when it's deleting trees? The
> reason I ask is because I had some _very_ important items symlinked into
> my development tomcat webapps directory and after executing $(ANT) clean
> they've disappeared.
I can't convince cvs to allow me to log in (anonymously) to get the
latest source, but at one time this also happened to me. I submitted
a patch, which tested to see if the "directory" was a symlink, and
ignored it if it was. The patch was committed by someone, and all
seemed well.
> Is this right???
No, it sucks.
--
Jay Doane | doane@acm.org
ANT tag
Posted by pauly <pa...@x-radio.com>.
Quick question: Does Ant follow symlinks when it's deleting trees? The
reason I ask is because I had some _very_ important items symlinked into
my development tomcat webapps directory and after executing $(ANT) clean
they've disappeared. Is this right???
Re:
Posted by Brill Pappin <br...@jmonkey.com>.
I'm talking about:
javax.servlet.ServletRequest.getParameterValues(String)::String[]
As I see it, the engine can't assume that the old value should be "replaced"
for the current request... and the servlet API does provide a method for
dealing with multiple parameters of the same name.
- Brill Pappin
----- Original Message -----
From: "Reinhard Pilz" <rp...@faw.uni-linz.ac.at>
To: <ge...@jakarta.apache.org>
Sent: Thursday, March 30, 2000 11:59 AM
Subject: RE: <jsp:param>
> I'm not sure what you mean with "as arrays".
>
> I've attached two JSP-Files in this mail.
>
> ParamCheck.jsp includes the output of ParamCheck2.jsp with
> <jsp:include page="ParamCheck2.jsp">
> <jsp:param name="param" value="B"/>
> </jsp:include>
> into its response.
>
> If I call ParamCheck.jsp?param=A I get something like that:
>
> - param=A BEFORE the include-statement
> - param=B DURING the include-statement
> - param=A AFTER the include-statement
>
> whereas I expect:
>
> - param=A BEFORE the include-statement
> - param=B,A DURING the include-statement
> - param=A AFTER the include-statement
>
>
> I even looked it up in the tomcat source files.
>
> The Method addQueryString() of the class
> org.apache.tomcat.core.RequestDispatchImpl just retrieves the request
> parameters of the included URL and inserts them into the Hashtable
> containing the parameter values. The method doesn't check, if the
Hashtable
> already contains a parameter with the same name. As it uses for the key in
> Hashtable.put(..) the name of the parameter, previous parameters with the
> same name get lost.
>
> I'm sure, it is easily done to apply the required changes to change the
> behaviour, but I'm not sure, which version is the right one.
>
> Well, thats actually my question - which version IS right?
>
>
> Reinhad Pilz
>
>
>
> > -----Original Message-----
> > From: Brill Pappin [mailto:brill@jmonkey.com]
> > Sent: Thursday, March 30, 2000 5:55 PM
> > To: general@jakarta.apache.org
> > Subject: Re: <jsp:param>
> >
> >
> > Are you sure they are being overwritten, or is it passing values with
the
> > same name, as arrays?
> >
> > - Brill Pappin
> >
> > ----- Original Message -----
> > From: "Reinhard Pilz" <rp...@faw.uni-linz.ac.at>
> > To: <ge...@jakarta.apache.org>
> > Sent: Thursday, March 30, 2000 8:11 AM
> > Subject: <jsp:param>
> >
> >
> > > When calling another servlet/jsp from a .jsp-file with
> > >
> > > <jsp:include....>
> > > <jsp:param.../>
> > > </jsp:include>
> > >
> > > or with
> > >
> > > pageContext.include("page.jsp?param=value")
> > >
> > > Tomcat seems the overwrite the old values of already existing request
> > > parameters with the values specified with the page to include.
> > >
> > > According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the
> > included
> > > page should see the old AND the new values.
> > >
> > > Am I right?
> > > Or is Tomcat right?
> > >
> > > thanks, reinhard
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
RE:
Posted by Reinhard Pilz <rp...@faw.uni-linz.ac.at>.
I'm not sure what you mean with "as arrays".
I've attached two JSP-Files in this mail.
ParamCheck.jsp includes the output of ParamCheck2.jsp with
<jsp:include page="ParamCheck2.jsp">
<jsp:param name="param" value="B"/>
</jsp:include>
into its response.
If I call ParamCheck.jsp?param=A I get something like that:
- param=A BEFORE the include-statement
- param=B DURING the include-statement
- param=A AFTER the include-statement
whereas I expect:
- param=A BEFORE the include-statement
- param=B,A DURING the include-statement
- param=A AFTER the include-statement
I even looked it up in the tomcat source files.
The Method addQueryString() of the class
org.apache.tomcat.core.RequestDispatchImpl just retrieves the request
parameters of the included URL and inserts them into the Hashtable
containing the parameter values. The method doesn't check, if the Hashtable
already contains a parameter with the same name. As it uses for the key in
Hashtable.put(..) the name of the parameter, previous parameters with the
same name get lost.
I'm sure, it is easily done to apply the required changes to change the
behaviour, but I'm not sure, which version is the right one.
Well, thats actually my question - which version IS right?
Reinhad Pilz
> -----Original Message-----
> From: Brill Pappin [mailto:brill@jmonkey.com]
> Sent: Thursday, March 30, 2000 5:55 PM
> To: general@jakarta.apache.org
> Subject: Re: <jsp:param>
>
>
> Are you sure they are being overwritten, or is it passing values with the
> same name, as arrays?
>
> - Brill Pappin
>
> ----- Original Message -----
> From: "Reinhard Pilz" <rp...@faw.uni-linz.ac.at>
> To: <ge...@jakarta.apache.org>
> Sent: Thursday, March 30, 2000 8:11 AM
> Subject: <jsp:param>
>
>
> > When calling another servlet/jsp from a .jsp-file with
> >
> > <jsp:include....>
> > <jsp:param.../>
> > </jsp:include>
> >
> > or with
> >
> > pageContext.include("page.jsp?param=value")
> >
> > Tomcat seems the overwrite the old values of already existing request
> > parameters with the values specified with the page to include.
> >
> > According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the
> included
> > page should see the old AND the new values.
> >
> > Am I right?
> > Or is Tomcat right?
> >
> > thanks, reinhard
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re:
Posted by Brill Pappin <br...@jmonkey.com>.
Are you sure they are being overwritten, or is it passing values with the
same name, as arrays?
- Brill Pappin
----- Original Message -----
From: "Reinhard Pilz" <rp...@faw.uni-linz.ac.at>
To: <ge...@jakarta.apache.org>
Sent: Thursday, March 30, 2000 8:11 AM
Subject: <jsp:param>
> When calling another servlet/jsp from a .jsp-file with
>
> <jsp:include....>
> <jsp:param.../>
> </jsp:include>
>
> or with
>
> pageContext.include("page.jsp?param=value")
>
> Tomcat seems the overwrite the old values of already existing request
> parameters with the values specified with the page to include.
>
> According to the JSP1.1 Spec. (Nov. 30, 1999), Section 2.13.6, the
included
> page should see the old AND the new values.
>
> Am I right?
> Or is Tomcat right?
>
> thanks, reinhard
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>