Jason Greene <jason.greene_at_redhat.com> wrote on 11/18/2014 01:05:53 PM:
> From: Jason Greene <jason.greene_at_redhat.com>
> To: jsr366-experts_at_javaee-spec.java.net
> Date: 11/18/2014 01:11 PM
> Subject: [javaee-spec users] [jsr366-experts] Re: default resources
>
>
> > On Nov 18, 2014, at 12:48 PM, Jason Greene <jason.greene_at_redhat.com>
wrote:
> >
> >
> >> On Nov 17, 2014, at 6:49 PM, Bill Shannon <bill.shannon_at_oracle.com>
wrote:
> >>
> >> Let me describe another issue that has been raised in this area...
> >>
> >> If I have an application:
> >>
> >> @Resource(name="MyFactory",
type=javax.jms.ConnectionFactory.class)
> >> ConnectionFactory cf;
> >>
> >> with a deployment descriptor intended to supply the mapping for
> the resource:
> >>
> >> <resource-ref>
> >> <res-ref-name>MyFactroy</res-ref-name>
> >> <res-type>javax.jms.ConnectionFactory</res-type>
> >> <mapped-name>JMS1</mapped-name>
> >> </resource-ref>
> >>
> >> Note that we now have two resource references, one mapped to the
> >> default JMS connection factory and used by the application, and
> >> one mapped to the JMS connection factory named "JMS1" and not used
> >> by the application. A typo or misspelling might result in unintended
> >> mappings.
> >>
> >> Option D doesn't help with this at all.
> >>
> >> Option B would allow for a product-specific option that disables the
> >> default mapping behavior, allowing deployment of the above
application
> >> to fail.
> >>
> >> Is this a reason to consider Option B, perhaps in addition to Option
D?
> >
> > Hmm I think this use case is better handled in implementation
> validation code. As an example a warning from a tool or in the
> server such as "MyFactroy is remarkably similar to MyFactory,
> possible mis-spelling?” could be used.
> >
> > My worry with Option D is that it’s potentially ambiguous, with no
> clear path to resolve it. D + B would solve the ambiguity.
>
> Actually D + C is a better combination than D + B, if the goal ranking
is:
>
> 1. Allow vendors to maintain compatibility with pre-EE7 strategies
> 2. Maximize portability.
> 3. Limit the burden of portability.
First off, Jason, I agree with your earlier statement that some type of
validation code from the tools or the runtime would be better at
attempting to catch these type of misspellings. Misspellings in
deployment descriptors can cause all types of issues. I don't think we
want the Java EE spec to start mandating how to detect and report
configuration and usability issues.
I don't see a lot of difference between Option B and C, other than B is
product-defined and C is spec-defined. So, Option B would be easier to
implement and easier to specify in an MR. I'm still leaning towards
Option D + B, but I could probably be swayed to Option D + C. We just
need to allow the use of existing (pre Java EE 7) mappings.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter
STSM, Java EE and Java Persistence API (JPA) architect
mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
http://webspherepersistence.blogspot.com/
phone: tl-553-3620 (office), 507-253-3620 (office)
http://openjpa.apache.org/