[
https://issues.apache.org/jira/browse/AMQ-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Aaberg updated AMQ-5895:
-------------------------------
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:
{code}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]
{/code}
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:
{code}
\} else if
(DtoFilteredDestination.class.isAssignableFrom(elementContent.getClass())) \{
return new FilteredDestination();
{/code}
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.
Perhaps I can also submit the bug fix myself if that can speed up the process.
was:
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:
{code}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]
{/code}
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:
{code}
} else if
(DtoFilteredDestination.class.isAssignableFrom(elementContent.getClass())) {
return new FilteredDestination();
{/code}
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.
Perhaps I can also submit the bug fix myself if that can speed up the process.
> FilteredDestinations do not work when loaded by runtimeConfigurationPlugin
> --------------------------------------------------------------------------
>
> Key: AMQ-5895
> URL: https://issues.apache.org/jira/browse/AMQ-5895
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.11.1
> Environment: Both windows / linux, IBM java 6 / Oracle Java 7
> Reporter: Anders Aaberg
> Labels: runtime-configuration, virtualDestinations
> Attachments: activemq.patch, stacktrace.txt, steps_to_reproduce.txt
>
>
> 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:
> {code}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]
> {/code}
> 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:
> {code}
> \} else if
> (DtoFilteredDestination.class.isAssignableFrom(elementContent.getClass())) \{
> return new FilteredDestination();
> {/code}
> 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.
> Perhaps I can also submit the bug fix myself if that can speed up the process.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
