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
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.
>>> 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.
Mark