I've updated from tomcat6-6.0.18-9.jpp5 to tomcat6-6.0.24-2.jpp5 This breaks a lot of JSPs! Jasper simply denies to compile them. I hunted down the bug to a very simple example: <%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> <c:set var="now" value='<%= new java.util.Date() %>' /> <jsp:getProperty name="now" property="time" /> This will simply output the current unix time (e.g. 1265641020987). On tomcat 6.0.24 I get this: org.apache.jasper.JasperException: jsp:getProperty for bean with name 'now'. Name was not previously introduced as per JSP.5.3 at org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1083) at org.apache.jasper.compiler.Node$GetProperty.accept(Node.java:1124) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361) at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411) at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417) at org.apache.jasper.compiler.Node$Root.accept(Node.java:495) at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361) at org.apache.jasper.compiler.Generator.generate(Generator.java:3383) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:216) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:332) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:312) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:299) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:589) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) My JDK is java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode) Please fix that! I assume that a lot of apps will break out there ...
To make it even more clear, this works: <jsp:useBean id="now" class="java.util.Date" /> <jsp:getProperty name="now" property="time" /> But getProperty always fails when the bean is not created with useBean. It's not specific to <c:set>. Other constructions also fail.
As per the error message at the beginning of the stack trace, the JSP is not valid.
(In reply to comment #2) > As per the error message at the beginning of the stack trace, the JSP is not > valid. I'll just add that <c:set> does not create a scripting variable, it creates a scoped variable. Here's part of the spec section referenced in the stack trace (JSP.5.3): The object named by the name must have been “introduced” to the JSP processor using either the jsp:useBean action or a custom action with an associated VariableInfo entry for this name. If the object was not introduced in this manner, the container implementation is recommended (but not required) to raise a translation error, since the page implementation is in violation of the specification. Looks like that's what's happening...
That's really bad because that worked up to 6.0.18. I can't remember any problems with such JSPs since tomcat 4 and 5. What about a compatibility switch to keep all that 3rd party apps from breaking?
Reopening. Reviewing implementation of o.a.j.compiler.ScriptingVariabler and what the specification says about objects, scripting variables, and introducing them: 1. In Tomcat code we make no distinction between variables declared programmatically (through VariableInfo) and through TLD (TagVariableInfo). Both introduce a java language variable (aka scripting variable) in the generated code. From JSP.7.1.2 of JSP/2.2 spec: "Finally, the XML document is processed to create a JSP page implementation class. This process may involve creating scripting variables. Each custom action will provide information about variables, either statically in the TLD, or more flexibly by using the getVariableInfo method of a TagExtraInfo class." - both ways introduce a variable 2. About the wording of JSP.5.3 I think that There is no explicit requirement in the Spec to use TagVariableInfo to implement variables introduced through TLD at the time when we are generating the servlet code. Thus I think the spec mentions VariableInfo in JSP.5.3, making no distinction. Also maybe the wording was remained intact since JSP/1.1, and variable declarations in TLDs were introduced in JSP/1.2. The place to fix this issue would be Generator#GeneratorVisitor#visit(Node.CustomTag) - see "JSP.5.3" mentioned in a comment there
Agreed. TagVariableInfo should be just as acceptable for this purpose. I have fixed this in trunk and proposed it for 6.0.x
In r920880 of trunk I added a system property to allow disabling enforcement of JSP.5.3. This is proposed for 6.0 and 5.5.
*** Bug 47822 has been marked as a duplicate of this bug. ***
This has been applied to 5.5.x and will be included in 5.5.30 onwards.
The patch has been applied to 6.0.x and will be included in 6.0.27 onwards.
Still seeing this after upgrading to 6.0.29... org.apache.jasper.JasperException: jsp:getProperty for bean with name 'auth'. Name was not previously introduced as per JSP.5.3 at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:574) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:422) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:144) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:306) at org.apache.tools.ant.Task.perform(Task.java:401) at org.apache.tools.ant.Target.execute(Target.java:338) at org.apache.tools.ant.Target.performTasks(Target.java:365) at org.apache.tools.ant.Project.executeTarget(Project.java:1237) at org.apache.tools.ant.Project.executeTargets(Project.java:1094) at org.apache.tools.ant.Main.runBuild(Main.java:669) at org.apache.tools.ant.Main.startAnt(Main.java:220) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:215) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:90)
(In reply to comment #12) Are you sure, that your jsp page is valid? If you are, please attach a war file with a sample web application that reproduces the issue. Note, that since 5.5.30 and 6.0.27 (as already is mentioned) you can disable the check for conformance with JSP.5.3. by defining a certain system property. http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html I am re-closing this as FIXED.