Weblogic connector should allow destinations lookup over JNDI

[danielkec]

Weblogic connector uses JMS createDestination methods, those are using custom WLS CDI syntax, we should provide JNDI lookup alternatives.

destination: ${cdi-identifier} x jndi.destination: ${jndi-identifier}

Backports:

• [x] #6303

:warning: This is an enhancement request to provide alternative for legacy systems, JNDI-less JMS usage is still a preferred approach for all JMS based Helidon connectors.

[tbarnes-us]

IMO, JNDI should become the standard approach, and the 'createDestination' approach should be deprecated and discouraged - not just for WebLogic but for all JMS vendors:

(1) The JMS specification itself encourages the use of JNDI and discourages the use of the createDestination methods. The following is a quote from the related JMS javadoc:

'The use of provider-specific queue names in an application may render the application non-portable. Portable applications are recommended to not use this method but instead look up an administratively-defined Queue object using JNDI.'

(2) JNDI is the most portable approach. As an example of its portability, JNDI is used by WebLogic's built-in JMS integration tooling to successfully integrate a very wide variety of JMS vendors.

(3) When JMS is in the picture for WebLogic customers, JNDI is the de facto standard approach for accessing both WebLogic JMS and that of other JMS vendors. Almost all WebLogic customers for both connection factory and destination lookups, and the documentation of the rarely used alternative 'create destination' approach is relegated to an appendix.

[tbarnes-us]

Side notes:

• In my opinion, Helidon would supply a generic adapter/factory for plugging in any arbitrary JMS using JNDI lookups. To be fully generic, it would bootstrap not only destinations, but also JMS connection factories, and would therefore avoid the need to have any code specific to any particular vendor.

• Such an adapter should ideally also pool, wrap, and reuse JNDI lookup results, connections, sessions, producers, and consumers - only removing them after an error or if too many idle instances end up accumulating in a pool... (This can yield a multi-X speedup - similar in concept to the speedup yielded by using datasource pools...) WL has a 'built-in' version of such which dynamically generates the wrappers in a way that direct access to proprietary extensions of the JMS provider, and which knows how to 'reset' JMS objects that are returned to its pools to a vanilla state...