[jira] [Commented] (AMQ-6941) Add option to allow anonymous vm://xxx connections
[ https://issues.apache.org/jira/browse/AMQ-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289498#comment-17289498 ] Quinn Stevenson commented on AMQ-6941: -- Anonymous users didn’t work because enabling them made them available both inside the VM and from outside - that was too open for us. We wound up using the plugin mentioned below so that if you were connecting from inside the same JVM, you didn’t need a user or password - it fit our needs perfectly. Quinn Stevenson qu...@pronoia-solutions.com (801) 244-7758 > Add option to allow anonymous vm://xxx connections > -- > > Key: AMQ-6941 > URL: https://issues.apache.org/jira/browse/AMQ-6941 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.11.4 >Reporter: Quinn Stevenson >Priority: Minor > > When deploying JMS components in the same JVM as an ActiveMQ broker, it would > be really nice to allow vm://broker-name connections to connect without a > username/password. > Either a new plugin could be added, or the Simple Authentication Plugin could > be enhanced. > There is a sample of a plugin that provides the basic functionality in my > Github repository > [https://github.com/hqstevenson/splunk-jms-activemq/tree/master/src/main/java/com/pronoia/splunk/jms/activemq/util] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-6941) Add option to allow anonymous vm://xxx connections
Quinn Stevenson created AMQ-6941: Summary: Add option to allow anonymous vm://xxx connections Key: AMQ-6941 URL: https://issues.apache.org/jira/browse/AMQ-6941 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: Quinn Stevenson When deploying JMS components in the same JVM as an ActiveMQ broker, it would be really nice to allow vm://broker-name connections to connect without a username/password. Either a new plugin could be added, or the Simple Authentication Plugin could be enhanced. There is a sample of a plugin that provides the basic functionality in my Github repository [https://github.com/hqstevenson/splunk-jms-activemq/tree/master/src/main/java/com/pronoia/splunk/jms/activemq/util] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6428) Add methods for sending messages to topics or queues
[ https://issues.apache.org/jira/browse/AMQ-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15543486#comment-15543486 ] Quinn Stevenson commented on AMQ-6428: -- I think I've got the PR fixed > Add methods for sending messages to topics or queues > > > Key: AMQ-6428 > URL: https://issues.apache.org/jira/browse/AMQ-6428 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Quinn Stevenson >Priority: Minor > > To simplify testing, the EmbeddedActiveMQBroker (in activemq-junit) should > have methods to send messages to topics and queues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6428) Add methods for sending messages to topics or queues
[ https://issues.apache.org/jira/browse/AMQ-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542723#comment-15542723 ] Quinn Stevenson commented on AMQ-6428: -- I tried squashing my two commits, but I think I screwed something up - the PR is showing a bunch of other commits from other people. I'm not exactly sure how to fix this other than closing the current PR and opening a new one. Is there an easier way? > Add methods for sending messages to topics or queues > > > Key: AMQ-6428 > URL: https://issues.apache.org/jira/browse/AMQ-6428 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Quinn Stevenson >Priority: Minor > > To simplify testing, the EmbeddedActiveMQBroker (in activemq-junit) should > have methods to send messages to topics and queues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-737) Add JUnit Rules
[ https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517904#comment-15517904 ] Quinn Stevenson commented on ARTEMIS-737: - @clebertsuconic -I had an idea - I noticed that none of the examples have a "unit test". I know you can run them with some the maven infrastructure that is available in the examples, but I thought it would be nice to have a unit test for an individual example. So I updated the "Bridge" example (examples/features/standard/bridge) and added a unit test using the EmbeddedJMSResource - can you give it a look? Note that I had to change the broker.xml files to get rid of a security exception I was seeing with the test - not really sure what's going on there. But if you like the idea, I could update a few more of the examples to include this type of unit test. > Add JUnit Rules > --- > > Key: ARTEMIS-737 > URL: https://issues.apache.org/jira/browse/ARTEMIS-737 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a > nice feature to have for Artemis as well, along with the JUnit rules for JMS > Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-737) Add JUnit Rules
[ https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511598#comment-15511598 ] Quinn Stevenson commented on ARTEMIS-737: - @clebertsucconic - yes, I'm getting the notifications. Sorry - I was away from my desk for a while. I tried to answer all the questions so far. I see I missed the checkstyle checks - I'll have to get those errors fixed and update the PR. > Add JUnit Rules > --- > > Key: ARTEMIS-737 > URL: https://issues.apache.org/jira/browse/ARTEMIS-737 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a > nice feature to have for Artemis as well, along with the JUnit rules for JMS > Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-737) Add JUnit Rules
[ https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511595#comment-15511595 ] Quinn Stevenson commented on ARTEMIS-737: - Yes - these rules are primarily targeted for end-users. The idea was to make it as simple as possible to write unit tests for applications that need a messaging back-end. > Add JUnit Rules > --- > > Key: ARTEMIS-737 > URL: https://issues.apache.org/jira/browse/ARTEMIS-737 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a > nice feature to have for Artemis as well, along with the JUnit rules for JMS > Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-737) Add JUnit Rules
[ https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511591#comment-15511591 ] Quinn Stevenson commented on ARTEMIS-737: - I don't necessarily think this approach is "better" than the existing test suite. I was looking for something simple for end-user testing - similar to what I contributed to ActiveMQ (activemq-junit) a while back. I don't have any expectations on whether or not these rules would help with testing Artemis itself - I'm not familiar enough with Artemis yet to have an informed opinion on that. So I wouldn't expect internal Artemis tests to use these Rules -but they could if it made sense. And No - I didn't have any plans on converting the existing test cases. Again, if the Rule looks like it would make sense for those tests, I'd be happy to try and convert some of them. But these Rules were primarily targeted and end-users (like me) who want to easily test their applications (like my Camel routes). > Add JUnit Rules > --- > > Key: ARTEMIS-737 > URL: https://issues.apache.org/jira/browse/ARTEMIS-737 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a > nice feature to have for Artemis as well, along with the JUnit rules for JMS > Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-737) Add JUnit Rules
[ https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511580#comment-15511580 ] Quinn Stevenson edited comment on ARTEMIS-737 at 9/22/16 12:02 AM: --- I'd be happy to put something in the user docs - but I don't know how you go about that :-). I've edited the wiki pages for ActiveMQ and Camel before, but I don't know the documentation process for Artemis. There are some simple examples in the unit tests. Granted, they don't do much, but they definitely show how to setup the rules to support a test. was (Author: hqstevenson): I'd be happy to put something in the user docs - but I don't know how you go about that :-). I've edited the wiki pages for ActiveMQ and Camel before, but I don't know the documentation process for Artemis. > Add JUnit Rules > --- > > Key: ARTEMIS-737 > URL: https://issues.apache.org/jira/browse/ARTEMIS-737 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a > nice feature to have for Artemis as well, along with the JUnit rules for JMS > Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-737) Add JUnit Rules
[ https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511580#comment-15511580 ] Quinn Stevenson commented on ARTEMIS-737: - I'd be happy to put something in the user docs - but I don't know how you go about that :-). I've edited the wiki pages for ActiveMQ and Camel before, but I don't know the documentation process for Artemis. > Add JUnit Rules > --- > > Key: ARTEMIS-737 > URL: https://issues.apache.org/jira/browse/ARTEMIS-737 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a > nice feature to have for Artemis as well, along with the JUnit rules for JMS > Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-737) Add JUnit Rules
[ https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503787#comment-15503787 ] Quinn Stevenson commented on ARTEMIS-737: - I've started working on porting the JUnit rules from ActiveMQ over. > Add JUnit Rules > --- > > Key: ARTEMIS-737 > URL: https://issues.apache.org/jira/browse/ARTEMIS-737 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Quinn Stevenson >Priority: Minor > > ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a > nice feature to have for Artemis as well, along with the JUnit rules for JMS > Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-737) Add JUnit Rules
Quinn Stevenson created ARTEMIS-737: --- Summary: Add JUnit Rules Key: ARTEMIS-737 URL: https://issues.apache.org/jira/browse/ARTEMIS-737 Project: ActiveMQ Artemis Issue Type: New Feature Components: Broker Reporter: Quinn Stevenson Priority: Minor ActiveMQ includes a JUnit rule for embedding a JMS Broker. This would be a nice feature to have for Artemis as well, along with the JUnit rules for JMS Clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6428) Add methods for sending messages to topics or queues
[ https://issues.apache.org/jira/browse/AMQ-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15484977#comment-15484977 ] Quinn Stevenson commented on AMQ-6428: -- I'm working on this one - you can assign it to me > Add methods for sending messages to topics or queues > > > Key: AMQ-6428 > URL: https://issues.apache.org/jira/browse/AMQ-6428 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Quinn Stevenson >Priority: Minor > > To simplify testing, the EmbeddedActiveMQBroker (in activemq-junit) should > have methods to send messages to topics and queues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6428) Add methods for sending messages to topics or queues
Quinn Stevenson created AMQ-6428: Summary: Add methods for sending messages to topics or queues Key: AMQ-6428 URL: https://issues.apache.org/jira/browse/AMQ-6428 Project: ActiveMQ Issue Type: Improvement Reporter: Quinn Stevenson Priority: Minor To simplify testing, the EmbeddedActiveMQBroker (in activemq-junit) should have methods to send messages to topics and queues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15271587#comment-15271587 ] Quinn Stevenson commented on AMQ-6274: -- Doh - Sorry. Thank you for your patience. I've squashed the two commits > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15271550#comment-15271550 ] Quinn Stevenson commented on AMQ-6274: -- Done > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15269839#comment-15269839 ] Quinn Stevenson commented on AMQ-6274: -- Done > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15269786#comment-15269786 ] Quinn Stevenson commented on AMQ-6274: -- OK - I updated the PR. Will this make it into 5.13.4? The customer I'm doing this for is using 5.13.2 right now and they need this - I'd rather not make them wait until 5.14 if at all possible. > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15268792#comment-15268792 ] Quinn Stevenson commented on AMQ-6274: -- I've updated the implementation and the MultipleCompositeToPhysicalQueueTest. I wanted to update the CompositeQueueTest and the CompositeTopicTest as well, but I'd need to modify the org.apache.activemq.spring.ConsumerBean class as well (add a getMessages so I can inspect the messages). Let me know if changing that class is OK, and I'll update those tests as well. > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15268741#comment-15268741 ] Quinn Stevenson commented on AMQ-6274: -- Thank you very much!! This will make my life even easier than I'd thought since the value will always be there (i.e. I don't have to put anything in the XML configuration to make it happen) - eliminating one more place where humans fail ;-) I'll update the PR with this fix - shouldn't be too bad since I'm getting rid of most of the changes I had to make (around making the header configurable). I'll also update the unit tests to check for the value. I missed the unit test the first time around because I'm not used to the unit tests being in another project - I won't make that mistake again ;-) > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267518#comment-15267518 ] Quinn Stevenson commented on AMQ-6274: -- The basic use case is wiretapping JMS Destinations to feed copies of the messages to another system for auditing purposes. The composite destinations work great for the wiretap - I can use a pattern to specify a group of destinations and where to forward copies. The problem is tracing the data in the audit system - I need a way to tell where the message originally came from. I worked around not having this feature in the past by putting my own JMS User Property on every message when I published it, but that proved to be error prone (i.e. it wouldn't get done once in a while for new destinations). Adding this type of functionality to the broker will eliminate those user-errors. Does that makes sense? > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267476#comment-15267476 ] Quinn Stevenson commented on AMQ-6274: -- Sorry - the pasted method didn't format very well. Basically I added a test to ensure that message.getOriginalDestination isn't null - but it always is. > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[
https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267361#comment-15267361
]
Quinn Stevenson commented on AMQ-6274:
--
OK - still working locally while I figure out what is going on here.
I modified the MultipleCompositeToPhysicalQueueTest locally to check the
message for the originalMessage value - it always seems to be null.
If this is supposed to be there, then I guess this is a bug - not an
enhancement - is that correct?
Here's the modified method in the test
@Test(timeout = 6)
public void testManyToOne() throws Exception {
Session consumerSession = buildSession("Consumer", url);
MessageConsumer consumer = createSubscriber(consumerSession, SUB1,
null);
// Producer
Session publisherSession = buildSession("Producer", url);
createPublisher(publisherSession,
PUB_BROADCAST.getVirtualDestination()).send(publisherSession.createTextMessage("BROADCAST"));
ActiveMQMessage receivedMessage = (ActiveMQMessage) consumer.receive();
ActiveMQDestination originalDestination =
receivedMessage.getOriginalDestination();
assertNotNull( "originalDestination should not be null",
originalDestination);
assertEquals("BROADCAST", ((TextMessage) receivedMessage).getText());
createPublisher(publisherSession,
PUB_INDIVIDUAL.getVirtualDestination()).send(publisherSession.createTextMessage("INDIVIDUAL"));
assertEquals("INDIVIDUAL", ((TextMessage)
consumer.receive()).getText());
}
> Add option to composite destinations to set originalMessage header
> --
>
> Key: AMQ-6274
> URL: https://issues.apache.org/jira/browse/AMQ-6274
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Quinn Stevenson
>Priority: Minor
>
> Composite Destinations are a great way to wiretap messages, but the resulting
> messages don't have any information in them about where they originally came
> from.
> I'm proposing to add an option to composite destinations ( addHeaders ) that
> will enable the addition of the originalDestination header to the messages.
> The option will be disabled by default to preserve existing behavior by
> default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267340#comment-15267340 ] Quinn Stevenson commented on AMQ-6274: -- That's actually where I started. From looking at the code, I thought that the ActiveMQMessage.originalMessage property would be set by the CompositeDestinationBroker as well. However, I set a breakpoint in the CompositeDestinationBroker class (the send method), and then I ran the MultipleCompositeToPhysicalQueueTest and the destination.isComposite() check fails, so the property is never set. Then I found the CompositeDestinationFilter - it is called, and it seemed like a good place to add the information. I re-used the orginialDestination JMS Property Name that the Advisory Messages use - maybe I should've done something else. If I can get the property from the ActiveMQMessage itself, that would be great. But as near as I can tell, it's never set. > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6274) Add option to composite destinations to set originalMessage header
[ https://issues.apache.org/jira/browse/AMQ-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264401#comment-15264401 ] Quinn Stevenson commented on AMQ-6274: -- You can assign this to me - I've just about got a PR ready for it. > Add option to composite destinations to set originalMessage header > -- > > Key: AMQ-6274 > URL: https://issues.apache.org/jira/browse/AMQ-6274 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.13.2 >Reporter: Quinn Stevenson >Priority: Minor > > Composite Destinations are a great way to wiretap messages, but the resulting > messages don't have any information in them about where they originally came > from. > I'm proposing to add an option to composite destinations ( addHeaders ) that > will enable the addition of the originalDestination header to the messages. > The option will be disabled by default to preserve existing behavior by > default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6274) Add option to composite destinations to set originalMessage header
Quinn Stevenson created AMQ-6274: Summary: Add option to composite destinations to set originalMessage header Key: AMQ-6274 URL: https://issues.apache.org/jira/browse/AMQ-6274 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.13.2 Reporter: Quinn Stevenson Priority: Minor Composite Destinations are a great way to wiretap messages, but the resulting messages don't have any information in them about where they originally came from. I'm proposing to add an option to composite destinations ( addHeaders ) that will enable the addition of the originalDestination header to the messages. The option will be disabled by default to preserve existing behavior by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6106) JUnit Rule for embedded ActiveMQ Broker
[ https://issues.apache.org/jira/browse/AMQ-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102374#comment-15102374 ] Quinn Stevenson commented on AMQ-6106: -- Would it be possible to get this incorporated into the upcoming 5.11.x/5.12.x/5.13.x releases? I know it works with these because I started using it with 5.11.x. There was the issue with AdvisoryMessages not working when a memory store was used, but that's been resolved and that was the only issues I've seen with this. The reason I ask is I've used this quite a bit in my Camel tests and I've had to copy it into several source structures - I'd really like to start using this version instead. > JUnit Rule for embedded ActiveMQ Broker > --- > > Key: AMQ-6106 > URL: https://issues.apache.org/jira/browse/AMQ-6106 > Project: ActiveMQ > Issue Type: New Feature >Affects Versions: 5.13.0 >Reporter: Quinn Stevenson >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 5.14.0 > > > Add a JUnit Rule to simplify using embedded ActiveMQ brokers in JUnit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6106) JUnit Rule for embedded ActiveMQ Broker
[ https://issues.apache.org/jira/browse/AMQ-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15083514#comment-15083514 ] Quinn Stevenson commented on AMQ-6106: -- I've updated the pull request. I added a "configure" method that can be overridden, as well as a constructor that allows the BrokerService to be created via an XBean URI. > JUnit Rule for embedded ActiveMQ Broker > --- > > Key: AMQ-6106 > URL: https://issues.apache.org/jira/browse/AMQ-6106 > Project: ActiveMQ > Issue Type: New Feature >Affects Versions: 5.13.0 >Reporter: Quinn Stevenson >Priority: Minor > > Add a JUnit Rule to simplify using embedded ActiveMQ brokers in JUnit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6106) JUnit Rule for embedded ActiveMQ Broker
Quinn Stevenson created AMQ-6106: Summary: JUnit Rule for embedded ActiveMQ Broker Key: AMQ-6106 URL: https://issues.apache.org/jira/browse/AMQ-6106 Project: ActiveMQ Issue Type: New Feature Affects Versions: 5.13.0 Reporter: Quinn Stevenson Priority: Minor Add a JUnit Rule to simplify using embedded ActiveMQ brokers in JUnit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
