OK, understood. Personally, I'd say this is a "nice to have"...
-----Original Message-----
From: Nigel Deakin [mailto:nigel.deakin_at_oracle.com]
Sent: Monday, April 23, 2012 6:04 AM
To: jsr343-experts_at_jms-spec.java.net
Subject: [jms-spec users] [jsr343-experts] Re: Re: (JMS_SPEC-90) Provide
simpler mechanism to refer to queues and topics in a portable way
Reza,
On 21/04/2012 01:48, Reza Rahman wrote:
> So the provider will dynamically create the queue or topic if it does not
exist? Otherwise, what's the value of this?
> Avoiding a JNDI lookup?
Proposal (B) Isn't concerned with creating the physical queue or topic
object. It's just a simpler way of manipulating the name. It removes the
need for the deployer to create the Queue or Topic administered objects in
JNDI, though if the deployer wants to do this, perhaps at a later stage,
they can still do so.
You can think of it as an even simpler alternative to the new
@JMSDestinationDefinition annotation or <jms-destination> deployment
descriptor element being proposed for Java EE 7 (which instruct the
container to create Queue or Topic administered objects in JNDI).
I'm trying to make Queue and Topic administered objects easier to use rather
than simply by-pass them. I don't want to encourage the use of
session.createQueue/createTopic (or similar API) in the code because this
ties the hands of the deployer and removes their ability to define the
actual queues and topics used by the application (which has always been a
key goal of JMS). I want to offer a much simpler way to configure
destinations for applications, whilst leaving unchanged the ability of the
deployer to override this behaviour by defining a <message-destination-ref>
element in the deployment descriptor which links to a Queue or Topic object
in JNDI.
Nigel
>
> On 4/20/2012 9:16 AM, Nigel Deakin wrote:
>> My earlier proposals for some new API to create Queue and Topic
>> objects didn't gain much support from this EG. I've thought about this
more, discussed it with colleagues, and come up with a new proposal.
>>
>> What am I trying to achieve here is to allow any application
>> (including Java SE or Java EE applications, a Java EE container, a
>> resource adapter, and tools) to create a Queue or Topic object in a
portable way without the need to obtain a connection factory, connection or
session first.
>>
>> I did consider adding new API to connection factory, but this
>> introduces a dependency on a vendor's JMS implementation which is
>> actually not necessary. JMS already defines a Queue or Topic object to be
simply a wrapper around a provider-specific queue or topic name, and I think
we should keep it as that.
>>
>> I also considered whether we should make the use of Queue and Topic
>> objects unnecessary by adding new methods to JMS which simply took a
>> String name instead of a Queue and Topic. I decided this was
>> undesirable for two reasons: it would bloat the API with yet more
>> methods, but more importantly because the concept of a Queue and Topic
object remains a useful one in JMS (and Java EE) because by allowing Queue
and Topic objects to be bound in JNDI it allows application code to be
separated from queue and topic names.
>>
>> Below are two separate proposals: a new feature in JMS, and a
>> tentative proposal for Java EE which exploits this feature. (We would
need to discuss the latter in detail with the Java EE platform spec EG).
>>
>> Please give your comments or questions on both (A) and (B).
>>
>> A: JMS Proposal
>> ---------------
>>
>> I propose that JMS defines two classes: javax.jms.QueueImpl (which
>> implements the javax.jms.Queue interface) and javax.jms.TopicImpl
>> (which implements the javax.jms.Topic interface). These are classes,
whose implementation is provided by JMS.
>>
>> Here is what javax.jms.QueueImpl would look like:
>>
>> public final class QueueImpl implements Queue { String queueName;
>> public QueueImpl(String queueName) { this.queueName = queueName; }
>> public String getQueueName() throws JMSException { return queueName;
>> } }
>>
>> javax.jms.TopicImpl would be similar.
>>
>> So an application could create a Queue by calling
>>
>> Queue queue = new QueueImpl("myQueue");
>>
>> We would then define that any existing JMS API call which accepted a
>> javax.jms.Destination must be able to accept a QueueImpl or
>> TopicImpl, any existing JMS API call which accepted a javax.jms.Queue
must be able to accept a QueueImpl, and any existing JMS API call which
accepted a javax.jms.Topic must be able to accept a TopicImpl.
>>
>> This would be very simple for vendors to implement, since they can
>> simply use the existing createQueue/createTopic methods on Session
>> (which they already implement) to convert the queue or topic name to
whatever provider-specific class they currently use to implement Queue and
Topic.
>>
>> For example, the implementation of Session.createConsumer would need to
be modified as follows:
>>
>> Existing implementation:
>>
>> public MessageConsumer createConsumer(Destination destination) throws
>> JMSException { return
>> someProprietaryCodeToCreateConsumer(destination);
>> }
>>
>> New implementation:
>>
>> public MessageConsumer createConsumer(Destination destination) throws
>> JMSException { if (destination instanceof QueueImpl){ return
>> someProprietaryCodeToCreateConsumer(createQueue(destination.getQueueN
>> ame()); } else if (destination instanceof TopicImpl){ return
>> someProprietaryCodeToCreateConsumer(createTopic(destination.getTopicN
>> ame());
>> } else {
>> return someProprietaryCodeToCreateConsumer(destination);
>> }
>> }
>>
>> Some minor details:
>>
>> * We would need to define that it was valid to pass a QueueImpl or
>> TopicImpl into Message.setJMSReplyTo, though Message.getJMSReplyTo would
be free to return a proprietary implementation.
>>
>> * We would clarify that implementations of
>> Session.createQueue/createTopic and Message.getJMSReployTo would be free
to return a proprietary implementation of Queue or Topic in all cases, or
they could return a QueueImpl or TopicImpl.
>>
>> B: Java EE Proposal
>> -------------------
>>
>> The above change would make it possible to consider some new features
>> for Java EE. This is because for the first time it would be possible for
a Java EE container to inject a Queue or Topic object without the need to
use JMS provider code.
>>
>> It is proposed that we define some default behaviour when injecting a
Queue or Topic object into a Java EE application.
>>
>> An application can currently inject a Queue object as follows:
>>
>> @Resource(name="myQueueName")
>> Queue myQueue;
>>
>> Java EE states that the name attribute is used to specify a
>> "destination reference name". The application deployer is responsible
>> for creating a Queue object, binding it to some location of JNDI, and
>> providing a <message-destination-ref> element which maps the specified
name to the JNDI name of the Queue object. If there is no such mapping, or
if there is no such JNDI object, a deployment error occurs.
>>
>> We could propose that if the specified destination reference name is
>> not mapped to a JNDI name then the container will automatically
>> instantiate a QueueImpl, using the specified destination reference name
as the queue name, and inject it into the application.
>>
>> This would offer a much simpler way to configure destinations for
>> applications, whilst leaving unchanged the ability of a deployer to
override this behaviour by defining a <message-destination-ref> element in
the normal way.
>>
>> Note that the Java EE 7 Early Draft already proposes a way for a
>> container to inject a "platform default connection factory". These two
features together will significantly simply the use of JMS for smaller or
less complex applications.
>>
>> There are a few details related to this Java EE proposal that would need
to be considered:
>>
>> * We may want to define some similar default behaviour for MDBs.
>>
>> * We would need to check whether there were any restrictions on valid
>> characters in @Resource(name="..."), since this would limit the queue or
topic names that could be specified in this way.
>>
>> * This wouldn't be possible the application injected a Destination
>> rather than a Queue or Topic, since the container wouldn't know whether
to create a QueueImpl or a TopicImpl.
>>
>> Nigel
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1913 / Virus Database: 2411/4946 - Release Date:
>> 04/19/12
>>
>>
>