Nigel,
What if we used QueueReference instead of QueueImpl (and
TopicReference...TopicImpl)?
John
On Mon, Apr 23, 2012 at 6:25 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> On 21/04/2012 23:18, Rüdiger zu Dohna wrote:
>
>>
>> I would like to replace both options with code like this:
>>
>> public void sendMessageNew(String payload) {
>> context.send("myQueue", payload);
>> }
>>
>
> The problem with this is that it means that the queue name cannot be
> overridden by a deployer or administrator at some point in the future
> (without changing the code). JMS has always encouraged keeping queue and
> topic names out of the code but instead encapsulating them in administered
> objects which can be looked up from JNDI. My proposal (B) is an attempt to
> getting the best of both worlds by allowing the developer to hardcode a
> queue or topic name in the application but still allow it to be overridden
> by the deployer or administrator.
>
> My proposal B (if the Java EE folks allow it) would change this to
>
> @Resource(name="myQueue")
> Queue queue;
>
> public void sendMessageNew(String payload) {
> context.send(queue, payload);
> }
>
> This was a deliberate attempt to achieve the simplicity you were asking
> for (having queue and topic names in the code) without losing the ability
> of the deployer/administrator to override this.
>
>
>
>> I'm very well aware that there is a huge difference between a JNDI name
>> and the provider-specific destination name
>> passed into createQueue/Topic and returned by Queue.getQueueName/Topic.**getTopicName.
>> But I don't care! This distinction
>> gives me no benefit, it only makes my life harder.
>>
>> I'm also aware that they have different name spaces: In the first
>> example, the String is obviously unique within JNDI;
>> in the second, it must be unique to the JMS provider and destination type
>> (actually, you can regard the type to be part
>> of the address); in the third, it would have to be unique to the JMS
>> provider. But that's not really a problem, is it?
>> We're talking about new methods, so there's not legacy code we have to
>> consider.
>>
>> The destination name that I put into my code should be purely business
>> driven, i.e., it should not have to adhere to the
>> JNDI naming conventions (i.e., prefixes), nor to the addressing scheme
>> the JMS provider might use. It actually sort of
>> identifies the logical endpoint of the sender, not the physical
>> destination where the messages go to... so when a
>> physical queue is created, this endpoint has to be bound to that queue...
>> conventions may even allow to do this on
>> demand... but creating physical destinations is a completely different
>> topic.
>>
>
> I'm a little confused where you're going with this. "The destination name
> that I put into my code should be purely business driven" seems to be a
> description of what JMS and Java EE tries to do right now. The application
> defines the queue or topic in terms of a "logical name", perhaps which
> relates to its role in the application, and the deployer or administrator
> maps that to the real queue or topic in the JMS server. Given that Java EE
> has chosen JNDI as the technology to do this across the whole platform I
> think we're stuck with it, but a naming hierarchy is a pretty flexible and
> easy-to-understand concept. The "prefixes" you mention are really to allow
> these logical names to have scopes (component, application, global etc)
> which seems a useful feature to me, and there is always a default.
>
> Nigel
>
>
>
>