> 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.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat