Here's the wording from the spec: InvalidDestinationException: This exception must be thrown when a destination is either not understood by a provider or is no longer valid.
Looks like we give back the InvalidDestinationException from the client code, but we give back a DestinationDoesNotExistException from within the broker when trying to use and not valid. Could just send back an InvalidDestinationException from the broker too? On Wed, May 22, 2013 at 12:02 PM, Timothy Bish <[email protected]> wrote: > On 05/22/2013 03:00 PM, Christian Posta wrote: > >> All, >> >> I've noticed this before, and just ran into the problem myself. >> Subscribing to advisories for temp topics by default seems a little >> overkill... >> >> This can be enabled for those clients using temp destinations and want to >> save a sync trip to the broker if the dest is not available.... but for >> most connections, why should we take the cost of hearing about those when >> we don't need them? >> >> I propose changing the default for jms.watchTopicAdvisories=false with >> changes to the docs explaining you should enable it if you're using temp >> dests... would this cause too much trouble for existing users? >> >> Thanks, >> Christian >> >> First thought is that it might cause the client to violate JMS specs > surrounding when it should throw InvalidDestinationExceptions but I could > be wrong. > > -- > Tim Bish > Sr Software Engineer | RedHat Inc. > [email protected] | www.fusesource.com | www.redhat.com > skype: tabish121 | twitter: @tabish121 > blog: http://timbish.blogspot.com/ > > www.camelone.org : The open source integration conference: > > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
