Rüdiger,
On 24/04/2012 10:50, Rüdiger zu Dohna wrote:
> Nigel,
>
> Currently a deployer has to create the physical destination, configure it, give it an address name, and put it into
> JNDI with a second name, so the client code can do the lookup.
>
> In my eyes, dependency injection is supposed to reverse only those last two steps: The code defines a logical
> endpoint and the deployer binds it to the physical destination he creates for the application.
>
> This would mean, that there are two options: 1) Auto-create a destinations to hold messages before they are bound, so
> the binding happens *after* the method runs and calls some send method. 2) Throw an exception if the endpoint is not
> bound (note that this behavior sounds ugly, but actually the same thing already happens, when the JNDI name is not
> bound).
My proposal B for Java EE would, as you say, eliminate the need for the deployer to create a Queue or Topic administered
object and bind it into JNDI, unless they wanted to override the queue or topic physical name hardcoded into the
application.
As you suggest, it doesn't concern itself with the creation of the physical queue or topic in the JMS provider, for
those JMS providers that require this. JMS 1.1 explicitly avoids concerning itself with how this is done.
I don't really follow what you are suggesting here.
> Auto-create a destinations to hold messages before they are bound, so
> the binding happens *after* the method runs and calls some send method.
In my proposal B I'm not suggesting that anything is actually bound into JNDI. I'm proposing that a Queue or Topic
administered object is created on-the-fly (by instantiating the class supplied with JMS) and injected into the application.
If the JMS provider supports auto-creation of physical destinations, and the administrator has enabled this feature,
then I would expect any such auto-creation to take place when the JMS API is first used to access the destination, such
as when sending a message or it, or perhaps creating a producer or consumer on it. Not when the Queue or Topic is looked
up or instantiated.
> Throw an exception if the endpoint is not bound
You mean that if the application or deployed descriptor specifies the JNDI name of a Queue or Topic object in JNDI but
no such object has been bound in the location specified? This will cause an error now, and I'm not suggesting this
should change.
(Remember that a JNDI name is specified either by explicitly specifying @Resource(lookup="jms/inboundQueue") (or
mappedName=) or by using @Resource("name=logicalQueueName") combined with a <message-destination-ref> element in the
deployment descriptor that maps that name to a Queue or Topic object in JNDI.
My proposal is that if the application specifies @Resource("name=logicalQueueName"), and there is no
<message-destination-ref> element in the deployment descriptor that maps that name to a Queue or Topic object in JNDI,
then the container should instantiate a Queue or Topic object, set it to refer to a queue or topic named
"logicalQueueName" and inject it into the application. Currently this would cause a deployment error.
>
> If we are willing to go further down that road, another option would be to invert even more... I'm aware that this
> would be a huge change to the already proposed simplified API and would require a lot of rethinking again. The code
> could look like this:
>
> @JMSEndpoint @ConnectionFactory(...) public JMSDestination destination;
>
> public void sendMessage(String payload) { destination.send(payload); }
>
> The injection point would by default be identified by the application name, module name, bean name, and field name.
> The last three could be overridden by annotation attributes.
>
> Deployment tools could scan the annotations and ask the deployer to create and bind the destinations required. This
> also could be automated in a cloud environment by adding some destination deployment descriptor that include the
> provider-specific destination address, destination type, queue length, etc. And to finish the round trip, these could
> also be set by annotations like @DestinationAddress("hostname/appname"), @DestinationType(QUEUE),
> @DestinationOption("queue-length", "1024").
I'd need to ask lots of questions before I can give a sensible comment on this. Do you really want me to devote time to
this?
Nigel
>
> Crazy, eh? ;-) Rüdiger
>