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.getQueueName());
>> } else if (destination instanceof TopicImpl){
>> return someProprietaryCodeToCreateConsumer(createTopic(destination.getTopicName());
>> } 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
>>
>>
>