DO NOT REPLY [Bug 36247] New: - Jasper jsp:include page=foo.xml/ throws IllegalStateException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36247. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36247 Summary: Jasper jsp:include page=foo.xml/ throws IllegalStateException Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] %@ page language=java contentType=text/xml% jsp:include page=sample.xml/ the above jsp causes an IllegalStateException the following is just fine: (the files are identical) %@ page language=java contentType=text/xml% jsp:include page=sample.html/ My guess is that someone is messing about with the outputStream in order to get the XML encoding sorted... still surely the contentType drives this not the file extension? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jsp:include forwarding from included resource, revisited
Hi, guys! I am bothering you again with my JSP include/forward/redirect problem. I am not able to comment on JSP53 spec, so I thought that since Tomcat is reference implementation of JSP, then you guys may have some influence on JSP standard. To recap, my problem is that I have a resource, included in JSP page. The included resource (in my case a struts action, but can be a servlet) performs forward (or redirect, or redirect and then forward), to a location with actual content (currently, JSP page). The problem I am having is that response stream is closed after my included resource is processed, and the rest part of parent page is not processed. I was pointed to the spec: JSP version 2.4, section 8.4 reads: Before the forward method of the RequestDispatcher interface returns, the response content must be sent and committed, and closed by the servlet container. I want it to be changed to something like this: Before the forward method of the RequestDispatcher interface returns, the response content must be sent and committed, and closed by the servlet container, UNLESS REQUEST TO FORWARD METHOD WAS NOT INCLUDED INTO ANOTHER REQUEST. Here is the reason: I want to be able to create components in JSP using jsp:include. I want to be able to jsp:include serlvets or Struts actions or other request-processing modules, which then would forward to (or redirect to) actual content - a result page, which would become a piece in the main page. I cannot apply clean MVC model within current JSP standard: resource that I include, must generate output itself. This is against good style and brings us back to dark ages of web programming. If anyone from this group had a chance to bring attention of JSR53 members to this issue, I would be glad to hear about the progress. Thanks, Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Indirect jsp:include does not seem to work
Hello all, I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. I looked in the code. ApplicationDispatcher correctly identifies the first request to strutsAction.do as Path Based Include. But when struts action forwards to detail jsp, ApplicationDispatcher identifies it as Path Based Forward. doForward() is called instead of doInclude(), and ApplicationDispatcher flushes and closes the response writer. Thus, Jasper cannot write the rest of master page content to writer, and throws org.apache.jasper.JasperException: Stream closed. Without thinking much, I commented out writer flushing in ApplicationDispatcher.doForward(). It seems to work on Tomcat 4.1.31, but failed on Tomcat 5.0. Anyway, I am not sure that I did a right thing and that all buffers are properly being closed now. Would be great if Tomcat devs look into it. Btw, Jetty does not work as I want, too. BUT: I tried to create a proxy JSP page, which is included in main JSP page. This proxy page includes strutsAction.do, which forwards to real JSP page that I want to include (whew!) Jetty works perfectly fine with this proxy JSP page! Also, Resin works fine both with direct including of struts action from main page, and with proxy JSP page. So, I believe that this is a Tomcat bug. Thanks, Michael Jouravlev. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not work
I found bug #21440 in ASF bug database which looks awful like the one I have. It was entered in July, 2003 and is still not resolved. Tomcat devs considered against attempting to fix this bug (if confirmed it is actually one) in 4.1.x. and that its severity 'minor', since this is a corner case that should not occur often. I am sorry, this is not the corner case. I need this functionality. And considering that my hosting provider uses Tomcat 4.x, I might be able to persuade him to use a patch, if it were available. My provider does not have intentions to switch to Tomcat 5 now (which has this bug too, by the way). Resin works, and Jetty works with a proxy JSP page. So, for development I can use other servlet containers, but I need Tomcat to be patched for production, including 4.x (at least 4.1.x). I tested my app on 4.0.6, 4.1.31 and 5.0.28, it did not work. Thank you, Michael. I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. [skipped] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=21440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21440 --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 20:39 --- (In reply to comment #2) Agree this is severity 'minor', since this is a corner case that should not occur often. ... I think I am against attempting to fix this bug (if confirmed it is actually one) in 4.1.x. This bug does not seem to be fixed yet. This functionality is needed, it is not a corner case. Tomcat 5.0.28 seem to have this bug too. Please, fix it, including Tomcat 4.1.x too. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
You cannot perform a forward inside an include. [Just like you can't set any headers, including cookies, in an include or a host of other things while in an include.] -Tim Michael J. wrote: Hello all, I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. I looked in the code. ApplicationDispatcher correctly identifies the first request to strutsAction.do as Path Based Include. But when struts action forwards to detail jsp, ApplicationDispatcher identifies it as Path Based Forward. doForward() is called instead of doInclude(), and ApplicationDispatcher flushes and closes the response writer. Thus, Jasper cannot write the rest of master page content to writer, and throws org.apache.jasper.JasperException: Stream closed. Without thinking much, I commented out writer flushing in ApplicationDispatcher.doForward(). It seems to work on Tomcat 4.1.31, but failed on Tomcat 5.0. Anyway, I am not sure that I did a right thing and that all buffers are properly being closed now. Would be great if Tomcat devs look into it. Btw, Jetty does not work as I want, too. BUT: I tried to create a proxy JSP page, which is included in main JSP page. This proxy page includes strutsAction.do, which forwards to real JSP page that I want to include (whew!) Jetty works perfectly fine with this proxy JSP page! Also, Resin works fine both with direct including of struts action from main page, and with proxy JSP page. So, I believe that this is a Tomcat bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
Here is what I found at: http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html#8828 The jsp:include element allows you to include either a static or dynamic resource in a JSP page. The results of including static and dynamic resources are quite different. If the resource is static, its content is included in the calling JSP page. If the resource is dynamic, it acts on a request and sends back a result that is included in the JSP page. When the include action is finished, the JSP container continues processing the remainder of the JSP page. So, what I am doing is perfectly legitimate. I include a dynamic resource (spec does not clarify the type of resource or its nesting level). It should return result, to be included in the main page. And JSP container continues processing the remainder of the JSP page, which Tomcat does not do. It is a bug. Resin works exactly as I expect, and Jetty works too with a proxy JSP page. I have not tried other servers yet. Thank you, Michael. On Apr 1, 2005 10:39 AM, Tim Funk [EMAIL PROTECTED] wrote: You cannot perform a forward inside an include. [Just like you can't set any headers, including cookies, in an include or a host of other things while in an include.] -Tim Michael J. wrote: Hello all, I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. I looked in the code. ApplicationDispatcher correctly identifies the first request to strutsAction.do as Path Based Include. But when struts action forwards to detail jsp, ApplicationDispatcher identifies it as Path Based Forward. doForward() is called instead of doInclude(), and ApplicationDispatcher flushes and closes the response writer. Thus, Jasper cannot write the rest of master page content to writer, and throws org.apache.jasper.JasperException: Stream closed. Without thinking much, I commented out writer flushing in ApplicationDispatcher.doForward(). It seems to work on Tomcat 4.1.31, but failed on Tomcat 5.0. Anyway, I am not sure that I did a right thing and that all buffers are properly being closed now. Would be great if Tomcat devs look into it. Btw, Jetty does not work as I want, too. BUT: I tried to create a proxy JSP page, which is included in main JSP page. This proxy page includes strutsAction.do, which forwards to real JSP page that I want to include (whew!) Jetty works perfectly fine with this proxy JSP page! Also, Resin works fine both with direct including of struts action from main page, and with proxy JSP page. So, I believe that this is a Tomcat bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
Michael J. wrote: Here is what I found at: http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html#8828 [snip] So, what I am doing is perfectly legitimate... A syntax reference is not the same as a specification. Specifications are (supposedly) more rigorous and more precise in their specification of required behaviour. Tomcat is the reference implementation for the Servlet and JSP specifications. It might be helpful if everybody who is interested in this discussion could please read JSP4.5 (section 4.5 of the JSP spec, version 1.2, since you are talking about Tomcat 4). See also SRV.8, that is, section 8 of the Servlet spec (Version 2.3, for Tomcat 4), which defines how the underlying include and forward mechanisms work; pay particular attention to sections 8.3 and 8.4 (compare the first lines of each of those sections). Resin works exactly as I expect, and Jetty works too with a proxy JSP page. I have not tried other servers yet. I have experienced this error too, and I wish Tomcat worked that way, but I haven't yet found anything in the Specifications that would allow me to change how it works :-) As implied by the spec, there may be different results depending on the sizes of buffers used by the implementation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
A syntax reference is not the same as a specification. Specifications are (supposedly) more rigorous and more precise in their specification of required behaviour. Tomcat is the reference implementation for the Servlet and JSP specifications. It might be helpful if everybody who is interested in this discussion could please read [spec list skipped] I will read the specs, but I am having a deja vu: California Driver's Handbook is for drivers, who don't know how to drive anyway. It is just a funny comics pamphlet. California Vehicle Code is a real thing for cops, and contains all the proper rules. spec-quote version=2.4 section=8.4 Before the forward method of the RequestDispatcher interface returns, the response content must be sent and committed, and closed by the servlet container. /spec-quote Frankly speaking, as a user I don't care about dispatchers, responses and containers. I just want to include a _resource_, which is allowed according to Sun's quick reference card for JSP 1.2. Ok, Sun apparently is screwed up, mixing the requirements, but it should not be my problem, because its syntax reference card works for me :) I want my problem to be solved. And this works in other containers. I understand that Tomcat has to go by the real spec, not by the comics book. Then, in this case spec should be updated. This functionality is important to me. And currently I cannot implement it on Tomcat without a... er... patch, which I did myself and which can break something else. So I would prefer a real fix from Tomcat pros. The language for the 2.3 spec is similar. Bottom line: Resin is wrong ;-). Wrong or not, it works great for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
Now I understand: you want real life to work like the comic book! :-) :-) (Don't take that personally, it's April 1 today after all). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33223] - pageContext.forward and jsp:include result in StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33223. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33223 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33223] New: - pageContext.forward and jsp:include result in StringIndexOutOfBoundsException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33223.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33223
Summary: pageContext.forward and jsp:include result in
StringIndexOutOfBoundsException
Product: Tomcat 5
Version: 5.5.4
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
We have a tag library which we use on JSP pages. The Page tag forwards to a
controller (via pageContext.forward() which then redirects to a template page
and the template page includes via jsp-include the site navigation etc. then
includes via jsp-include the original request page. This works in Tomcat 4
but it throws an exception in Tomcat 5 - I tried with 5.5.4.
In debugging this, I found the problem is JspServlet:service which tries to
call
if (requestUri != null){
String currentIncludedUri
= requestUri.substring(requestUri.indexOf(includeUri));
with the values:
includeUri= /test/index.jsp
requestUri= /tomcat-bug/test/
Since includeUri does not appear in requestUri, indexOf returns -1 and this
causes a runtime exception.
This occurs because my webapp has index.jsp in the web.xml welcome-file-list,
but when the initial page is being executed, request.getRequestURI() returns the
requested page, not the resolved welcome page. For example,
Here is a simplified example showing how to reproduce. I deployed this in the
webapp context tomcat-bug on Tomcat 5.5.4 with no front end web server -
Tomcat is running as the web server. I removed the tag libraries and other
infrastructure and created simple JSP files that demonstrate the root problem,
so no classes or jars are required in WEB-INF/lib or WEB-INF/classes.
URL: http://localhost:8080/tomcat-bug/test/
Note: I don't get the exception with the URL
http://localhost:8080/tomcat-bug/test/index.jsp, only when the page is resolved
via the welcome-file
Web application files:
test/index.jsp:
%
Boolean included = (Boolean) pageContext.getAttribute(template.running,
PageContext.REQUEST_SCOPE);
if (included == null)
{
String uri = request.getRequestURI();
String path = request.getContextPath();
if (path != null uri.startsWith(path))
uri = uri.substring(path.length());
pageContext.setAttribute(template.body, uri, PageContext.REQUEST_SCOPE);
pageContext.forward(/templates/template.jsp);
}
else
{
%
pThis is my JSP page, test/index.jsp. This is the body/content of the
page./p
%
}
%
!-- end of test/index.jsp --
templates/template.jsp:
%
pageContext.setAttribute(template.running, Boolean.TRUE,
PageContext.REQUEST_SCOPE);
String top = /templates/top.jsp;
String body = (String) pageContext.getAttribute(template.body,
PageContext.REQUEST_SCOPE);
%
html
headtitleTomcat bug/title/head
body
jsp:include flush=true page=%=top%/jsp:include
br/
Body:
jsp:include flush=true page=%=body%/jsp:include
:body
/body
/html
!-- end of templates/template.jsp --
templates/top.jsp :
pThis is the top navigation bar for the page template (top.jsp)p
!-- end of templates/top.jsp --
WEB-INF/web.xml:
?xml version=1.0 encoding=UTF-8?
web-app version=2.4
xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
welcome-file-list
welcome-fileindex.jsp/welcome-file
/welcome-file-list
/web-app
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 --- Additional Comments From [EMAIL PROTECTED] 2005-01-17 15:35 --- I *believe* this has been fixed in recent 4.1, 5.0, and 5.5 releases -- at least we've not been bitten by it recently. I've not had a chance to go looking for it lately either. If it is still an issue in 5.5 someone will re-open. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-17 03:24 --- Jess, I'm closing this item. Please reopen if and only if it's relevant in Tomcat 5.5.6. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 [EMAIL PROTECTED] changed: What|Removed |Added Component|Jasper 2|Jasper Product|Tomcat 4|Tomcat 5 Version|4.1.3 |5.0.28 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 --- Additional Comments From [EMAIL PROTECTED] 2005-01-14 00:06 --- http://issues.apache.org/bugzilla/show_bug.cgi?id=31804 Could someone please advise me on whether this Bug is fixed? Bugzilla shows this bug to be filed under Tomcat 4.0 I am using Tomcat 5.0.28 and am having problems when using the jsp:param tag. I get tons of deprecation errors. My IDE is jbuilder 2005 and am using : java version 1.4.2_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04) Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode) any tips on whether this bugID is fixed for Tomcat 5.0.28 (or how could it be fixed OR a workaround ) would be greatly appreciated. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 --- Additional Comments From [EMAIL PROTECTED] 2005-01-14 00:08 --- sorry. prior post had the wrong URL the correct one is : http://issues.apache.org/bugzilla/show_bug.cgi?id=10671 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31741] - servlet request forward to jsp with jsp:include tag can cause extra request to be submitted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31741 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-01-01 20:38 --- This works as expected if tested directly with Tomcat 4.1.x from CVS HEAD (no Apache). Either this is a Tomcat 4 bug that has been fixed in 4.1.31 or a JK2 bug. I suspect that a JK2 bug is most likely. However, JK2 is no longer supported (see text below so i am marking this as WONTFIX). JK2 Support Information follows: As of November 15, 2004, JK2 is no longer supported. All bugs related to JK2 will be marked as WONTFIX. In its place, some of its features have been backported to jk1. Most of those features will be seen in 1.2.7, which is slated for release on November 30th, 2004. Another alternative is the ajp addition to mod_proxy which will be part of apache 2. For more information on the Tomat connectors docs at http://jakarta.apache.org/tomcat/connectors-doc/ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-18 13:09 --- I have thought about this some more and decided that on balance the patch should be committed. The patch has been applied to TC4.1.x and ported to TC5.5.x -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31741] - servlet request forward to jsp with jsp:include tag can cause extra request to be submitted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31741 servlet request forward to jsp with jsp:include tag can cause extra request to be submitted --- Additional Comments From [EMAIL PROTECTED] 2004-10-19 04:13 --- This does not seem to be an issue in Tomcat 5.0.28. The output I got is below and seems to be correct. -- Request: [EMAIL PROTECTED] reqNum=1: Start Request: [EMAIL PROTECTED] reqNum=1: Sleep Request: [EMAIL PROTECTED] reqNum=2: Start Request: [EMAIL PROTECTED] reqNum=2: Forward Request: [EMAIL PROTECTED] reqNum=2: Finish Request: [EMAIL PROTECTED] reqNum=1: Forward Request: [EMAIL PROTECTED] reqNum=1: Finish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31741] New: - servlet request forward to jsp with jsp:include tag can cause extra request to be submitted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31741 servlet request forward to jsp with jsp:include tag can cause extra request to be submitted Summary: servlet request forward to jsp with jsp:include tag can cause extra request to be submitted Product: Tomcat 4 Version: 4.1.30 Platform: PC OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We seem to have found a case where 2 clicks from a browser cause 3 requests to be processed by the servlet. The steps to reproduce are: - Set up the servlet and JSP files as below - Start with the HTML file - Click the Submit button once, wait 1 second (first request will not be complete) and then click it again - You'll see 2 requests (correct) in the Apache log and 3 requests (incorrect) processed in catalina.out We found this while doing some debugging on our application. This was done on a Solaris Intel machine running Apache 2.0.48 and the 2.0.4 JK connectors using the CoyoteConnector config in server.xml. A couple of things that seem to be necessary for this: - The flush must be set to true in the jsp:include directive - There must be some kind of output in the including page before the include directive Log I captured - request 3 seems to be spawned after request 1 completes --- WebappClassLoader: Resource '/WEB- INF/classes/ServletJSPForwardAndIncludeTest.class' was modified; Date is now: Fri Oct 15 21:33:15 EDT 2004 Was: Fri Oct 15 20:42:29 EDT 2004 Request: [EMAIL PROTECTED] reqNum=1: Start Request: [EMAIL PROTECTED] reqNum=1: Sleep Request: [EMAIL PROTECTED] reqNum=2: Start Request: [EMAIL PROTECTED] reqNum=2: Forward Request: [EMAIL PROTECTED] reqNum=2: Finish Request: [EMAIL PROTECTED] reqNum=1: Forward Request: [EMAIL PROTECTED] reqNum=1: Finish Request: [EMAIL PROTECTED] reqNum=3: Start Request: [EMAIL PROTECTED] reqNum=3: Sleep Request: [EMAIL PROTECTED] reqNum=3: Forward Request: [EMAIL PROTECTED] reqNum=3: Finish Oct 15, 2004 9:33:53 PM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:472) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.coyote.tomcat4.OutputBuffer.close(OutputBuffer.java:324) at org.apache.coyote.tomcat4.CoyoteResponse.finishResponse (CoyoteResponse.java:486) at org.apache.coyote.tomcat4.CoyoteAdapter.service (CoyoteAdapter.java:200) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:324) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:395) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:615) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) Oct 15, 2004 9:33:53 PM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:472) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:329) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:395) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:615
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-10 21:02 --- 1a. If you are worried about performance - precompile. If you want ease of replacement - don't. You can't have it both ways. 1b. Please state which section of the spec you believe tomcat is not compliant with. Without this, I can't invetsigate further. 3. What about different encodings across different webapps on the same server? There are solutions for this issue with the current versions of tomact. My concern about the proposed patch, that it encourages non-portable coding, remains. I am leaving this as REOPENED for now but I am leaning towards resolving it as WONTFIX. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 02:46 --- 1a.No I can't. So, I need this patch is committed. 1b.Please see API spec of RequestDispatcher#include method. (Because jsp:include action will be converted into this method.) This method must be able to handle any resource(such as a servlet, HTML file, or JSP file). But I feel like you said that because Tomcat cannot handle HTML file correctly, you ask to convert HTML file into JSP file. Isn't it right? 3.It can be resolved by defining DefaultServlet on each web app. If this patch is committed, we can separate web app from environment(locale) before fixing JSP spec. If you don't set file.encoding property, Tomcat will handle it just like former. So I believe there will be no demerit at all. If you say that property of i18n depending on container is a problem, see javaEncoding property of JspServlet. This property is also depend on the container, and assume that ALL JSP files for all webapps have the same encoding. Do you think that javaEncoding property is also a problem? Do you mean that it is not a problem, current Tomcat changes its handling by environments? I believe that this patch will be help for i18n problems, as other properties. Regards, Takayuki Kaneko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 09:29 --- 1. Converting HTML files into JSPs has following problems. - Since the JSP compile is needed, a performance may become a problem. - HTML files must be included correctly in JSP spec. I think requiring converting HTML into JSP means not fulfilling specification. 2.file.encoding option does not operate depending on the version of JVM. 1.1 OK 1.2 NG 1.3 - 1.4.1 OK 1.4.2 NG file.encoding is determined by default locale at the time of JVM execution. I recommend you to see the following page. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4163515 3. The best solution for including HTML files of multiple encodings is changing the JSP spec. First of all, a browser cannot display if multiple encodings are contained in 1 page. In this case, in a HTML file, you should use comprehensive encodings, such as UTF8. However, do you want to use UTF8 as default locale? This patch can separate encodings of default locale and web app. This patch extends options without any undesireble effects. Other options are still effective even if this patch is accepted. reagrds, Takayuki Kaneko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 11:19 --- 1. If performance is an issue, pre-compile your JSPs. If you can quote the part of the spec tomcat isn't following and the patch addresses this issue I'll commit it. However, having read the spec, and the errata, I believe tomcat is spec compliant. 2. I wasn't aware of this. Thanks for pointing this out. This is clearly not an option. 3. I think you mis-understood me. I was not trying to address one file with multiple encodings. My point is that your patch assumes (as does the current tomcat code) that ALL static files for all webapps will have the same encoding. Is this sufficient to address your i18n issues? Is it not possible to have one webapp with html files using one encoding and one webapp with thml files using a different one? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 16:43 --- 1.pre-compile is a good solution, but the sequence of replacing is complicate without stopping the web app while Tomcat is running. In a HTML file, I just need to replace it. It is much simple. I think your saying is not compliant the spec. If converting HTML into JSP is required, then HTML files can not be included. 3.My point is that it will be not necessary to consider the different static file encodings within the same web app. As having stated above, the problem of displaying still remains, there is no solution for a such web app in the present JSP specification. And there is no solution for even one static file encoding under present Tomcat. Takayuki Kaneko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 21:33 --- I am still not happy with the portability implications of this. I still think it would be better for the 'fix' to be part of the application (and hence be portable) rather than part of the container (not portable and may require changes to app between containers depending on how each handles this). That being said, if all other options are inappropriate then I am prepared to consider this patch. Therefore I'd would appreciate it you would consider the following options. 1. I understand that some developers want to include HTML directly. However, given that this has i18n problems and i18n is obviously important to you why not tell your developers that they can't do this and should convert to JSPs? It is a change to the file name, adding a encoding directive and changing references from xxx.html to xxx.jsp. This would be trivial to automate. 2. How about using -Dfile.encoding=... at the JVM level? 3. The patch (and option 2 above) assumes that every file has the same encoding. Is this always the case? Might different files in different apps have different encodings? If so, you could specify a modified version of the default servlet in your web application to handle .html files. With this option you could even handle different static file encodings within the same web app. This option would give you a lot of flexibility (which may or may not be useful to you). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-05 06:27 --- There are, however, a number of alternative approaches that are spec compliant and are hence container neutral. I knew. However these approaches could not include HTML direct. We should convert HTML to JSP or use escaped character for non iso-8859-1 characters. Some of the people want include HTML direct. Then, this becomes problem. You said I feed back JCP. It's really right, but imagin, how long we wait to resolve the problem and does tomcat never have tomcat specific functions? Could you see the number of vote for this bug? I'm disappointment for your i18n and l10n attitude. I posted i18n and l10n patch in the past but it took _6 month_ that tomcat commiter took my patch. I recommend you to provide temporary solution since release Tomcat 6.0 again. bye, Takashi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2004-10-05 14:37 --- Although I think that correcting specification is the right approach, there is no solution in the present JSP specification. Therefore the problem should be coped with by a container. When not applying this patch, Tomcat depends on default encoding of Java VM to include of a HTML file. Since Web application depends by environment strongly, it will be the worst situation if you consider the portability which you say. If there are already many properties which are valuable and depend on the container, I suggest this patch should be treated as one of them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-02 14:33 --- The default encoding for included pages is defined in http://www.jcp.org/aboutJava/communityprocess/maintenance/jsr053/errata_1_2_a_2 0020321.html Comments and suggestions for the JSP spec should be directed to the spec team ([EMAIL PROTECTED]) rather than this mailing list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-10-02 14:47 --- The patch suggested above would be a Tomcat specific solution to a wider i18n problem. Whilst it would work for Tomcat I would not wish to encourage an approach such as this as if you ever need to move to an alternative container, it will break again. Therefore, this patch will not be applied. (Hence the WONTFIX). There are, however, a number of alternative approaches that are spec compliant and are hence container neutral. The simplest approach is to convert the HTML to JSPs and specify the correct page encoding in the new JSPs using %@ page pageEncoding=... %. There are other approaches and if the one suggested above isn't appropriate I suggest that you post a question on the tomcat-user mailing list rather than this bug report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31201. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-09-26 01:56 --- This is a problem at JSP spec(5.4 sec) not Tomcat. JSP spec doesn't show included pages encoding. As far as I read cuurent JSP spec, I think default encoding should be defined by pageEncoding attribute in JSP's page directive of included page. I proposes adding pageEncoding attribute for jsp:include directive (JSP spec 5.4) to specify included page default encoding. If included page has pageEncoding, this jsp:include's encoding should be ignored. However this patch seems valuable since JSP spec will be fixed. I think this patch should be applied for current tomcat. reagrds, Takashi Okamoto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31316] - Tomcat 5 rejects jsp:include ..../jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31316. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31316 Tomcat 5 rejects jsp:include /jsp:include --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 19:21 --- You're right; the issue is the use of whitespace at all in this context. The new rigor is still likely to trip up some porters of applications, but it's a defensible interpretation of the spec. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31316] New: - Tomcat 5 rejects jsp:include ..../jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31316.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31316
Tomcat 5 rejects jsp:include /jsp:include
Summary: Tomcat 5 rejects jsp:include /jsp:include
Product: Tomcat 5
Version: 5.0.28
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Servlet JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In porting an app from Tomcat 4.1.30 to Tomcat 5.0.28 we discovered
that the following JSP text no longer works:
jsp:include page=departments.jsp flush=false/jsp:include
It throws a JasperException:
org.apache.jasper.JasperException: /index.jsp(374,0) Expecting
jsp:param standard action with name and value attributes
unless the text is changed to
jsp:include page=departments.jsp flush=false/
The change in behavior seems to violate the old (1.2) and new (2.0) JSP
specs, which both say:
A jsp:include action may have jsp:param subelements that can
provide values for some parameters in the request to be used for
the inclusion.
i.e. it *may* have jsp:param subelements (it doesn't insist on
them).
Even the syntax description (on page 1-110 of the 2.0 spec) explicitly
permits omitting jsp:param when opening and closing jsp:include tags
are used instead of jsp:include ... /:
jsp:include page=urlSpec flush=true|false
{ jsp:param / }*
/jsp:include
In any case the change in behavior is problematic for people porting
applications.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31316] - Tomcat 5 rejects jsp:include ..../jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31316. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31316 Tomcat 5 rejects jsp:include /jsp:include --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 18:58 --- I believe this has been raised at least once in the past, and the response was that you have to have a new line between the start and end jsp:include tags, i.e. jsp:include foo bar/jsp:include is a no-no, but jsp:include foo bar /jsp:include is OK. Try the latter and let us know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31316] - Tomcat 5 rejects jsp:include ..../jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31316. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31316 Tomcat 5 rejects jsp:include /jsp:include --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 20:35 --- It fails in the same way even if the /jsp:include appears on a separate line. But even if this workaround had worked, the change in behavior is still surprising and would still be problematic for people porting apps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31316] - Tomcat 5 rejects jsp:include ..../jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31316. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31316 Tomcat 5 rejects jsp:include /jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 21:22 --- I think you got the valid and invliad cases reversed. You'll get this error iff there are white spaces between jsp:include and /jsp:include. The reason why this is an error is explained in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] New: - Encoding bug when using jsp:include ... action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31201.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31201
Encoding bug when using jsp:include ... action
Summary: Encoding bug when using jsp:include ... action
Product: Tomcat 4
Version: 4.1.30
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
There is a bug in JSP include that DefaultServlet assigns default locale
encoding
for included file using jsp:include file=... action,
and the included file's encoding is not matched default locale.
For example;
locale=ja_JP.SJIS
abc.html:
written by Windows-31J
page.jsp:
---
%@ page contentType=text/html; charset=Windows-31J %
page include!!
HR
jsp:include file=abc.html flush=true /
HR
---
HTML file's encoding should be fixed when Web Application is deploying.
So I tried to make a patch for this bug.
I added fileEncoding parameter for DefaultServlet.
Patch for this bug follows:
===
*** DefaultServlet.java Sun Jan 25 22:23:42 2004
--- DefaultServlet_patch.java Mon Sep 13 22:13:39 2004
***
*** 177,182
--- 177,187
/**
+ * Encoding for Reader
+ */
+ protected String fileEncoding;
+
+ /**
* MD5 message digest provider.
*/
protected static MessageDigest md5Helper;
***
*** 306,311
--- 311,322
} catch (Throwable t) {
;
}
+ try {
+ value = getServletConfig().getInitParameter(fileEncoding);
+ fileEncoding = value;
+ } catch (Throwable t) {
+ ;
+ }
// Sanity check on the specified buffer sizes
if (input 256)
***
*** 1793,1799
InputStream resourceInputStream = resourceInfo.getStream();
// FIXME : i18n ?
! Reader reader = new InputStreamReader(resourceInputStream);
// Copy the input stream to the output stream
exception = copyRange(reader, writer);
--- 1804,1812
InputStream resourceInputStream = resourceInfo.getStream();
// FIXME : i18n ?
! Reader reader = (fileEncoding == null) ?
! new InputStreamReader(resourceInputStream) :
! new InputStreamReader(resourceInputStream,
fileEncoding);
// Copy the input stream to the output stream
exception = copyRange(reader, writer);
***
*** 1864,1870
IOException exception = null;
InputStream resourceInputStream = resourceInfo.getStream();
! Reader reader = new InputStreamReader(resourceInputStream);
exception = copyRange(reader, writer, range.start, range.end);
// Clean up the input stream
--- 1877,1885
IOException exception = null;
InputStream resourceInputStream = resourceInfo.getStream();
! Reader reader = (fileEncoding == null) ?
! new InputStreamReader(resourceInputStream) :
! new InputStreamReader(resourceInputStream,
fileEncoding);
exception = copyRange(reader, writer, range.start, range.end);
// Clean up the input stream
***
*** 1956,1962
while ( (exception == null) (ranges.hasMoreElements()) ) {
InputStream resourceInputStream = resourceInfo.getStream();
! Reader reader = new InputStreamReader(resourceInputStream);
Range currentRange = (Range) ranges.nextElement();
--- 1971,1979
while ( (exception == null) (ranges.hasMoreElements()) ) {
InputStream resourceInputStream = resourceInfo.getStream();
! Reader reader = (fileEncoding == null) ?
! new InputStreamReader(resourceInputStream) :
! new InputStreamReader(resourceInputStream,
fileEncoding);
Range currentRange = (Range) ranges.nextElement();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29509] New: - /jsp:include notation without jsp:param fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29509 /jsp:include notation without jsp:param fails Summary: /jsp:include notation without jsp:param fails Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Following two cases work ok: jsp:include page=... flush=... / and jsp:include page=... flush=... jsp:param name=... value=... / /jsp:include but this does not jsp:include page=... flush=... /jsp:include The final example produces the following (good!) message: Expecting jsp:param standard action with name and value attributes The final example worked fine in 4.0.6. I was not able to recognize this as a change in the JSP2.0 spec. Bug?, Spec change? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29509] - /jsp:include notation without jsp:param fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29509. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29509 /jsp:include notation without jsp:param fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-06-10 19:09 --- *** This bug has been marked as a duplicate of 25448 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25448] - jsp:include is intolerant of whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25448. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25448 jsp:include is intolerant of whitespace [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-06-10 19:09 --- *** Bug 29509 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28590] New: - ClassLoader is wrong after jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28590 ClassLoader is wrong after jsp:include Summary: ClassLoader is wrong after jsp:include Product: Tomcat 3 Version: 3.3.x Nightly Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Jdk12Interceptor.postService() sets thread context class loader at postService () time of the included jsp, so the rest part of the outer jsp doesn't run in web app class loader. Test jsp: %out.println(Thread.currentThread().getContextClassLoader());% jsp:include page=/any.jsp flush=true/ %out.println(Thread.currentThread().getContextClassLoader());% Output: org.apache.tomcat.util.depend.DependClassLoader12Impl ... java.net.FactoryURLClassLoader Tomcat 4 doesn't have this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28590] - ClassLoader is wrong after jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28590 ClassLoader is wrong after jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-04-27 02:46 --- Fixed now in the CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27623] - jsp:include / in XML view page product too many XML Decl
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27623. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27623 jsp:include / in XML view page product too many XML Decl [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-16 02:16 --- Since the dynamically included page is separate page, the inclusion of an xml decl is to be expected, since it does not know it will be included. To do what you are doing, JSP 2.0 has just the new action to let you omit such decl for the page. See JSP.5.16. Specifically you'll need to rewrite world.jspx as: fo:block xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:jsp=http://java.sun.com/JSP/Page; jsp:output omit-xml-declaration=true / Hello World /fo:block - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27623] New: - jsp:include / in XML view page product too many XML Decl
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27623. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27623 jsp:include / in XML view page product too many XML Decl Summary: jsp:include / in XML view page product too many XML Decl Product: Tomcat 5 Version: 5.0.19 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have two file hello.jspx world.jspx like: hello.jspx: | ?xml version=1.0? | fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; | xmlns:jsp=http://java.sun.com/JSP/Page; | jsp:include page=world.jspx/ | /fo:root world.jspx: | fo:block xmlns:fo=http://www.w3.org/1999/XSL/Format; | Hello World | /fo:block and the result is: | ?xml version=1.0 encoding=UTF-8? | fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; | ?xml version=1.0 encoding=UTF-8? | ~~ | fo:block xmlns:fo=http://www.w3.org/1999/XSL/Format; | Hello World/fo:block/fo:root and tomcat product too much XML decl. My env: Windows XP, jdk1.4.2_04, tomcat 5.0.19 Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16694] - jsp:include fails if param=../../
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16694. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16694 jsp:include fails if param=../../ [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-07 18:32 --- According to the spec for URIs (http://www.ietf.org/rfc/rfc2396), section 2.2, / is a reserved character and must be escaped. The fact that it works in some circumstances without being escaped is pure chance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25448] - jsp:include is intolerant of whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448
jsp:include is intolerant of whitespace
--- Additional Comments From [EMAIL PROTECTED] 2004-02-25 13:31 ---
Ok - for all people that have this problem and have access to perl, here is a
small script to fix the problem. It reads the names of jsp files from stdin and
changes the jsp:include's accordingly. That is, only the ones where page=
comes before flush= - should be easy to change though.
#!/usr/bin/perl
use IO::AtomicFile;
use strict;
while(STDIN) {
my $fileName = $_;
chomp $fileName;
print processing $fileName\n;
processFile($fileName);
}
exit 0;
sub processFile {
my $fileName = shift;
my $fileContent;
open(IN,$fileName) or die($fileName: $!);
while(IN) {
$fileContent .= $_;
}
close(IN);
$fileContent =~
s/\jsp\:include\s+page\s*=\s*\(.+?)\\s+flush\s*=\s*\(.+?)\\s*\\s*\\/jsp:include\s*\/jsp:include
page=$1 flush=$2\//msg;
my $FH = IO::AtomicFile-open($fileName,w);
print $FH $fileContent;
$FH-close || warn ( write atomic $fileName: $!);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26290] New: - java compiler name space collision on String org when used with jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26290. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26290 java compiler name space collision on String org when used with jsp:include Summary: java compiler name space collision on String org when used with jsp:include Product: Tomcat 5 Version: 5.0.0 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am not sure if you would consider this is a bug but here it is This is probably a bug with the code that generates the java code from the jsp page. This may not be a bug because it is really a name space collision. However, it is a kind of a bug because the name space that is colliding with is not neccessarily researved. The ramification of this bug or behavior is that you cannot create a jsp variable called org and use the jsp:include directive on the same jsp page with tomcat because of namespace collisions. I am not certain if this behavior occurs in other webapps such as websphere or jboss. In a jsp if you create a global String variable called org and then use the jsp:include page=/jsp/auditlistdetail.jsp flush=true / directive the code will not compile because of a namespace collision on the org variable. When the java compiler gets to org.apache it tries to treat org. as a String object. Original JSP code = String org; jsp:include page=/jsp/someother.jsp flush=true / Java generated code looks something like this. === . String org = ; .. org.apache.jasper.runtime.JspRuntimeLibrary.include(request, response, /jsp/someother.jsp, out, true); . Java compiler error message is cannot resolve symbol variable apache. It is trying to look for a method or variable in the org string object. I would suggest using an import org.apache.jasper.runtime.* so this one particular collision does not occur. I would guess that there are alot of applications out there with jsp variables called org. I am renaming my variables to organization to prevent any further problems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26290] - java compiler name space collision on String org when used with jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26290. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26290 java compiler name space collision on String org when used with jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-20 20:29 --- This is a limitation of the java programming package naming convention. You also may also want to stay away from the following variable names: com, java, javax, edu, net as well as any other top level domain. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25448] - jsp:include is intolerant of whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448 jsp:include is intolerant of whitespace [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-12-15 19:15 --- Reopen to change status. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25448] - jsp:include is intolerant of whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448 jsp:include is intolerant of whitespace [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-15 19:23 --- This is NOT a bug, afterall. According to JSP 2.0 spec, JSP.1.3.10.1, the grammar for EmptyBody does not allow whitespaces before /jsp:include. In this case, whitespaces are allowed only when they are followed by jsp:params. This is consistent with how whitespaces are treated in the body of a custom action: a body consists of whitesapces only are not considered empty. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16701] - No exception if jsp:include fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16701. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16701 No exception if jsp:include fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-12-15 23:10 --- I am afraid that this behaviour is as per the spec. quote SRV.8.3 The Include Method The include method of the RequestDispatcher interface may be called at any time. The target servlet of the include method has access to all aspects of the request object, but its use of the response object is more limited: It can only write information to the ServletOutputStream or Writer of the response object and commit a response by writing content past the end of the response buffer, or by explicitly calling the flushBuffer method of the ServletResponse interface. It cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. /quote I am resolving this as WONTFIX. If you feel the spec has got this wrong, the address to send your feedback to is [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25448] New: - jsp:include is intolerant of whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448 jsp:include is intolerant of whitespace Summary: jsp:include is intolerant of whitespace Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] While upgrading from Tomcat 4.1.18 to 5.0.16, I encountered a problem where several of my JSPs will not compile. I found that the following syntax was causing Jasper to to throw an error. The syntax: jsp:include page=/asset/search-includeaction.jsp flush=false /jsp:include Would cause this exception to be thrown: org.apache.jasper.JasperException: /asset/index.jsp(43,6) Expected param tag with name and value attributes at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:83) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:402) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:126) at org.apache.jasper.compiler.Parser.parseParam(Parser.java:892) at org.apache.jasper.compiler.Parser.parseBody(Parser.java:1838) at org.apache.jasper.compiler.Parser.parseOptionalBody(Parser.java:1100) at org.apache.jasper.compiler.Parser.parseInclude(Parser.java:928) at org.apache.jasper.compiler.Parser.parseStandardAction(Parser.java:1251) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1597) at org.apache.jasper.compiler.Parser.parse(Parser.java:171) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:247) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:149) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:135) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:237) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:456) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:439) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:552) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:291) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:594) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.opennms.web.UTF8RequestEncodingValve.invoke(UTF8RequestEncodingValve.java:56) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:578) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151
DO NOT REPLY [Bug 25448] - jsp:include is intolerant of whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25448 jsp:include is intolerant of whitespace [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jsp:include bug in 4.1.27
I am currently porting webapps to Tomcat(4.1.27) from WL and believe I may have found a bug with the implementation of the jsp:include action tag. The problem I found is that when using the jsp:include tag in a page which resides in a context which differs from the request's initial context the page being included is not found. (The crossContext attribute of the Context element has been set to true.) An example may better explain this: WebappOne one.jsp source: WebappOne/one.jspbr % config.getServletContext().getContext(/WebappTwo).getRequestDispatcher(/two.jsp).include(request,response); % WebappTwo two.jsp source: WebappTwo/two.jspbr jsp:include page=/three.jsp flush=true/ three.jsp source: WebappTwo/three.jsp The text inside of WebappTwo/three.jsp will not be included in WebappTwo/two.jsp output when requesting WebappOne/one.jsp. However, if we move WebappTwo/three.jsp to WebappOne the output is included in the output of WebappTwo/two.jsp. I think that the cause of this is that JspRuntimeLibrary.include(...) uses the request to obtain a RequestDispatcher and the request is pointing to the initial context: RequestDispatcher rd = request.getRequestDispatcher(resourcePath); rd.include(request, new ServletResponseWrapperInclude(response, out)); The JSP 1.2 spec seems to say that jsp:include should be relative to the current page: A jsp:include .../ element provides for the inclusion of static and dynamic resources in the same context as the current page. Thanks, Greg Holtfreter Software Engineer Encyclopaedia Britannica - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671 Major issues with jsp:param in jsp:include and jsp:forward --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 01:30 --- I agree that passing non-ISO-8859-1 characters (or whatever your platform default is) via jsp:param is broken in 4.1.27. A suggested work-around: While this work-around won't be suitable for all applications, it is handy where an included page (or a page that is always the target of a forward) wants to receive characters that would otherwise not work. Basically encode the value of the parameter into something that can be represented in ISO-8859-1 before passing it to jsp:param, and then do the reverse encoding in the called page. Using Java 1.4's URLEncoder.encode (string, UTF-8) before giving the string to jsp:param is one such encoding that does this. This causes: [non ISO-8859-1 suitable string] (encode using URLEncoder.encode(string, UTF-8)) [string that can be represented in ISO-8859-1] (pass to jsp:include or jsp:forward via jsp:param) (Tomcat calls URLEncoder.encode(string)) (Tomcat calls the included or forwarded page) (Tomcat calls URLEncoder.decode(string)) [string that can be represented in ISO-8859-1] (decode using URLDecoder.decode(string, UTF-8)) [original string] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671 Major issues with jsp:param in jsp:include and jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 12:02 --- I lately ran into ALMOUST the same URL encoding decoding problem. As it seems no action is going to be taken I'll describe my situation so it could help in the desition making. First I need to put ISO-8859-4 characters on the URL (I know it's bad design and the next time I'll use underlying coding ;). For example the URL to be encoded is: folder.do?path=/Uusim/täpiline. Now I use struts for createing the actual URL and so the URL is encoded in UTF-8. When tomcat decodes the request URL on the next step useing platform defaul encodeing ISO-8859-4 I get different result. As you all can see the problem could even be none of Tomcat's business but while figuring about the solutions I came up with a little example that makes it Tomcat's problem: Lets assume that I encode the url with URLEncoder.encode(java.lang.String) manually. Then struts will not find any unaceptable characters and leaves the URL alone (At least I hope so). Now I shouldn't have no problems with Tomcat's decodeing method. But the same problem comes up again when my application is distributed and the url location happens to be on a different server with a different encodeing. Now when the different server happens to be out of my hands and so the encodeing remains different then I'll have to deal with the encoding problem on application level and that's a bit stupid. So my opinion is that the URL encodeing and decodeing should allways be done in UTF-8 encodeing like the World Wide Web Consortium recommends. And maybe introduce a configuration parameter for extreme cases when some other server handles this issue incorrectly. I'd be happy to get any response concering this issue. PS! I also checked and think that this problem is currently up with both the 4.1.27 and 5.0.12 server versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671 Major issues with jsp:param in jsp:include and jsp:forward --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 14:24 --- We have not hit these issues with 4.1.24 they went away for us quite some 4.1.x releases back. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23406] New: - jsp:include shows partial output after the included file has been modified
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406 jsp:include shows partial output after the included file has been modified Summary: jsp:include shows partial output after the included file has been modified Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a very strange problem and it is almost unreproducable. If someone would like to help me isolate the issue I'd be much abliged. I'm willing to do the research work on it, but need a few hints where to look. The following happens: We have an index.jsp which jsp:includes a menu.jsp. The menu.jsp is a relatively large plain text file. The menu.jsp is generated every night at midnight to reflect the changes of the day. Some days when we come in, the menu only shows partially. Other days the whole menu is shown. When checking the generated java and class files everything seems to be in order. The index.jsp has a JspRuntimeLibrary.include where the jsp:include was and the menu.jsp, menu_jsp.java and menu_jsp.class(decompiled to check) all resemble the new state. The index.jsp shows itself entirely, however only a part of the included html is shown. If the menu.jsp is recreated manually everything works again. A sidenote to this bug is that it only seems to occur with larger includes (this example is 1300 lines). Other sites we've created use the same method of including and menu generation with smaller menus and they have no problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23406] - jsp:include shows partial output after the included file has been modified
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23406
jsp:include shows partial output after the included file has been modified
--- Additional Comments From [EMAIL PROTECTED] 2003-09-25 11:07 ---
[PURE SPECULATION]
You are seeing a race condition. While the file (menu.jsp) is being generated to
its destination - a request is made for it. During this sime time, a request is
made for the file. The file is read incompletely by the JSP compiler, and the
write happens quick enough that all of this occurs in the same second so the JSP
engine does not detect a file change.
I have seen this on tomcat404. You have 3 workarounds:
1) If its a plain text file, just call it menu.txt. This also saves some
overhead of a JSP.
2) Generate the file to a temporary area on the same disk. Then use a file copy
from/to local disk.
3) Tweak the jsp to force a compile error of itself if it is not complete. A
simple brace % { % at the top of the file then closing brace at the bottom
should work.
It would be nice for Jasper to store the file size and date to perform its
checks for situations such as this.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10270] - jsp:include breaks with non-String rtexpr
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10270 jsp:include breaks with non-String rtexpr --- Additional Comments From [EMAIL PROTECTED] 2003-08-28 00:00 --- JSP.2.11.13 describes expressions in template text, not expresions in action attributes, as is the case here. JSP.2.13.2.3 says Request-time expressions can be assigned to properties of any type. No automatic conversions will be performed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21782] New: - HttpServletRequestWrapper subclass conflicts with jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21782. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21782 HttpServletRequestWrapper subclass conflicts with jsp:include Summary: HttpServletRequestWrapper subclass conflicts with jsp:include Product: Tomcat 4 Version: 4.1.18 Platform: PC URL: http://tesuque.stanford.edu/~dyoo/tomcat_wrapper_bug.tar .gz OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm running into some behavior that appears to be a bug in Tomcat 4.1. I've written a small WAR to demonstrate the problem: http://tesuque.stanford.edu/~dyoo/tomcat_wrapper_bug.war The source code to this package is: http://tesuque.stanford.edu/~dyoo/tomcat_wrapper_bug.tar.gz The situation is the following: Given a regular HttpServletRequest object, I wrap my own HttpServletRequestWrapper around it. This wrapper includes a setParameter() method that lets me define my own parameters. Once I've reassigned a few parameters (like name), I do an RequestDispatcher.include() to my presentation JSP. Within that presentation jsp, I do another include to a small JSP page. I also do some overriding some parameters using jsp:param. The bug is that the jsp:param tags don't appear to be taking any effect in my small jsp page! I've determined that the HttpServletRequest that is being passed to the small jsp page is my own wrapped request object, so there's no way the jsp:param-ed variables can be passed on. In a normal situation, the code that handles jsp:include will construct its own wrapped request object to pass off any jsp:param'ed parameters. However, for some reason, Tomcat appears not to do this wrapping process on an HttpServletRequest that is already wrapped with HttpServletRequestWrapper. I've looked at the Tomcat source code, and I do see some potential problems in the request wrapping code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21782] - HttpServletRequestWrapper subclass conflicts with jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21782. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21782 HttpServletRequestWrapper subclass conflicts with jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-07-21 22:35 --- Looks to be dup of an invalid bug. Use a filter for the desired behavior. *** This bug has been marked as a duplicate of 8566 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440 jsp:include whose target performs a 'forward' does not behave as expected [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||20940 nThis|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] New: - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440
jsp:include whose target performs a 'forward' does not behave as expected
Summary: jsp:include whose target performs a 'forward' does not
behave as expected
Product: Tomcat 4
Version: 4.1.24
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
It appears that tomcat does not behave properly when a JSP
page invokes a jsp:include whose target performs a 'forward'.
Details below.
---
SETUP
Foo.html
!-- An HTML page that simply outputs FOO --
FOO
ForwardServlet.java:
/**
* A servlet that performs a RequestDispatcher.forward()
* to Foo.html.
*/
package tsc.servlet;
import java.io.IOException;
import javax.servlet.*;
public class ForwardServlet extends GenericServlet {
public void service(ServletRequest req, ServletResponse res)
throws ServletException, IOException {
ServletContext context = getServletContext(); String
path=/Foo.html;
RequestDispatcher rd = context.getRequestDispatcher(path);
rd.forward(req, res);
}
}
Forward.jsp:
!-- A JSP page that performs a jsp:forward to Foo.html. --
jsp:forward page=Foo.html/
---
TestCase 1
With the following example:
TestCase1.jsp
-
***1***
jsp:include page=/ForwardServlet/ ***2***
% System.out.println(TestCase1.jsp); %
The expected result is that only FOO will be displayed
on the resulting page, and TestCase1.jsp will be
displayed on the console.
Here is why:
In JSP 5.4, it is stated that:
Inclusion is into the current value of out.
...
An included page only has access to the JspWriter object and it cannot set
headers. This precludes invoking methods like setCookie. Attempts to invoke
these methods will be ignored. The constraint is equivalent to the one imposed on
the include method of the RequestDispatcher class.
Although it would not hurt the spec to be a little more specific, the assumption
here is that the RequestDispatcher.include()
has to be called with a response object whose 'writer' is shared
with the including page.
Given that the target of the 'include' is a servlet that performs
a RequestDispather.forward(), the following will happen
(as per SRV 8.4):
- output data in the response buffer is cleared
- response content is sent and committed, and closed.
From the viewpoint of our original TestCase1.jsp page, this therefore
means that:
- ***1*** is added to the response output
- ***1*** gets cleared from the response output
- FOO is added to the response output
- the response output is closed
- '***2***' does not get added to the response output because
it has already been closed
- The 'System.out()' statement gets executed.
If this example is run with Tomcat 4.1.24, the output
is:
***1***
FOO
and TestCase1.jsp is NOT displayed on the console.
Not as expected.
---
Moreover, with the following example:
TestCase2.jsp
-
***1***
jsp:include page=/ForwardServlet/ ***2***
% System.out.println(TestCase2-a.jsp); %
jsp:include page=/ForwardServlet/ ***3***
% System.out.println(TestCase2-b.jsp); %
The expected result is that TestCase2-a.jsp will be displayed on the console
and that an IllegalStateException will be
thrown.
[Exception should be thrown because the response has already been committed with
the first forward (via the first include), and a forward
cannot be done (via the second include) when a response has already
been committed.]
If this example is run with Tomcat 4.1.24, the output
is:
***1***
FOO
nothing is displayed on the console, and no exception is thrown.
---
Also, in the above two test cases, if ForwardServlet is replaced by
Forward.jsp as the target of the jsp::include's:
TestCase1
works as expected
TestCase2
FOO
TestCase2-a.jsp is displayed on the console
IllegalStateException is not thrown
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440 jsp:include whose target performs a 'forward' does not behave as expected [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Minor --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 18:56 --- The test case 2 is giving me a headache, so I won't comment on it. For the first one, I think that since you're inside an include, the forwarded page can't close the response, which I think is very logical. I think the report is invalid, sorry Pierre (and even if it's not, there are many other, way more important request dispatcher issues which have an actual impact unlike this report, waiting to be clarified by the specification, such as req/resp wrapping). I think I am against attempting to fix this bug (if confirmed it is actually one) in 4.1.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440 jsp:include whose target performs a 'forward' does not behave as expected --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 19:18 --- Agree this is severity 'minor', since this is a corner case that should not occur often. The test case 2 is giving me a headache, so I won't comment on it. With some more coffee, I know you can do it Remy :-) For the first one, I think that since you're inside an include, the forwarded page can't close the response, which I think is very logical. That was my impression at first, but after checking with the spec leads, it looks like the response object is to be shared between the including and included pages. Given the following in the servlet spec: - response content is sent and committed, and closed. This would mean that the output stream of the including page is closed. I think the report is invalid, sorry Pierre (and even if it's not, there are many other, way more important request dispatcher issues which have an actual impact unlike this report, waiting to be clarified by the specification, such as req/resp wrapping). I think I am against attempting to fix this bug (if confirmed it is actually one) in 4.1.x. Not sure it is invalid, but clarifications from the spec leads would be important. I'll copy the spec leads on this report to make sure it eventually gets addressed. As mentioned above, this is 'minor' and I understand this may not be fixed in 4.1.x, and that there are way more important issues pending. Having it logged will hopefully ensure it does not fall through the cracks... (A JSTL bug report on c:import is what triggered this investigation because the behavior of c:import in JSTL is defined in function of jsp:include). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440
jsp:include whose target performs a 'forward' does not behave as expected
--- Additional Comments From [EMAIL PROTECTED] 2003-07-09 22:40 ---
I believe I have a fix for testcase_1:
jsp:include wraps the response into an instance of
org.apache.jasper.runtime..ServletResponseWrapperInclude, so that the
included resource may append its output to the output buffer of the
including page.
Therefore, in the case of ForwardServlet, the response object passed
to RequestDispatcher.forward() is an instance of
ServletResponseWrapperInclude. RequestDispatcher.forward() calls
resetBuffer() on the response object, which
ServletResponseWrapperInclude delegates to the wrapped response. At
this point, ***1*** has not been committed to the response buffer
yet: it was buffered in the JspWriter associated with the including
page, to which the PrintWriter associated with the
ServletResponseWrapperInclude appends. This means that calling
resetBuffer() on the response does not really have any effect, and
therefore, FOO gets appended to ***1***.
On the other hand, when replacing ForwardServlet with forward.jsp,
the code generated for forward.jsp calls RequestDispatcher.forward()
with a response object obtained as follows:
// Make sure that the response object is not the wrapper for include
while (response instanceof ServletResponseWrapperInclude) {
response = ((ServletResponseWrapperInclude)response).getResponse();
}
As a consequence of passing the original response to the
RequestDispatcher, the response consists of just FOO, which does not
get appended to ***1***.
A fix is to override ServletResponseWrapperInclude.resetBuffer() as follows:
public void resetBuffer() {
try {
writer.clearBuffer();
} catch (IOException ioe) {
}
}
which clears the output buffer of the including page, which is what we want.
However, independently of this fix, running testcase_1 throws this exception:
SEVERE: Servlet.service() for servlet jsp threw exception
java.io.IOException: Stream closed
at
org.apache.jasper.runtime.JspWriterImpl.ensureOpen(JspWriterImpl.java:233)
at
org.apache.jasper.runtime.JspWriterImpl.clearBuffer(JspWriterImpl.java:188)
at org.apache.jsp.test1_jsp._jspService(test1_jsp.java:48)
When replacing ForwardServlet with forward.jsp, it throws this exception:
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: getOutputStream() has already been called for
this response
at
org.apache.coyote.tomcat5.CoyoteResponse.getWriter(CoyoteResponse.java:628)
at
org.apache.coyote.tomcat5.CoyoteResponseFacade.getWriter(CoyoteResponseFacade.java:192)
at
org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:165)
at
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:158)
at
org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:245)
at
org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:160)
at
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:120)
at org.apache.jsp.test11_jsp._jspService(test11_jsp.java:52)
Still investigating
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21440 jsp:include whose target performs a 'forward' does not behave as expected --- Additional Comments From [EMAIL PROTECTED] 2003-07-09 23:09 --- Remy, I agree in general with your comments about the RD. However, I think this particular case (testcase_1) is covered by SRV.8.4: If output data exists in the response buffer that has not been committed, the content must be cleared before the target servlet's service method is called. and Before the forward method of the RequestDispatcher interface returns, the response content must be sent and committed, and closed by the servlet container. My proposed change (in org.apache.jasper.runtime.ServletResponseWrapperInclude) will make the ForwardServlet case consistent with jsp:forward, which already implements the required behaviour. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jsp:include
Hi, There's a bug in J2EE 1.4 RI Beta 2 that prevents me from using a custom tag: instanceof operator treats TagSupport subclass as SimpleTagSupport instance. This leaves me only one appropriate option: subclass the class that implements jsp:include tag, and overwrite a method in it. I'd appreciate a pointer as to what class implements that tag. I've been searching through taglibs and tomcat-5 nightly builds, and have not found a single class that is related to jsp:include. Thank you in advance. P.S. Yes, i will be reporting the bug on sun's website. But i need to work around at this time... -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s Description: S/MIME Cryptographic Signature
Re: jsp:include
Can you reproduce your problem with Tomcat 5? If so, you may get it fixed faster if you post it on bugzilla. When you do, make sure to include a test case (a war file would be great). Not sure I understand what the problem is. Also not sure what jsp:include has to anything to do with your problem. You cannot find a class that is related to jsp:include because there isn't one. jsp:include eventually invokes RequestDispatcher.include in the generated servlet code. See org.apache.jasper.runtime.JspRuntimeLibrary.include() for more details. Date: Tue, 24 Jun 2003 15:45:39 -0500 From: Reshat Sabiq [EMAIL PROTECTED] Subject: jsp:include To: [EMAIL PROTECTED] Hi, There's a bug in J2EE 1.4 RI Beta 2 that prevents me from using a custom tag: instanceof operator treats TagSupport subclass as SimpleTagSupport instance. This leaves me only one appropriate option: subclass the class that implements jsp:include tag, and overwrite a method in it. I'd appreciate a pointer as to what class implements that tag. I've been searching through taglibs and tomcat-5 nightly builds, and have not found a single class that is related to jsp:include. Thank you in advance. P.S. Yes, i will be reporting the bug on sun's website. But i need to work around at this time... -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13781] - Non-existent file name given to jsp:include does not generate FNE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13781. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13781 Non-existent file name given to jsp:include does not generate FNE [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 00:07 --- *** This bug has been marked as a duplicate of 16701 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16701] - No exception if jsp:include fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16701. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16701 No exception if jsp:include fails [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||m --- Additional Comments From [EMAIL PROTECTED] 2003-03-27 00:07 --- *** Bug 13781 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17184] New: - jsp:include does not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17184. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17184 jsp:include does not work Summary: jsp:include does not work Product: Tomcat 4 Version: 4.1.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] i was not able to include my jsp page using include command. The compiler did not gave an error. However using the %@ include % command it worked fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16778] - jsp:include doesn't work in tag file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16778 jsp:include doesn't work in tag file [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16778] New: - jsp:include doesn't work in tag file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16778 jsp:include doesn't work in tag file Summary: jsp:include doesn't work in tag file Product: Tomcat 5 Version: Nightly Build Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] jsp:include.../ doesn't seem to work in tag files. I'm getting this exception when the tag file is compiled (this is from a nightly build I downloaded a few days ago): org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Since fork is true, ignoring compiler setting. [javac] Compiling 1 source file [javac] Since fork is true, ignoring compiler setting. [javac] D:\prog\tomcat5\src\jakarta-tomcat-5\build\work\Standalone\localhost\n6\tags\org\apache\jsp\tag\web\mainframe.java:109: include(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse,java.lang.String,java.io.Writer,boolean) in org.apache.jasper.runtime.JspRuntimeLibrary cannot be applied to (javax.servlet.ServletRequest,javax.servlet.ServletResponse,java.lang.String,javax.servlet.jsp.JspWriter,boolean) [javac] org.apache.jasper.runtime.JspRuntimeLibrary.include(request, response, /n6/blah.html, out, false); [javac] ^ [javac] 1 error at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:120) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:307) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:399) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:427) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:572) at org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:215) at org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:446) at org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:84) at org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:488) at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1033) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1700) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:1742) at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:1748) at org.apache.jasper.compiler.Node$Root.accept(Node.java:334) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:1700) at org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:506) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:262) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:426) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:572) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:297) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:293) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:288) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:294) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:490) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1005) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:490) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1005) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2608) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151
DO NOT REPLY [Bug 16694] New: - jsp:include fails if param=../../
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16694. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16694 jsp:include fails if param=../../ Summary: jsp:include fails if param=../../ Product: Tomcat 4 Version: 4.1.18 Platform: All OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] jsp:include fails if you has one Parameter with ../../ expl: jsp:include page=/level/test/debug.jsp?Param=../.. works: Param=../.. jsp:include page=/level/test/debug.jsp?Param=../../ fails! jsp:include page=/level/test/debug.jsp?Param=../.../../.. works: BUT Param=../.. you can fix this if you replace / with %2F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16701] New: - No exception if jsp:include fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16701. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16701 No exception if jsp:include fails Summary: No exception if jsp:include fails Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If the standard action jsp:include fails to locate the resource (say JSP file) specified in the page attribute, there is no exception generated. Tomcat does just do nothing about the failed include action, but leaves the place in the response empty. Tomcat 3.2 did throw a java.io.FileNotFoundException, which I would also expect to obtaine using Tomcat 4.1. I did not try other versions of Tomcat 4, but two different installations of Tomcat, one 4.1.12, antoher 4.1.x had the same problem. I checked not to be confused by the ErrorPage (removing the part in the page directive), also put try/catch around the include with various exception classes; none showed any evidence of an exception thrown by the code executing the jsp:include action. Using pageContext.include() behaves the same. jsp:includes does work well if the page can be found. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request URI corrupted by jsp:include
Supporting our application for one of our clients, they have set up RH7.2, Tomcat 4.1.10 (installed from rpm), jdk 1.4.1-b2, and apache 1.3.23-14 installed from rpm. I've encountered in issue (bug) that hopefully has been recognized and resolved. We include a little page sectional called tabBar (a simple HTML snippet that replaces the parameter with the string value) jsp:include page=/interface/tabBar.jsp flush=true jsp:param name=atTabTitle value=Find Users / /jsp:include %=request.getRequestURI()% The output on the page is: dth=139 height= (this code happens to be part of a previous include on the page) jsp:include page=/interface/tabBar.jsp jsp:param name=atTabTitle value= Find Users / /jsp:include %=request.getRequestURI()% The output on the page is: /attask/test2.jsp Obviously, the first output is totally corrupted. The only difference is the 'flush' argument. In any case, flushing shouldn't hose the requestURI. Any ideas? -Scott -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Request URI corrupted by jsp:include
This looks a lot like a bug that was recently fixed. Unfortunately, it missed the cut for 4.1.14. You'll have to get j-t-c/jk/java/org/apache/jk/server/JkCoyoteHandler.java from the CVS and re-compile. - Original Message - From: Scott Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 11:58 AM Subject: Request URI corrupted by jsp:include Supporting our application for one of our clients, they have set up RH7.2, Tomcat 4.1.10 (installed from rpm), jdk 1.4.1-b2, and apache 1.3.23-14 installed from rpm. I've encountered in issue (bug) that hopefully has been recognized and resolved. We include a little page sectional called tabBar (a simple HTML snippet that replaces the parameter with the string value) jsp:include page=/interface/tabBar.jsp flush=true jsp:param name=atTabTitle value=Find Users / /jsp:include %=request.getRequestURI()% The output on the page is: dth=139 height= (this code happens to be part of a previous include on the page) jsp:include page=/interface/tabBar.jsp jsp:param name=atTabTitle value= Find Users / /jsp:include %=request.getRequestURI()% The output on the page is: /attask/test2.jsp Obviously, the first output is totally corrupted. The only difference is the 'flush' argument. In any case, flushing shouldn't hose the requestURI. Any ideas? -Scott -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13781] New: - Non-existent file name given to jsp:include does not generate FNE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13781. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13781 Non-existent file name given to jsp:include does not generate FNE Summary: Non-existent file name given to jsp:include does not generate FNE Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A non-existent file given as value to the page attribute of the jsp:include standard action does not generate java.io.FileNotFoundException. I tested the same in Tomcat 4.0.2, it properly generates FNE -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13443] New: - request.getRequestURI() problem with jsp:include tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13443. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13443 request.getRequestURI() problem with jsp:include tag Summary: request.getRequestURI() problem with jsp:include tag Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] the script: file test.jsp: jsp:include page=include.jsp flush=true %=request.getRequestURI()%br / %=request.getRequestURL()% file include.jsp: psimple text/p When I run test.jsp, instead of writing the good URI and URL (with the path to file), it writes piece of headers like :E HTML PUBLIC -//W3C It works well only if the test.jsp file is forwarded by a servlet. In the other cases, inserting a code like %request.getRequestURI();% resolve the problem. It seems that this bug doesn't appear in Tomcat 4.0.x release -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12590] New: - Unable to nest jsp:attribute within jsp:body if used with jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12590 Unable to nest jsp:attribute within jsp:body if used with jsp:include Summary: Unable to nest jsp:attribute within jsp:body if used with jsp:include Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A test case like: jsp:include jsp:attribute name=page foo.jsp /jsp:attribute jsp:body jsp:param jsp:attribute name=name /jsp:include Throws a error : org.apache.jasper.JasperException: /jsp2/jspattrpos/param-in-param.jsp(13,15) Not allowed in a template text body. at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:95) at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:440) at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:126) at org.apache.jasper.compiler.Parser.parseElementsTemplateText(Parser.java:1524) at org.apache.jasper.compiler.Parser.parseBody(Parser.java:1642) at org.apache.jasper.compiler.Parser.parseNamedAttributes(Parser.java:1688) at org.apache.jasper.compiler.Parser.parseEmptyBody(Parser.java:904) at org.apache.jasper.compiler.Parser.parseParam(Parser.java:792) at org.apache.jasper.compiler.Parser.parseBody(Parser.java:1639) at org.apache.jasper.compiler.Parser.parseJspBody(Parser.java:1574) at org.apache.jasper.compiler.Parser.parseJspAttributeAndBody(Parser.java:1016) at org.apache.jasper.compiler.Parser.parseOptionalBody(Parser.java:981) at org.apache.jasper.compiler.Parser.parseInclude(Parser.java:821) at org.apache.jasper.compiler.Parser.parseAction(Parser.java:1140) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1420) at org.apache.jasper.compiler.Parser.parse(Parser.java:159) at org.apache.jasper.compiler.ParserController.parseFile(ParserController.java:245) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:169) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:259) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:409) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:570) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:271) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2505) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480
DO NOT REPLY [Bug 12590] - Unable to nest jsp:attribute within jsp:body if used with jsp:include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12590 Unable to nest jsp:attribute within jsp:body if used with jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671 Major issues with jsp:param in jsp:include and jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-09-09 10:53 --- The behavior in 4.1.11 will be identical to Tomcat 4.0.x. It is still unclear to me if this is a spec violation or not. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671 Major issues with jsp:param in jsp:include and jsp:forward --- Additional Comments From [EMAIL PROTECTED] 2002-09-09 10:56 --- *** Bug 9361 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-09 17:29 --- You cannot write jsp:include page=%=jspbase%includes/left.inc flush=true /jsp:include because the value for the attribute page is not an expression. Instead use jsp:include page='%=jspbase + includes/left.inc%' flush=true /jsp:include Also, jsp:include page=includes/left.inc flush=true /jsp:include works perfectly for me. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % --- Additional Comments From [EMAIL PROTECTED] 2002-09-09 17:33 --- Sorry, I meant jsp:include page=includes/left.jsp/ works for me, but not jsp:include page=includes/left.inc/. But then .inc is not a recognized JSP extension. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % --- Additional Comments From [EMAIL PROTECTED] 2002-09-09 20:00 --- Yes, this is a known problem. Since Catalina refuses to include binaries in the middle of text, your file must have a text/* MIME type. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-09-08 08:15 --- Include a test case. I believe the functionality is working fine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Component|Catalina|Jasper 2 Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-09-08 08:17 --- Missed the fact that it was using JK. I think you should test if it works in standalone mode. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % --- Additional Comments From [EMAIL PROTECTED] 2002-09-08 16:22 --- OK, I tested this standalone with the ISAPI redirector and the files are being included only so long as I don't use expression which is very limiting. So my question is: did this release break our ability to use 1. the ISAPI redirector and 2. expressions with jsp:include? It appears so. If I use expression like this: % String jspbase=/en_test/ % ... jsp:include page=%=jspbase%includes/left.inc flush=true /jsp:include then I get a 500 error like this: exception org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:477) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:182) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke (StandardContext.java:2350) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:469) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex t(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service (CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:405) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio n(Http11Protocol.java:380) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:508) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:533) at java.lang.Thread.run(Thread.java:536) root cause org.apache.jasper.JasperException: /en_test/testindex3.jsp(78,44) jsp.error.attribute.unterminated at org.apache.jasper.compiler.DefaultErrorHandler.jspError (DefaultErrorHandler.java:94) at org.apache.jasper.compiler.ErrorDispatcher.dispatch (ErrorDispatcher.java:417) at org.apache.jasper.compiler.ErrorDispatcher.jspError (ErrorDispatcher.java:170) at org.apache.jasper.compiler.Parser.parseAttributeValue (Parser.java:217) at org.apache.jasper.compiler.Parser.parseAttribute(Parser.java:181
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % --- Additional Comments From [EMAIL PROTECTED] 2002-09-08 16:25 --- Last entry, first line, meant without ISAPI redirector. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % --- Additional Comments From [EMAIL PROTECTED] 2002-09-08 16:39 --- Even the non-expression form of jsp:include is not working reliably: This is now not working: jsp:include page=includes/left.inc flush=true /jsp:include it fails to include the file left.inc and from then on no further jsp:include statements work. while the limited directive form does work: %@ include file=includes/left.inc % -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] New: - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % Summary: jsp:include does not work with %= expression % Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] jsp:include does not appear to be functioning correctly. I can't get it to work with %= expression % form and it isn't even working correctly in determining relative location. I have an include file located in an includes dir directly beneath the loaded file dir but jsp:include page=includes/myfile flush=true / does not include it and in fact stops all further includes. This is a major problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % --- Additional Comments From [EMAIL PROTECTED] 2002-09-08 05:53 --- The file that I'm including is not a .jsp file. But this shouldn't make any difference. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12394] - jsp:include does not work with %= expression %
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12394 jsp:include does not work with %= expression % --- Additional Comments From [EMAIL PROTECTED] 2002-09-08 06:03 --- Also might note that I'm using the ISAPI redirector. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671 Major issues with jsp:param in jsp:include and jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Normal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10671 Major issues with jsp:param in jsp:include and jsp:forward [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Blocker --- Additional Comments From [EMAIL PROTECTED] 2002-08-30 04:58 --- There is talk of calling 4.1.10 a final release, but yet this apparent spec violation has not been fixed?!? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12049] - jsp:include does not resolve symlinked directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12049. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12049 jsp:include does not resolve symlinked directory [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-08-27 07:58 --- For security reasons, the filesystem abstraction layer will expect the canonical path of the file served to be situated under the webapp directory. This is likely what causes the problem. You can tweak that implementation, or you can submit a patch to the current implementation to allow disabling the check. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
