DO NOT REPLY [Bug 37084] JspC from ant fails on JSPs that use custom taglib
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084 --- Comment #8 from Konstantin Kolinko 2009-01-03 07:40:35 PST --- For reference: The following mail thread has stacktrace for TC 6.0.18 reproducing the issue: http://marc.info/?t=12258533382&r=1&w=2 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37084] JspC from ant fails on JSPs that use custom taglib
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084 --- Comment #9 from Konstantin Kolinko 2009-01-03 07:47:21 PST --- Created an attachment (id=23074) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23074) patch that should fix the issue, against tc6.0.x -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37084] JspC from ant fails on JSPs that use custom taglib
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084 Konstantin Kolinko changed: What|Removed |Added Severity|regression |normal Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Comment #10 from Konstantin Kolinko 2009-01-03 08:31:39 PST --- Though I am yet failing to reproduce the issue in current tc6.0.x, I have elaborated a theory why it occurs. 1. The exception is caused by creating JasperLoader instance with a null baseUrl and trying to use it to load a class, in JspCompilationContext#getJspLoader(). Usually that does not occur, because JspCompilationContext#createOutputDir() is called first. 2. During compilation the #createOutputDir() call does occur: a) in Compiler#isOutDated() when it checks for the full name of the java source / class file, b) later, when Compiler#generateJava() explicitly calls JspCompilationContext#checkOutputDir(). Thus, the compilation is not the route that leads to the preliminary creation of JasperLoader instance. 3. I think that the issue is caused when JspServletWrapper#getDependants() gets called earlier than the compilation of the class occurs. The events will occur as following: 1) JspServletWrapper#getDependants() calls JspCompilationContext#load() that results in #getJspLoader() call and creation of JasperLoader instance. 2) The JasperLoader instance is unusable and this call results in an exception. Nevertheless the created JasperLoader instance is remembered. 3) JspServletWrapper#getDependants() catches the exception, but silently swallows it. 4) The program continues running but breaks later. Thus, the question is what can cause the early #getDependants() call on a fresh compilation context. I am not able to reproduce it. Maybe there should be some interrelated tag/jsp files (OP mentioned: "Seems to be related to the use of a custom taglib in a JSP that is included by another JSP", but that is not sufficient). Also, the known workaround for the issue (disabling caching in JspC) should somehow fit into the picture. Nevertheless, I am proposing a patch to TC 6.0, that I attached above. A side effect is that it mkdirs the output directory, but I think that must be OK. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37084] JspC from ant fails on JSPs that use custom taglib
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084 Mark Thomas changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #11 from Mark Thomas 2009-01-03 14:41:14 PST --- I am -1 for any patch that guesses at a solution as there is no way to confirm the validity of the patch or that it fixes the root cause rather than hides symptoms. As previously requested, a test case is required. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 39589] $CATALINA_BASE/shared/lib and $CATALINA_BASE/shared/classes libraries not found in specific deployments
https://issues.apache.org/bugzilla/show_bug.cgi?id=39589 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #8 from Konstantin Kolinko 2009-01-03 14:53:43 PST --- Found the cause: The context files of those applications that are failing have privileged="true" on their element. If privileged flag is set, the Webapp classloader of the application uses the Server (aka Catalina) classloader instead of the Shared one as its parent. That is by design and WONTFIX. Though that is not mentioned in class-loader-howto.html, it is mentioned in the description of the privileged attribute of Context here: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html *** This bug has been marked as a duplicate of bug 44094 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 44094] privileged="true" causes ClassNotFound from shared\lib
https://issues.apache.org/bugzilla/show_bug.cgi?id=44094 Konstantin Kolinko changed: What|Removed |Added CC||ply...@apache.org --- Comment #4 from Konstantin Kolinko 2009-01-03 14:53:43 PST --- *** Bug 39589 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46354] LIMIT_BUFFER setting causes arraycopy errors
https://issues.apache.org/bugzilla/show_bug.cgi?id=46354
--- Comment #4 from Konstantin Kolinko 2009-01-03
16:14:26 PST ---
This is caused by bug in implementation of
o.a.jasper.runtime.BodyContentImpl#setWriter(Writer)
in current tc6.0.x and tc5.5.x code (and thus in TC 6.0.18, TC 5.5.27).
That method is called by PageContextImpl#pushBody(Writer) and is the one that
prepares the bodycontent instance for reuse.
The current code, with comments omitted, is the following:
558:void setWriter(Writer writer) {
559:this.writer = writer;
560:closed = false;
561:if (writer != null) {
571:if (bufferSize != 0) {
572:bufferSizeSave = bufferSize;
573:bufferSize = 0;
574:}
575:} else {
576:bufferSize = bufferSizeSave;
577:clearBody();
578:}
579:}
The unconditional assignment on line 576 is wrong.
Consider the following sequence of events:
1. setWriter(null)
bufferSize = bufferSizeSave is assigned 0 // <- this is wrong (1)
2. write more than 512 bytes of data
bufferSize becomes > 512
3. setWriter(writer)
bufferSizeSave = bufferSize is assigned value that is > 512
4. setWriter(null)
bufferSize = bufferSizeSave is > 512
BodyContentImpl#clear() is called and shrinks the buffer to its default size
of 512, bufferSize becomes 512
5. write several bytes of data
6. setWriter(null)
bufferSize = bufferSizeSave is > 512 // <- this is wrong (2)
7. write more than 512 bytes of data
At this point the ArrayIndexOutOfBoundsException should occur, because
bufferSize is > 512, but the buffer is only 512 bytes.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r731137 - in /tomcat: container/tc5.5.x/webapps/docs/jasper-howto.xml tc6.0.x/trunk/webapps/docs/jasper-howto.xml trunk/webapps/docs/jasper-howto.xml
Author: markt Date: Sat Jan 3 16:21:37 2009 New Revision: 731137 URL: http://svn.apache.org/viewvc?rev=731137&view=rev Log: Add comment as a result of bug 37515 Modified: tomcat/container/tc5.5.x/webapps/docs/jasper-howto.xml tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml tomcat/trunk/webapps/docs/jasper-howto.xml Modified: tomcat/container/tc5.5.x/webapps/docs/jasper-howto.xml URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/jasper-howto.xml?rev=731137&r1=731136&r2=731137&view=diff == --- tomcat/container/tc5.5.x/webapps/docs/jasper-howto.xml (original) +++ tomcat/container/tc5.5.x/webapps/docs/jasper-howto.xml Sat Jan 3 16:21:37 2009 @@ -202,7 +202,9 @@ -Using Ant is the preferred way to compile web applications using JSPC. +Using Ant is the preferred way to compile web applications using JSPC. Note +that when pre-compiling JSPs, SMAP information only be included in the final +classes if suppressSmap is false and compile is true. Use the script given below (a similar script is included in the "deployer" download) to precompile a webapp: Modified: tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml?rev=731137&r1=731136&r2=731137&view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/jasper-howto.xml Sat Jan 3 16:21:37 2009 @@ -224,7 +224,9 @@ -Using Ant is the preferred way to compile web applications using JSPC. +Using Ant is the preferred way to compile web applications using JSPC. Note +that when pre-compiling JSPs, SMAP information only be included in the final +classes if suppressSmap is false and compile is true. Use the script given below (a similar script is included in the "deployer" download) to precompile a webapp: Modified: tomcat/trunk/webapps/docs/jasper-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/jasper-howto.xml?rev=731137&r1=731136&r2=731137&view=diff == --- tomcat/trunk/webapps/docs/jasper-howto.xml (original) +++ tomcat/trunk/webapps/docs/jasper-howto.xml Sat Jan 3 16:21:37 2009 @@ -224,7 +224,9 @@ -Using Ant is the preferred way to compile web applications using JSPC. +Using Ant is the preferred way to compile web applications using JSPC. Note +that when pre-compiling JSPs, SMAP information only be included in the final +classes if suppressSmap is false and compile is true. Use the script given below (a similar script is included in the "deployer" download) to precompile a webapp: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37515] smap not generated by JspC when used from Ant for precompilation
https://issues.apache.org/bugzilla/show_bug.cgi?id=37515 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WONTFIX --- Comment #9 from Mark Thomas 2009-01-03 16:26:31 PST --- I have added a comment to the 5.5.x and 6.x docs. compile="true" and supressSmap="false" works for me with the latest 5.5.x code. I did toy with the idea of an enhancement request for a new Ant task that merged the smap info into the generated classes but I couldn't see anything that would achieve that isn't achieved by using JspC. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46354] LIMIT_BUFFER setting causes arraycopy errors
https://issues.apache.org/bugzilla/show_bug.cgi?id=46354 --- Comment #5 from Konstantin Kolinko 2009-01-03 17:11:01 PST --- Created an attachment (id=23076) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23076) webapp that reproduces the issue To reproduce the issue: 1. deploy the war file 2. append the following line to conf/catalina.properties : org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true 3. launch the server and access http://localhost:8080/bug46354/ 4. Error 500 report is observed with stacktrace of java.lang.ArrayIndexOutOfBoundsException exception Without step 2. the page works and displays some text. Reproducible in TC 5.5.27 and in current tc6.0.x -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37515] smap not generated by JspC when used from Ant for precompilation
https://issues.apache.org/bugzilla/show_bug.cgi?id=37515 Jess Holle changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #10 from Jess Holle 2009-01-03 17:21:31 PST --- The issue with using compile="true" is that it does not give as much control over compilation. For starters we use a custom extension to the web app classloader to introduce another directory to the classpath *before* WEB-INF/classes. That's the main item -- we could probably live with just using compile="true" if we could control the compilation classpath. We also use UTF-8 as the encoding for javac, but I believe jspc must do so internally as well -- as that's what it produces. [By the way, the documentation should really make the fact that jspc produces UTF-8 Java sources clear as this is not the normal default for Java sources or javac.] I'm re-opening this since there is a use case for compile="false", but I'll understand if that use case is insufficiently interesting to everyone else (as we can work around this ourselves as well by not using pre-compiled JSPs when debugging). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46354] LIMIT_BUFFER setting causes arraycopy errors
https://issues.apache.org/bugzilla/show_bug.cgi?id=46354 --- Comment #6 from Konstantin Kolinko 2009-01-03 18:33:11 PST --- Created an attachment (id=23077) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23077) patch for BodyContentImpl class of tc6.0.x I think that the straightforward way to fix this is to remove the private bufferSizeSave field and the trick from the #setWriter() method and to overwrite the #getBufferSize() method. The bufferSize field is just declared in JspWriter and is not used for calculations neither there nor in BodyContent class, nor the JSP 2.1 spec requires any calculations from them (all methods except the #getBufferSize() getter are abstract). All the calculations are implemented in BodyContentImpl. Thus the attached patch. It fixes the issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37084] JspC from ant fails on JSPs that use custom taglib
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084 Konstantin Kolinko changed: What|Removed |Added Attachment #23074|0 |1 is obsolete|| --- Comment #12 from Konstantin Kolinko 2009-01-03 23:11:32 PST --- Created an attachment (id=23078) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23078) webapp that reproduces the issue when compiled by JspC To reproduce the issue: The following recipe is for Eclipse IDE project for TC 6.0. 1. In your project folder create the following subdirectory and two subdirectories in it: bug37084 /output /source 2. Unzip the war file into bug37084/source 3. Create the following Run configuration: type: Java Application Main class: org.apache.jasper.JspC Arguments / Program arguments: -uriroot bug37084\source -d bug37084\output 4. Run the application 5. A stacktrace is observed: 04.01.2009 10:06:30 org.apache.jasper.JspC processFile SEVERE: ERROR-the file '\index.jsp' generated the following general exception: java.lang.NullPointerException at sun.misc.URLClassPath$3.run(URLClassPath.java:323) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:320) at sun.misc.URLClassPath.getLoader(URLClassPath.java:297) at sun.misc.URLClassPath.getResource(URLClassPath.java:167) at java.net.URLClassLoader$1.run(URLClassLoader.java:192) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:134) ... 6. Delete the generated files from bug37084/output -- The patch that I proposed above does not help. It just results in java.lang.ClassNotFoundException being thrown instead of the NPE. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 37084] JspC from ant fails on JSPs that use custom taglib
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084 Konstantin Kolinko changed: What|Removed |Added Status|NEEDINFO|ASSIGNED -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
