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