The advantage of Option B is that we can do it for EE 7 in an MR. Option C can
only be done in EE 8. Doing Option B does not preclude doing Option C.
It sounds like there's support for D + B + C.
Anyone else have an opinion?
Kevin Sutter wrote on 11/18/14 11:31:
> 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/