I added to some existing auto create address logic in the code path which suffices for my test case. It does appear a little hacky to have three xxToUse local variables and the toString messing on simpleString does not look right.
One thought was to pass a null routingtype to this method but it is not clear to me where that decision should be made. Pulling the value from config for the auto creation case does make sense however.
Please review and maybe it is time to consider pulling all of the auto creation logic into one place.
@mtaylor Pushed an update, with the check in the openwire session the change set is smaller and the new tests with an existing address work as expected.
the prefixing remains and the case of multiple routing types is handled already by returning the first entry in the set which may need a revisit when the prefix is handled.
hmm, all the tests had a createProducer earlier that auto created the address.
With a createConsumer first I see the problem, the bindingQuery AddressInfo is null.
Passing a null routing type in that case and some tidy up in auto address creation in serverimpl works but the routingType comes from defaultConfiguration rather than the address settings in that case.
Question - should the caller figure the routingType from the addressSettings and if so should the logic for null routingType in createQueue get whacked?
adding the logic to figure the routingType as the path of least resistance and the most explicit. The null routing type autocreateaddress case does not work in createQueue - maybe that is an indication that the relevant code can be removed.