[javaee-spec users] [jsr366-experts] Re: default resources

From: Kevin Sutter <>
Date: Mon, 17 Nov 2014 15:07:32 -0600

This thread seems to have taken several different turns, so I'm going to
revert back and reply to Bill's that started the original discussion and
asked for feedback from other EG members...

(Aside... Normally, we try to stay away from product-specific discussions
in the EG. But, since this topic is very much product-specific, I might
drop a few references to WebSphere below...)

I re-raised this topic of product-specific default resource mappings back
in June 2013 (Subject line "Clarification on Default resources"). But,
this wasn't the first time it was raised. Looking back in the archives, I
had noticed that both Werner and David had some issues with existing
product-specific default resource mappings. I was trying to get some
buy-in from these guys... Unfortunately, the discussion died on the
vine... I pushed for a bit, but when it didn't gain traction, I didn't
follow up... I guess I should have continued to push.

Based on our (WebSphere) experiences, we have determined the only viable
solution is Option (D) in Bill's note below. WebSphere had previously
defined the ability to define resource mappings before they became part of
the spec. We have to continue to honor those mappings to make for happy
customers. In the absence of these WebSphere default mappings, then we
will fallback to the Java EE 7 default mappings. A "pure" Java EE 7
application would not have an issue with this approach, and would continue
to be portable.

Kevin Sutter

Bill Shannon <> wrote on 11/11/2014 02:36:52 PM:

> From: Bill Shannon <>
> To:
> Date: 11/11/2014 02:42 PM
> Subject: [jsr366-experts] Re: default resources
> I'd still like to get feedback on this from the rest of you!
> Come on, experts, I'm sure you're capable of forming an opinion on this!
> Bill Shannon wrote on 11/05/14 16:06:
> > Here's a small issue to get the expert group started!...
> >
> > There are several places in Java EE 7 where we defined that unmapped
> > resources must be mapped to the platform default resources. For
> > if you define a DataSource resource or a JMS connection factory
> > but it's not mapped to a specific (portable or platform-specific)
> > resource, it must be automatically mapped at deployment time to the
> > corresponding platform default resource.
> >
> > See EE.5.19, EE.5.20, and EE.5.21.
> >
> > Previously, the expectation was that unmapped resources would result
> > an error at deployment time. The newly defined behavior fails to
> > two cases:
> >
> >
> > 1. The resource might be mapped using a product-specific
> deployment descriptor.
> >
> > The intent was that the default mapping would only occur in the
> > of any explicit mapping. The spec will need to make this clear.
> >
> >
> > 2. The resource might be mapped using a product-specific implicit
> mapping rule.
> >
> > This case is more problematic. With nothing in the application code,
> > nothing in the deployment descriptors, I would normally expect
> > 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. With the Java EE 7 mapping rules,
> > mapping of such resources might change.
> >
> >
> > How should we handle case #2?
> >
> > A. The product redefined an error case to be a non-error case, which
> > conflicts with the Java EE 7 spec. The product has to change.
> >
> > B. The spec should allow a product-specific switch that controls
> > the behavior follows the Java EE 7 rules or the product-specific
> > The switch might be per-application or global, but the default must
> > to follow the Java EE 7 rules.
> >
> > C. The spec should define a per-application switch to control whether
> > unmapped resources are mapped to the platform default resources or
> > are handled in a product-specific way. The default behavior would
> > be as specified in Java EE 7. This allows applications that
> > on the old product-specific behavior to continue to work, but only
> > the application is changed.
> >
> > D. The spec should allow a resource with no explicit mapping to be
> > mapped to an existing product-specific resource using a
> > implicit mapping as long as that product-specific resource exists.
> > the product-specific resource does not exist, the resource mustbe
> > to the platform-defined default resource. This somewhat reduces
> > portability while providing some compatibility with existing
> > that use implicit mapping rules.
> >
> > Note that parts of B, C, and D could all be done; these choices need
> > be exclusive.
> >
> > Please let me know what you think.
> >
> > Thanks.