I'm working with 5.5.20 version, on a SuSE linux (both 10 and 10.1). I've found library problems in libraries in "common/lib". I've changed these libraries with the ones found on a 5.5.17 version an all work fine...Is that a bug??? The attachments contains the stack trace e the jsp that create the problem.
Created attachment 19030 [details] The stack trace
Created attachment 19031 [details] Portion of the jsp that create the problem
Check the entire JSP that is causing the error for malformed XML. Your stack trace is trying to tell you that you have an escape character (0x1b) in the CDATA of a c and fmt element in that JSP. That's not a bug IMHO, but it is strange that the older parsers don't throw the same errors. Are the same source files used in both versions tested, or were the source files copied to the new version? Validation error messages from TagLibraryValidator for c in /common/templates/publicPage.jsp null: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x1b) was found in the CDATA section. Validation error messages from TagLibraryValidator for fmt in /common/templates/publicPage.jsp null: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x1b) was found in the CDATA section. Double-check that your JSPs are clean and aren't hiding any objectionable data and rerun your test.
Chris, 0x1b is inserted and then later removed by Tomcat in certain cases as part of the translation of the JSP. This is almost certinaly related this internal Tomcat behaviour rather than the user's JSP.
Created attachment 19063 [details] Simple JSP file that reproduces 0x1b problem The bug is not stable, you should click F5 in a browser several times to reproduce it.
One more thing: to reproduce error with file.jsp (attached above) you should download apache standard tag libraries jar (standard.jar) and put it in the WEB-INF\lib. Bug will not appear if you remove reference to tag library from jsp.
I experienced the same problems when upgrading to Tomcat 5.5.20. After taking blocks of code in and out of my JSP page, I found that my javascript was the cause for the page to not be compiled properly. Looking closer at my javascript, I found that the following line caused the JSP compiler to fail every time it was included: var re = /[A-Za-z0-9\!\"\#\$\%\&\'\(\)\*\+\,\-\.\/\:\;\<\=\>\?\@\[\\\]\^\_\`\{\|\}\~]/g; By changing this regular expressing to: var re = /[\S]/g; my problem was resolved. I'm not sure what specifically about the original regular expression was causing the compiler problems, nor do I know why that regular expression was written the way it was. Hope this helps.
This regression is as a result of the fix for bug 33407. I'm looking into an alternative fix.
This has been fixed in SVN (using an alternative character that doesn't break validation) and will be included in 5.5.21 onwards.
(In reply to comment #9) > This has been fixed in SVN (using an alternative character that doesn't break > validation) and will be included in 5.5.21 onwards. Is there a workaround for this? this only happens on one of my JSPs, and the only <c:> tags are in a header that I include in every page. I can't figure out how to workaround it.
Options are: - remove the \$ character sequence from the page - turn off tldValidation for the context - use the libs from 5.5.17 HTH
Oh I see, the \$ explains it! I didnt realize that was the cause of the problem. Is there another way I can safely display a dollar sign character in jsp?
nevermind, i've been staring at the screen too long. I was trying to escape a string like this: \${713} so I could actually show ${713} on screen instead of just 713. So, I changed it to ${'${713}'} and I'm ok now.