On 5/25/2012 12:07 PM, Bill Shannon wrote:
> 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!
>
The Java EE 7 Platform spec Early Draft states the following (in section 8.5,
"Deployment"):
"Note that the deployment descriptor version refers only to the version of the XML schema
or DTD against which the descriptor is to be validated. It does not provide any
information as to what version of the Java EE platform the application is written to."
I propose adding the following text:
"In particular, the version of the deployment descriptor does not otherwise determine
what APIs or container features can or cannot be used or the semantics of those features."
Do you all think that will be clear enough?
-Linda
>>>>> 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.