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