Bug 40797 - Library problems
Library problems
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Jasper
5.5.20
Other other
: P2 blocker with 1 vote (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on: 33407
Blocks:
  Show dependency tree
 
Reported: 2006-10-19 05:16 UTC by Alessandro Ruzzon
Modified: 2006-11-12 11:58 UTC (History)
0 users



Attachments
The stack trace (2.69 KB, text/plain)
2006-10-19 05:18 UTC, Alessandro Ruzzon
Details
Portion of the jsp that create the problem (927 bytes, text/plain)
2006-10-19 05:18 UTC, Alessandro Ruzzon
Details
Simple JSP file that reproduces 0x1b problem (154 bytes, text/plain)
2006-11-01 05:01 UTC, Pavel Sher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alessandro Ruzzon 2006-10-19 05:16:33 UTC
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.
Comment 1 Alessandro Ruzzon 2006-10-19 05:18:10 UTC
Created attachment 19030 [details]
The stack trace
Comment 2 Alessandro Ruzzon 2006-10-19 05:18:38 UTC
Created attachment 19031 [details]
Portion of the jsp that create the problem
Comment 3 Chris Halstead 2006-10-20 10:43:03 UTC
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.
Comment 4 Mark Thomas 2006-10-20 15:35:01 UTC
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.
Comment 5 Pavel Sher 2006-11-01 05:01:07 UTC
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.
Comment 6 Pavel Sher 2006-11-01 05:43:40 UTC
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.
Comment 7 Jeremy Nix 2006-11-08 04:28:19 UTC
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.
Comment 8 Mark Thomas 2006-11-11 19:37:20 UTC
This regression is as a result of the fix for bug 33407. I'm looking into an
alternative fix.
Comment 9 Mark Thomas 2006-11-11 20:27:54 UTC
This has been fixed in SVN (using an alternative character that doesn't break
validation) and will be included in 5.5.21 onwards.
Comment 10 Greg Passmore 2006-11-12 11:41:40 UTC
(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.
Comment 11 Mark Thomas 2006-11-12 11:48:28 UTC
Options are:
- remove the \$ character sequence from the page
- turn off tldValidation for the context
- use the libs from 5.5.17

HTH
Comment 12 Greg Passmore 2006-11-12 11:54:34 UTC
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?
Comment 13 Greg Passmore 2006-11-12 11:58:06 UTC
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.