users@javaee-spec.java.net

[javaee-spec users] Re: default resources

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 06 Nov 2014 14:20:29 -0800

arjan tijms wrote on 11/06/2014 03:37 AM:
> Hi,
>
> On Thu, Nov 6, 2014 at 1:06 AM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>> 2. The resource might be mapped using a product-specific implicit mapping rule.
>>
>> This case is more problematic. With nothing in the application code, and
>> nothing in the deployment descriptors, I would normally expect the deployment
>> to fail. Some products may have mapped any unmapped resources to some
>> administrator-defined product-specific resource using some undefined
>> name mangling or defaulting rules.
>
> For reference, here's a discussion with details about one such
> product: https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-06/message/2

It's kind of depressing that none of our experts complained about this
when we introduced this new default mapping.

It's also depressing that our pre-EE7 CTS didn't have a negative test case to
test deployment failure when no mapping was specified for a resource.

>> How should we handle case #2?
>> [...]
>>
>> Note that parts of B, C, and D could all be done; these choices need not
>> be exclusive.
>>
>> Please let me know what you think.
>
> What about having an EE 7 deployment descriptor as the main switch, in
> combination with C (per application switch)?
>
> The idea would be that applications depending on this product specific
> default behaviour would have to be Java EE 6 or earlier applications,
> since the mapping change was introduced in Java EE 7. Those
> applications should thus also have an EE 6 deployment descriptor, or
> no descriptor, but definitely not an EE 7 one.
>
> If they are upgrading to a Java EE 7 server, then running with an EE 6
> descriptor would mean the default resource mapping does not happen,
> and the app runs unchanged. If they update their deployment descriptor
> to EE 7 the default resource mapping does happen, but at that point
> they have been changing their descriptor anyway, so it would be a
> small amount of extra effort to put the per-application switch in at
> that time to switch this mapping off right away.
>
> One complication is that Java EE 7 has been on the market for some
> time now, so there can be a couple of applications out there that have
> Java EE 6 descriptors yet are relying on a default resource anyway. So
> if this is about a Java EE 7 MR change, then the deployment descriptor
> based switch could be stated slightly weaker by saying "the product is
> allowed to switch based on the DD".
>
> With that last one in place there remains a tiny portability case;
> applications having an EE 6 desployment descriptor, currently running
> on an EE 7 server (which is thus GlassFish or WildFly that both don't
> do product specific mapping) that are in the future migrated to an EE
> 7 server that does use the DD switch (if it's indeed about an EE 7
> MR). But I guess this group is really small and people expect some
> issues when switching between different servers anyway.

A consistent principle we've had with the deployment descriptors is that
the version of the deployment descriptor says nothing at all about the
version of the platform the application is targeting.

Old applications can be upgraded to use a new deployment descriptor with
new features, without other changes to the application.

New applications can use old format deployment descriptors if they only
need the features available in the older descriptors.

That's not something we're going to change.

Given that, do you think C is the best choice? Note that C can only be
done in EE 8, leaving us a hole until then. B and D could be done with
an MR to EE 7. We could, of course, do B or D now, and C in EE 8.