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=13081>. 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=13081 ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes Summary: ScriptingVariableVisitor#setScriptingVars does not account for scriptlet scopes Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The code in ScriptingVariableVisitor#setScriptingVars is attempting to fix a long-standing problem whereby tags within other tags cannot declare scripting variables twice (due to the same Java scope) and yet tags that are scoped within different parent tags *must* redeclare the variable. This is handled by the following snippet of code: Integer currentRange = (Integer) scriptVars.get(varName); if (currentRange == null || ownRange.compareTo(currentRange) > 0) { scriptVars.put(varName, ownRange); vec.add(varInfos[i]); } The problem with this code is that it ignores the fact that java scriptlets may have defined explicit code blocks, limiting the visibility of a scripting variable more than this particular piece of code can ever realize. Because of the need to handle this situation, all of our tags take an optional attribute "declareVariables" and have for many years. The above snippet of code breaks valid JSP's that have worked for us on the 4.0.x series of Tomcat. Despite the fact that it is not considered good "form" to use significant Java code in JSP's, it is certainly allowed. We have legacy applications that we cannot change for various reasons. Understanding that there is a real problem to be solved here (which we solved a different way), I'm wondering if I can suggest solving this dilemma by introducing a new servlet initialization parameter to control whether the above check is done or not. The default value could be true so that the check above can continue to be done, but allowing us to override the configuration in web.xml to turn this check off. At this point, we have to drop back to the 4.0.x series of Tomcat to avoid this problem. We would very much like to use the new, better performing 4.1.x series, but will have to wait until a reasonable solution can be found to this problem. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
