Mark Thomas wrote on 05/25/12 01:29:
> On 24/05/2012 23:25, Bill Shannon wrote:
>> (I probably won't be able to post to the users list so someone will need
>> to forward this...)
>
> Looks like you can post without any issues.
>
>> Rajiv Mordani wrote on 05/24/2012 02:59 PM:
>>> Including Bill and Kin-man to this thread. Bill feel free to add more details as
>>> you have more context in all of the platform.
>>>
>>> On 5/24/12 6:48 AM, Mark Thomas wrote:
>>>> On 24/05/2012 06:36, rajiv.mordani_at_oracle.com wrote:
>>>>> The version of the deployment descriptor does not determine what
>>>>> features from the container can and cannot be used.
>>>> That is unexpected for two reasons.
>>>
>>> This is and has been the expectation from the entire platform for a long time.
>>> We are in the process of clarifying it in the platform spec as well to be
>>> explicit. If for some reason the current EL EG is not following this we need to
>>> fix this.
>>
>> The intent is that the platform be upward compatible from one release to
>> another. If you could say "this is a Java EE 5 application" and get
>> different behavior than if you said "this is a Java EE 6 application",
>> that's not upwards compatible. You might as well have said "this is a
>> .NET application" and gotten that behavior. If all the same things
>> don't have all the same meanings, it's not upwards compatible.
>>
>> (Ok, I'm simplifying, but this isn't the place for the deep dive.)
>
> I think there needs to be some clarification of this in the
> specifications. My expectation was that an application that uses a
> Servlet 2.5 descriptor will:
> a) run on a 2.5 container
> b) run on a 3.0 container
> c) run the same way on both
The descriptor alone does not control that.
> It is now clear that this is not the intention of the EGs. I understand
> the use case the platform is aiming to support and it is a use case that
> clearly makes sense. However, it does lead to some unexpected results -
> such as the one above - and some clarification in the specifications
> would help to limit surprises.
Yes, we can always make the specs more clear!
>>>> On the other hand, having applications behave differently on different
>>>> containers is clearly not desirable either. A key feature of the J2EE
>>>> specifications is consistency of behaviour across different containers
>>>> and versions of the same container. The internal inconsistency between
>>>> the Servlet EG approach and the JSP EG approach is also not ideal.
>>>>
>>>> All that said, I am having great difficulty understanding what a valid
>>>> use case would be for using a 2.5 descriptor with 3.0 annotations. Why
>>>> not just use a 3.0 descriptor in the first place?
>>>>
>>>> Overall, my preference is for consistency, both in behaviour between
>>>> versions and with the JSP EG.
>>>
>>> Just to emphasize - This has to be consistent across the entire platform and not
>>> just servlet and JSP. So we need to fix EL and not have features tied to
>>> specific versions of descriptors..
>>
>> I know we've made some mistakes, or perhaps we should consider them
>> exceptions to the general rule. There have been some cases where it's
>> been difficult to do what developers expect without making an exception
>> to the general rule.
>>
>> Just like our goal is that existing APIs continue to have the same
>> semantics in newer versions of the platform, so you can take a piece
>> of code written for an older version and run it unchanged on a newer
>> version, our goal is that deployment descriptors behave similarly.
>> Ideally, you could take an old deployment descriptor, change the DTD
>> or schema version number, and it would have the same syntax and semantics
>> in the newer version.
>>
>> We haven't done as good with deployment descriptors as we've done with Java
>> APIs. In some cases, the semantics of existing elements in the deployment
>> descriptor have changed when moving to a new version. For example, there
>> were places where "$" in the text of an element had no special meaning,
>> but in newer versions it indicates a variable to be replaced.
>>
>> I don't know what the precise issue is with EL referenced above, but this
>> was certainly one of the compatibility issues we faced related to EL.
>> We could've instead made everyone explicitly enable the interpretation of
>> EL, but it's not clear that would've been a better choice even though it
>> would've been more compatible. At best, it's an exception to the rule.
>
> Yes, the issues I was referring to for EL are around the introduction of
> ${...} in 2.0 and #{...} in 2.1
>
> It may help to manage the expectations of developers if a note was added
> to JSP.3.3.2 (and may be elsewhere) that made clear that the behaviour
> described there is an exception rather than the rule.
This *is* captured in section EE.12.1.1 of the platform spec. If it's not
clear in the JSP spec, it should be.