[AMQ-5895] FilteredDestinations do not work when loaded by runtimeConfigurationPlugin

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.11.1
• Fix Version/s: 5.12.0
• Component/s: Broker
• Labels: runtime-configuration virtualDestinations

Environment

Both windows / linux, IBM java 6 / Oracle Java 7

• Patch Info: Patch Available
• Assignee: Gary Tully
• Reporter: Anders Aaberg
• Created: 17/Jul/15 15:34
• Updated: 29/Jul/15 11:50
• Resolved: 29/Jul/15 11:50

Description

When adding a FilteredDestination to VirtualDestinations in activemq.xml, the runtimeConfigurationPlugin will not update the configuration correct for the filteredDestination. The log does not give any errors until we send a message towards the CompositeTopic/Queue that contains the FilteredDestination, then the message is not forwarded and the following error is written in the log:

java.lang.IllegalArgumentException: Unknown mapped destination type java.lang.Object@7a141450
        at org.apache.activemq.broker.region.virtual.CompositeDestination.getMappedDestinations(CompositeDestination.java:124)[activemq-broker-5.11.1.jar:5.11.1] 

It works if we restart activeMQ, because then the configuration is not loaded by the runtimeConfigurationPlugin, however we really want to avoid that.

Solution: It seems that the translation from JAXB objects to ActiveMQ objects is not translating DtoFilteredDestination to FilteredDestinations in org.apache.activemq.plugin.JAXBUtils.

When I added the following code to the method "inferTargetObject", then the problem was solved:

        } else if (DtoFilteredDestination.class.isAssignableFrom(elementContent.getClass())) {
            return new FilteredDestination();

Why this matters: In my organisation we really like to use ActiveMQ VirtualDestinations with FilteredDestinations, because it is a much more minimalistic than having to make many simple subscriptions in Camel and it has many benefits compared to durable subscribers. However, we do not wish to restart ActiveMQ every time we modify the VirtualDestinations, hence we need to be able to updated the VirtualDestinations using runtimeConfigurationPlugin and this does not work right now due to this bug.

I have added some files to this issue: a patch file, a full stacktrace and some steps to reproduce the problem.

Perhaps I can also commit the bug fix myself if that can speed up the process.