2010/3/8 Mark Thomas <ma...@apache.org>:
> On 07/03/2010 21:26, Konstantin Kolinko wrote:
>> 2010/3/7 Konstantin Kolinko <knst.koli...@gmail.com>:
>>> 2010/3/7 Mark Thomas <ma...@apache.org>:
>>>> On 07/03/2010 18:45, ma...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to