From dev-return-97832-apmail-tomcat-dev-archive=tomcat.apache.org@tomcat.apache.org Mon Jul 27 20:10:23 2009 Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 16348 invoked from network); 27 Jul 2009 20:10:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 Jul 2009 20:10:23 -0000 Received: (qmail 15185 invoked by uid 500); 27 Jul 2009 20:11:27 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 15077 invoked by uid 500); 27 Jul 2009 20:11:26 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 15066 invoked by uid 99); 27 Jul 2009 20:11:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jul 2009 20:11:26 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [81.103.221.48] (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jul 2009 20:11:16 +0000 Received: from know-smtpout-3.server.virginmedia.net ([62.254.123.3]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090727201054.HGWV6611.mtaout02-winn.ispmail.ntl.com@know-smtpout-3.server.virginmedia.net> for ; Mon, 27 Jul 2009 21:10:54 +0100 Received: from [212.183.136.194] (helo=host49.msm.che.vodafone) by know-smtpout-3.server.virginmedia.net with esmtpa (Exim 4.63) (envelope-from ) id 1MVWX8-00025S-3c for dev@tomcat.apache.org; Mon, 27 Jul 2009 21:10:54 +0100 Message-ID: <4A6E09C7.6080306@apache.org> Date: Mon, 27 Jul 2009 22:10:47 +0200 From: Mark Thomas User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: Bug 47413 - difference in composite ${a}${b} EL expressions between 6.0.18 and 6.0.20 References: <427155180907221658k3c9e5772ve3fc112763baf247@mail.gmail.com> In-Reply-To: <427155180907221658k3c9e5772ve3fc112763baf247@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.0 c=1 a=XhWt6tiOuVcA:10 a=IGlj9GZpowWLTR-lWdwA:9 a=HsxzDsWBT3EqR1nChQAA:7 a=MvGzYnXKnJRGKNo5MxqWH_SNcJ0A:4 X-Virus-Checked: Checked by ClamAV on apache.org Konstantin Kolinko wrote: > but to fix the second one there, I need to generate JSP code that > coerces the string value to the expected type according to EL coercion > rules. > > I do not see how to easily implement that. Maybe somebody has an idea? Some thoughts in-line. > 1) EL coercion rules are best implemented by > o.a.el.lang.ELSupport.coerceToType(obj, type), > but as far as I understand catalina.policy, a JSP page is not allowed > to call that class. Correct. > Either a wrapper method should be added (where?), or the policy be changed. > > JspRuntimeLibrary.convert(String,String,Class,Class) in package > o.a.jasper.runtime > looks similar to what is needed, but actually it is wrong: > when converting to a Boolean value it interprets "on" as true, but > according to EL rules that should be false (as Boolean.valueOf("on") > is false). > I think that it serves some other purpose. The only place I see that code being used is in o.a.j.c.Generator. I am pretty sure than is a bug that needs to be fixed. It has been like that since the very first Tomcat 3.0.x code import but I can't see any good reason in the specs for converting "on" to true. > Generator.GenerateVisitor.convertString(Class, String, String, Class, > boolean) in package o.a.jasper.compiler does conversion at compile > time, not at run time. I won't like to reimplement all those > conversion rules. +1 :) > 2) Alternative way: > > The comment in Generator.attributeValueWithEL() says that this method > is needed to prevent unescaping of literals that are outside of EL > expressions, as blindly passing them over to EL processor will result > in unescaping. > > Maybe we can double-escape those literals, so that when EL processor > performs their unescaping it will restore their original values? > If so, we can create one composite EL expression and pass it over to > EL processor, and it will evaluate it and perform all necessary > coercions. > > Is this a plausible route to resolve this? I looked at this when I worked on the EL Parser issues. If memory serves me correctly this had issues around correctly handling unescaped sequences like '\$', '\\$', '\\\$' etc. You may have better luck than I did. > What escaping is meant there? Is it \$, \#, \', \" ? You'll also need to escape \. Overall, I think a solution based on JspRuntimeLibrary.convert(String,String,Class,Class) is the way to go. That said, you are the one doing the work so feel free to ignore me ;) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org