You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2010/03/07 19:45:50 UTC
svn commit: r920055 -
/tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Author: markt
Date: Sun Mar 7 18:45:50 2010
New Revision: 920055
URL: http://svn.apache.org/viewvc?rev=920055&view=rev
Log:
Both TLD and web.xml determine if deferred EL syntax is treated as EL or as a literal
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Validator.java?rev=920055&r1=920054&r2=920055&view=diff
==============================================================================
--- tomcat/trunk/java/org/apache/jasper/compiler/Validator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Validator.java Sun Mar 7 18:45:50 2010
@@ -1075,11 +1075,16 @@
|| (!n.getRoot().isXmlSyntax() && attrs.getValue(i).startsWith("<%=")));
boolean elExpression = false;
boolean deferred = false;
+ double libraryVersion = Double.parseDouble(
+ tagInfo.getTagLibrary().getRequiredVersion());
+ boolean deferredSyntaxAllowedAsLiteral =
+ pageInfo.isDeferredSyntaxAllowedAsLiteral() ||
+ libraryVersion < 2.1;
ELNode.Nodes el = null;
if (!runtimeExpression && !pageInfo.isELIgnored()) {
- el = ELParser.parse(attrs.getValue(i), pageInfo
- .isDeferredSyntaxAllowedAsLiteral());
+ el = ELParser.parse(attrs.getValue(i),
+ deferredSyntaxAllowedAsLiteral);
Iterator<ELNode> nodes = el.iterator();
while (nodes.hasNext()) {
ELNode node = nodes.next();
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/3/8 Konstantin Kolinko <kn...@gmail.com>:
> 2010/3/8 Mark Thomas <ma...@apache.org>:
>> On 07/03/2010 21:26, Konstantin Kolinko wrote:
>>>
>>> Re: r920110:
>>> (...)
>>> I see no provision in the spec for the above change.
>>>
>>> The chapter "Backwards Compatibility with JSP 2.0" that I mentioned above
>>> does say that only about #{} expressions.
>>>
>>> The chapter "Backwards Compatibility with JSP 1.2" of JSP 2.0 spec
>>> (page 20/478) or JSP.3.3.2 Deactivating EL Evaluation of JSP 2.0 spec
>>> (page 123/478) do not mention that either.
>>
>> The TCK passes either way. Given that the spec doesn't cover this and
>> neither does the TCK do we:
>> a) stick to the letter of the spec
>> b) treat isELIgnored and isDeferredSyntaxAllowedAsLiteral consistently
>>
>> I have a preference for b) but if the majority disagree I'm happy to revert.
>>
>
> Compatibility between JSP 2.0 and JSP 1.2 (aka isELIgnored) is covered
> by JSP 2.0 spec.
>
> See "Backwards Compatibility with JSP 1.2" in the preface section of
> JSP 2.0 spec (page 20 of 478)
>
> Among compatibility mechanisms mentioned there, using Tag Library
> version to switch EL processing in attributes is not mentioned.
>
> At that time the main concern for compatibility were users of JSTL 1.0.
>
> citing (page 22):
> "Users of JSTL 1.0 will need to either
> "upgrade their taglib imports to the JSTL 1.1 uris, or they will need to use the
> "_rt versions of the tags (e.g. c_rt instead of c, or fmt_rt instead of fmt).
> /citing.
>
One more evidence against r920110:
JSP 2.0 allows ${} expressions to be used for attributes that are
specified as <rtexprvalue>true</rtexprvalue> even for JSP 1.2 and
earlier tags.
That is an important use case.
BTW, r920110 changes only Validator, not Parser or JspDocumentParser.
I think that is why TCK did not catch it.
>> In a similar area on which the spec is silent, if I use a TLD that
>> declares it requires JSP 2.1 in a web applciation that declares servlet
>> 2.3 in web.xml is that an error? At the moment it works but it feels
>> wrong. Thoughts?
>
> An example of that I think will be the case when the tag library is
> provided by the container, and we deploy an application created for
> the older version of specification. If Tag library was updated, does
> its URL change, or is it still available under the old URL?
>
> I think that URL change between JSTL 1.0 and 1.1 was an exception, and
> the authors would like to avoid it in the future.
>
> Thus such deployment won't be an error.
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/3/8 Mark Thomas <ma...@apache.org>:
> On 07/03/2010 21:26, Konstantin Kolinko wrote:
>> 2010/3/7 Konstantin Kolinko <kn...@gmail.com>:
>>> 2010/3/7 Mark Thomas <ma...@apache.org>:
>>>> On 07/03/2010 18:45, markt@apache.org wrote:
>>>>> Author: markt
>>>>> Date: Sun Mar 7 18:45:50 2010
>>>>> New Revision: 920055
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=920055&view=rev
>>>>> Log:
>>>>> Both TLD and web.xml determine if deferred EL syntax is treated as EL or as a literal
>>>
>>> Ah, I see. That is said in the chapter "Backwards Compatibility with
>>> JSP 2.0" that precedes the main spec pages (page xxiv in JSP 2.2
>>> Specification).
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>>
>>
>> Re: r920110:
>>
>> 2010/3/7 <ma...@apache.org>:
>>> Author: markt
>>> Date: Sun Mar 7 20:54:01 2010
>>> New Revision: 920110
>>>
>>> URL: http://svn.apache.org/viewvc?rev=920110&view=rev
>>> Log:
>>> isELIgnored depends on library version and web.xml declaration
>>>
>>> Modified:
>>> tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
>>> =========================================================
>>> --- tomcat/trunk/java/org/apache/jasper/compiler/Validator.java (original)
>>> +++ tomcat/trunk/java/org/apache/jasper/compiler/Validator.java Sun Mar 7 20:54:01 2010
>>> @@ -1077,12 +1077,15 @@
>>> boolean deferred = false;
>>> double libraryVersion = Double.parseDouble(
>>> tagInfo.getTagLibrary().getRequiredVersion());
>>> + boolean elIgnored =
>>> + pageInfo.isELIgnored() ||
>>> + libraryVersion < 2.0;
>>> boolean deferredSyntaxAllowedAsLiteral =
>>> pageInfo.isDeferredSyntaxAllowedAsLiteral() ||
>>> libraryVersion < 2.1;
>>>
>>> ELNode.Nodes el = null;
>>> - if (!runtimeExpression && !pageInfo.isELIgnored()) {
>>> + if (!runtimeExpression && !elIgnored) {
>>> el = ELParser.parse(attrs.getValue(i),
>>> deferredSyntaxAllowedAsLiteral);
>>> Iterator<ELNode> nodes = el.iterator();
>>>
>>
>> I see no provision in the spec for the above change.
>>
>> The chapter "Backwards Compatibility with JSP 2.0" that I mentioned above
>> does say that only about #{} expressions.
>>
>> The chapter "Backwards Compatibility with JSP 1.2" of JSP 2.0 spec
>> (page 20/478) or JSP.3.3.2 Deactivating EL Evaluation of JSP 2.0 spec
>> (page 123/478) do not mention that either.
>
> The TCK passes either way. Given that the spec doesn't cover this and
> neither does the TCK do we:
> a) stick to the letter of the spec
> b) treat isELIgnored and isDeferredSyntaxAllowedAsLiteral consistently
>
> I have a preference for b) but if the majority disagree I'm happy to revert.
>
Compatibility between JSP 2.0 and JSP 1.2 (aka isELIgnored) is covered
by JSP 2.0 spec.
See "Backwards Compatibility with JSP 1.2" in the preface section of
JSP 2.0 spec (page 20 of 478)
Among compatibility mechanisms mentioned there, using Tag Library
version to switch EL processing in attributes is not mentioned.
At that time the main concern for compatibility were users of JSTL 1.0.
citing (page 22):
"Users of JSTL 1.0 will need to either
"upgrade their taglib imports to the JSTL 1.1 uris, or they will need to use the
"_rt versions of the tags (e.g. c_rt instead of c, or fmt_rt instead of fmt).
/citing.
> In a similar area on which the spec is silent, if I use a TLD that
> declares it requires JSP 2.1 in a web applciation that declares servlet
> 2.3 in web.xml is that an error? At the moment it works but it feels
> wrong. Thoughts?
An example of that I think will be the case when the tag library is
provided by the container, and we deploy an application created for
the older version of specification. If Tag library was updated, does
its URL change, or is it still available under the old URL?
I think that URL change between JSTL 1.0 and 1.1 was an exception, and
the authors would like to avoid it in the future.
Thus such deployment won't be an error.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Posted by Mark Thomas <ma...@apache.org>.
On 07/03/2010 21:26, Konstantin Kolinko wrote:
> 2010/3/7 Konstantin Kolinko <kn...@gmail.com>:
>> 2010/3/7 Mark Thomas <ma...@apache.org>:
>>> On 07/03/2010 18:45, markt@apache.org wrote:
>>>> Author: markt
>>>> Date: Sun Mar 7 18:45:50 2010
>>>> New Revision: 920055
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=920055&view=rev
>>>> Log:
>>>> Both TLD and web.xml determine if deferred EL syntax is treated as EL or as a literal
>>
>> Ah, I see. That is said in the chapter "Backwards Compatibility with
>> JSP 2.0" that precedes the main spec pages (page xxiv in JSP 2.2
>> Specification).
>>
>> Best regards,
>> Konstantin Kolinko
>>
>
> Re: r920110:
>
> 2010/3/7 <ma...@apache.org>:
>> Author: markt
>> Date: Sun Mar 7 20:54:01 2010
>> New Revision: 920110
>>
>> URL: http://svn.apache.org/viewvc?rev=920110&view=rev
>> Log:
>> isELIgnored depends on library version and web.xml declaration
>>
>> Modified:
>> tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
>> =========================================================
>> --- tomcat/trunk/java/org/apache/jasper/compiler/Validator.java (original)
>> +++ tomcat/trunk/java/org/apache/jasper/compiler/Validator.java Sun Mar 7 20:54:01 2010
>> @@ -1077,12 +1077,15 @@
>> boolean deferred = false;
>> double libraryVersion = Double.parseDouble(
>> tagInfo.getTagLibrary().getRequiredVersion());
>> + boolean elIgnored =
>> + pageInfo.isELIgnored() ||
>> + libraryVersion < 2.0;
>> boolean deferredSyntaxAllowedAsLiteral =
>> pageInfo.isDeferredSyntaxAllowedAsLiteral() ||
>> libraryVersion < 2.1;
>>
>> ELNode.Nodes el = null;
>> - if (!runtimeExpression && !pageInfo.isELIgnored()) {
>> + if (!runtimeExpression && !elIgnored) {
>> el = ELParser.parse(attrs.getValue(i),
>> deferredSyntaxAllowedAsLiteral);
>> Iterator<ELNode> nodes = el.iterator();
>>
>
> I see no provision in the spec for the above change.
>
> The chapter "Backwards Compatibility with JSP 2.0" that I mentioned above
> does say that only about #{} expressions.
>
> The chapter "Backwards Compatibility with JSP 1.2" of JSP 2.0 spec
> (page 20/478) or JSP.3.3.2 Deactivating EL Evaluation of JSP 2.0 spec
> (page 123/478) do not mention that either.
The TCK passes either way. Given that the spec doesn't cover this and
neither does the TCK do we:
a) stick to the letter of the spec
b) treat isELIgnored and isDeferredSyntaxAllowedAsLiteral consistently
I have a preference for b) but if the majority disagree I'm happy to revert.
In a similar area on which the spec is silent, if I use a TLD that
declares it requires JSP 2.1 in a web applciation that declares servlet
2.3 in web.xml is that an error? At the moment it works but it feels
wrong. Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/3/7 Konstantin Kolinko <kn...@gmail.com>:
> 2010/3/7 Mark Thomas <ma...@apache.org>:
>> On 07/03/2010 18:45, markt@apache.org wrote:
>>> Author: markt
>>> Date: Sun Mar 7 18:45:50 2010
>>> New Revision: 920055
>>>
>>> URL: http://svn.apache.org/viewvc?rev=920055&view=rev
>>> Log:
>>> Both TLD and web.xml determine if deferred EL syntax is treated as EL or as a literal
>
> Ah, I see. That is said in the chapter "Backwards Compatibility with
> JSP 2.0" that precedes the main spec pages (page xxiv in JSP 2.2
> Specification).
>
> Best regards,
> Konstantin Kolinko
>
Re: r920110:
2010/3/7 <ma...@apache.org>:
> Author: markt
> Date: Sun Mar 7 20:54:01 2010
> New Revision: 920110
>
> URL: http://svn.apache.org/viewvc?rev=920110&view=rev
> Log:
> isELIgnored depends on library version and web.xml declaration
>
> Modified:
> tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
> =========================================================
> --- tomcat/trunk/java/org/apache/jasper/compiler/Validator.java (original)
> +++ tomcat/trunk/java/org/apache/jasper/compiler/Validator.java Sun Mar 7 20:54:01 2010
> @@ -1077,12 +1077,15 @@
> boolean deferred = false;
> double libraryVersion = Double.parseDouble(
> tagInfo.getTagLibrary().getRequiredVersion());
> + boolean elIgnored =
> + pageInfo.isELIgnored() ||
> + libraryVersion < 2.0;
> boolean deferredSyntaxAllowedAsLiteral =
> pageInfo.isDeferredSyntaxAllowedAsLiteral() ||
> libraryVersion < 2.1;
>
> ELNode.Nodes el = null;
> - if (!runtimeExpression && !pageInfo.isELIgnored()) {
> + if (!runtimeExpression && !elIgnored) {
> el = ELParser.parse(attrs.getValue(i),
> deferredSyntaxAllowedAsLiteral);
> Iterator<ELNode> nodes = el.iterator();
>
I see no provision in the spec for the above change.
The chapter "Backwards Compatibility with JSP 2.0" that I mentioned above
does say that only about #{} expressions.
The chapter "Backwards Compatibility with JSP 1.2" of JSP 2.0 spec
(page 20/478) or JSP.3.3.2 Deactivating EL Evaluation of JSP 2.0 spec
(page 123/478) do not mention that either.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/3/7 Mark Thomas <ma...@apache.org>:
> On 07/03/2010 18:45, markt@apache.org wrote:
>> Author: markt
>> Date: Sun Mar 7 18:45:50 2010
>> New Revision: 920055
>>
>> URL: http://svn.apache.org/viewvc?rev=920055&view=rev
>> Log:
>> Both TLD and web.xml determine if deferred EL syntax is treated as EL or as a literal
Ah, I see. That is said in the chapter "Backwards Compatibility with
JSP 2.0" that precedes the main spec pages (page xxiv in JSP 2.2
Specification).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r920055 - /tomcat/trunk/java/org/apache/jasper/compiler/Validator.java
Posted by Mark Thomas <ma...@apache.org>.
On 07/03/2010 18:45, markt@apache.org wrote:
> Author: markt
> Date: Sun Mar 7 18:45:50 2010
> New Revision: 920055
>
> URL: http://svn.apache.org/viewvc?rev=920055&view=rev
> Log:
> Both TLD and web.xml determine if deferred EL syntax is treated as EL or as a literal
With this, the updated tests for bug48668 and the 2.2 TCK pass. I
suspect that the fix still isn't 100% complete. I'm planning to add some
more test cases for this. Watch this space...
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org