users@javaee-spec.java.net

[javaee-spec users] Re: default resources

From: Florent BENOIT <Florent.Benoit_at_ow2.org>
Date: Fri, 7 Nov 2014 08:22:54 +0100

I think that the hole needs to be fixed/clarified before Java EE8 is
out because during this timeframe people are impacted.
For me #C is a better choice than #B as it's specified in the standard
descriptor.
But maybe B could be done by products until C/Java EE8 is done. (But
it will imply that products will have to maintain also their product's
specific switch when it will go in standard DD)

Florent


On Thu, Nov 6, 2014 at 11:20 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> 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.