On Wed, Aug 12, 2015 at 10:30 AM, Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:
> On 12/08/2015 00:56, David Heffelfinger wrote:
>
>> I'm working on a project where we are using IBM MQ Series as our Message
>> Oriented Middleware, to allow JNDI lookups to
>> find queues, topics and connection factories defined in IBM MQ,
>> developers need to create a .bindings file, as described
>> in
>> http://stackoverflow.com/questions/967051/understanding-mq-series-bindings-files
>> .
>>
>> This bindings file is very cumbersome to create, and the procedure is
>> very error prone. If there could be a way to map
>> JNDI names to the Message Oriented Middleware product specific names it
>> would really make things easier for application
>> developers.
>>
>> I'm not opposed to using JNDI, it just would be nice to be able to map
>> the product specific names to the JNDI names
>> defined in the application server, ideally through an annotation right on
>> the MDB or messaage listener.
>>
>
> Can you explain what you have in mind in a bit more detail?
>
I'm thinking from an application developer's perspective. I just don't want
to have to create the cumbersome .bindings file to map JNDI name to
Messaging Middleware specific name, something along the following lines,
@QueueMapping(jndiName="jndi/someQueue", momName="SOME.QUEUE")
The above annotation would be placed at the class level of an MDB or JMS
listener, and would translate the JNDI name to the message oriented
middleware specific name.
>> Please let me know what you guys think.
>>
>
> Back when we discussed JMS 2.0, and more recently, we have considered
> various proposals to define a standard way to create connection factory,
> queue and topic objects which
>
> a. keeps applications as portable as possible whilst
> b. avoiding the need to use JNDI
>
> However each time we didn't reach consensus on what we should do and no
> conclusion was reached. That doesn't mean that the need still isn't there,
> just that it is not easy!
>
> I think part of the problem is that different people had different use
> cases in mind. There are at least three cases:
>
> 1. API for use by a simple Java SE client to create a connection factory,
> queue or topic object.
>
> 2. API to for use by a Java EE application (servlet, EJB etc) to create a
> connection factory, queue or topic. In this case the connection factory
> object is likely to be implemented by a resource adapter. (And how would
> such a API relate to the existing SPI to instantiate resource adapter
> ManagedConnectionFactory, Queue and Topic objects?) JMS_SPEC-172 (mentioned
> in the subject line) relates to this use case.
>
> 3. SPI used by a resource adapter (or other Java EE wrapper) to create a
> given vendors' Java SE connection factory, queue or topic object which it
> will then wrap to add Java EE behaviour.
>
> In all three, the API/SPI should be capable of supporting multiple JMS
> providers (and in case (2), multiple resource adapters) in the same
> application. So there was a bootstrapping problem to decide what object to
> start from. (Obviously we did have ideas on how to solve it)
>
> We also ran into difficulties with queues and topics objects. Essentially,
> the act of creating a Queue or Topic object in the application is not the
> same as creating the underlying queue or topic in the underlying JMS
> server, and it wasn't clear whether we should be trying to provide APIs for
> both.
>
> Despite all this, it's worth trying again, perhaps picking one specific
> use case and tacking it alone
>
All good points, hopefully we can give it a shot.
David
--
http://ensode.net - A Guide to Java, Linux and Other Technology Topics
My Books: http://www.packtpub.com/authors/profiles/david-heffelfinger
My Video Training:
http://www.packtpub.com/java-ee-development-with-netbeans-7/video
Follow me on Twitter: https://twitter.com/ensode