>
> Perhaps I misunderstand what you are saying, providing multiple
> addressing via JNDI will not cause any vendor lock in except in the
> format and functionality that is specified in the BindingURL (Again
> this should be an AMQP specified format, which would remove that
> problem) There would be zero requirement for non pure JMS code in the
> client library as they would simply do:
>
> Destination specialDestination =
> (Destination)jndiContext.lookup("SpecialAMQPDestination");
>
> That is pure JMS + JNDI no AMQP lock-in.
That is pure JMS code with not standard JMS semantics. If your
application uses this special destination for sending messages to
several queues you'll then need to re-write it when migrating to another
JMS provider. What you are doing is introducing a vendor lockin as your
application will not behave as expected with a "standard" JMS
implementations. So, what I am saying is that such JMS extensions should
maybe not be hidden into config files.
