Hi,
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 <bill.shannon_at_oracle.com> wrote on 11/11/2014 02:36:52 PM:
> From: Bill Shannon <bill.shannon_at_oracle.com>
> To: jsr366-experts_at_javaee-spec.java.net
> 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
example,
> > if you define a DataSource resource or a JMS connection factory
resource,
> > 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
in
> > an error at deployment time. The newly defined behavior fails to
consider
> > 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
absence
> > 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,
and
> > nothing in the deployment descriptors, I would normally expect
thedeployment
> > 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,
the
> > 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
whether
> > the behavior follows the Java EE 7 rules or the product-specific
rules.
> > The switch might be per-application or global, but the default must
be
> > 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
depended
> > on the old product-specific behavior to continue to work, but only
if
> > 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
product-specific
> > implicit mapping as long as that product-specific resource exists.
If
> > the product-specific resource does not exist, the resource mustbe
mapped
> > to the platform-defined default resource. This somewhat reduces
> > portability while providing some compatibility with existing
products
> > that use implicit mapping rules.
> >
> > 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.
> >
> > Thanks.
>