(I probably won't be able to post to the users list so someone will need
to forward this...)
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.)
>> 1. The JSP EG took the opposite view regarding EL expressions.
>>
>> 2. It means an application that declares itself to be a 2.5 application
>> may behave differently on a 3.0 Servlet container than a 2.5 servlet
>> container due to the presence of annotations. Depending on where the
>> annotations are, that may be unexpected.
>
> The application would explicitly use an annotation in the code - so the behavior
> will be expected by the application by the fact that it used the particular
> annotation.
And in particular this supports an important use case.
If you start by developing an application for Servlet 2.5 and then
want to move to Servlet 3.0 and take advantage of the new features,
you really don't want to be forced to covert your entire application
to know about Servlet 3.0. You'd like to be able to change just the
part that needs to use the new features. If that's one Servlet class,
it's a lot better if you can just leave the deployment descriptor
alone. You can continue to use whatever tooling you might've used
to create or manage the deployment descriptors while upgrading just
a part of your application.
>> I don't see an obvious solution here. It would be very difficult to
>> prevent an application with a 2.5 descriptor using a method that was
>> introduced in 3.0. Not impossible, but difficult and certainly it would
>> add unwanted overhead (not scanning for annotations is easy).
>
> You avoid scanning of annotations via the metadata-complete in the descriptor.
>
>>
>> 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.