Nigel,
On 2012-03-27, at 19:25, Nigel Deakin wrote:
> Currently this is up to the provider. Session.createTopic(name) is allowed to throw an exception if the topic hasn't been administratively created, but since several JMS providers also use this method to create the topic (despite the spec discouraging it) I think we need to recognise this officially. Please see http://java.net/jira/browse/JMS_SPEC-31
>
> We could define a new method which never creates the topic (i.e. any auto-creation feature is disabled), though I can't see why you would want to do this. Given that auto-creation is a JMS provider specific feature, disabling it should be too.
The code would be not portable, then. Maybe it should be required... and thereby making the name a little bit more clear about what will happen. Actually it should best be getOrCreate.
I still think that if you have many applications accessing one messaging system, auto-creation can become very annoying. If one of the applications has a bug, you don't want to go around searching for which one might have created that strange new queue. In that case it would be better if the application itself would receive an exception instead.
So I think that the spec should also require a feature to disable this behavior.
> Given that createQueue and createTopic are already methods on Session (and JMSContext), existing implementations may rely on having a connection to the server (we can't know whether they do or not). We could add equivalent methods to Connection, but I think this would probably just clutter the API. After all, you always need a Session (or JMSContext) before you can use a Queue or Topic object for anything.
>
> Nigel
>
>
> On 27/03/2012 15:34, John D. Ament wrote:
>>
>> Nigel, Ruediger,
>>
>> I believe in all cases, this is currently on ConnectionFactories. Should there be any distinction between:
>>
>> .getTopic(String)
>> .createTopic(String)
>>
>> e.g. getTopic would fail (throw Exception?) if the given topic does not exist?
>>
>> John
>>
>> On Tue, Mar 27, 2012 at 10:30 AM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
>> I have logged this issue
>> http://java.net/jira/browse/JMS_SPEC-90
>> in order to capture the issue raised by Ruediger's thread "Why are Destinations resources and not Strings?"
>>
>> This is really a placeholder currently - I haven't got any specific proposals to make (though I know Rüdiger had some stronger ideas which he may wish to add to the JIRA). I just want this to be in JIRA so we can have a debate over which issues we should work on next.
>>
>> Nigel
>>
>> Provide simpler mechanism to refer to queues and topics in a portable way
>> -------------------------------------------------------------------------
>>
>> In the JMS 1.1 API, individual queues and topics are referred to not by name but by using javax.jms.Queue and javax.jms.Topic objects, where the javax.jms.Queue and javax.jms.Topic interfaces both extend the javax.jms.Destination interface.
>> This is because JMS 1.1 expects the way that a queue or topic is specified to be proprietary to a JMS provider. In order to allow these proprietary aspects to be isolated from the application, JMS 1.1 expects javax.jms.Queue and javax.jms.Topic objects to be "placed in a JNDI namespace by an administrator", for subsequent lookup by a portable application.
>>
>> Another benefit of storing queue and topic objects in JNDI is that it allows an administrator (or, in Java EE, a deployer) to configure a mapping between the queue or topic JNDI name specified in the application with the actual queue or topic name used by the JMS provider which can be modified without the need to change the application code.
>>
>> Applications can by-pass this mechanism by using the createQueue(String name) and createTopic(String name) methods on Session to convert a provider-specific queue or topic name to a javax.jms.Queue or javax.jms.Topic object. Since queue or topic names are not portable this usage is, however, not recommended.
>>
>> There are two main reasons why an application might want to avoid the need to bind and lookup objects in JNDI. For a Java SE application which would otherwise have no use for JNDI, this is an additional complication for the application. For a Java EE application which uses many thousands of destinations (e.g. a market data application that uses a separate topic for every stock code on a stock exchange), then even though a JNDI provider comes built-in, having to create many thousands of administered object is an administrative burden.
>>
>> This issue therefore raises the issue of whether JMS should be enhanced to allow applications to refer to queues and topics in a portable way without always having to create administered objects in JNDI. Possibilities include:
>>
>> * Perhaps defining a portable format for queue and topic names to allow the use of createQueue(String name) and createTopic(String name) methods on Session to be portable.
>>
>> * Perhaps providing methods on JMSContext which allow a queue or topic to be specified as a string (and which therefore call createQueue(String name) or createTopic(String name) internally) - though this might require the domain required (queue or topic) to be passed in as an additional parameter.
>> * Perhaps adding some defaulting mechanism to the JNDI namespace to allow a javax.jms.Queue or javax.jms.Topic to be looked up in JNDI in some special namespace and for the administered object to be created dynamically.
>>
>> * There are other possibilities which might be considered as well.
>>
>>
>>