2010/3/8 Konstantin Kolinko <knst.koli...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
