Clebert, That PR URL gives me a 404.
Harrison -----Original Message----- From: Clebert Suconic [mailto:clebert.suco...@gmail.com] Sent: Wednesday, October 11, 2017 9:00 AM To: users@activemq.apache.org Subject: Re: How to put "properties" on a message so they are accessible later What Harryson said matches my PR.. you you would need to call the method reencode. .otherwise you won't receive the messages.. and it wouldn't be persisted. On Wed, Oct 11, 2017 at 11:58 AM, Clebert Suconic <clebert.suco...@gmail.com> wrote: > Please look at the pull request.. I believe it would fix help you: > > https://github.com/apache/activemq-artemis/pull/1584 > > On Wed, Oct 11, 2017 at 11:58 AM, Clebert Suconic > <clebert.suco...@gmail.com> wrote: >> You would be able to call reencode on the message. >> >> there was an issue that if you didn't have a property, the >> applicationProperties wouldn't be set.. >> >> >> I added an example, and fixed that issue here: >> >> https://github.com/apache/activemq-artemis/pull/1584 >> >> >> Notice you would need to do the else part in case of a core protocol >> message.. (I didn't do that part here). >> >> On Wed, Oct 11, 2017 at 4:46 AM, Matthias Hanisch >> <matthias.hani...@camline.com> wrote: >>> Hi, >>> >>> let me explain a similar use case what we would use to show that >>> there is a demand for modification of application properties: >>> >>> We would like to enrich an AMQP message with additional application >>> properties for better filtering and message routing. >>> >>> As far as I understood from the discussion below this is not >>> possible by calling message.putStringProperty("new_prop", >>> "new_prop_value") >>> >>> I tried to do this in an AmqpInterceptor but the listener still gets >>> the original message without this added property. And therefore the >>> listener can also not create a message selector based on the new >>> application properties. >>> >>> I also checked the spec and I could not find a reference that >>> application properties are immutable. For "pure" properties this >>> seems to be true according to section 3.2.4 of the spec. >>> >>> The only way I can think of is to use a listener which creates a new >>> message with the enriched context and uploads it back to the broker. >>> This would duplicate a lot of messages and would impact performance. >>> >>> A more efficient way to realize this feature would be greatly appreciated. >>> >>> Best regards, >>> Matthias >>> >>> P.S.: I just subscribed to this mailing list so I was not able to >>> reply directly to the mail below. Sorry about that. >>> >>> >>> ---------- Weitergeleitete Nachricht ---------- >>>> From: Clebert Suconic <clebert.suco...@gmail.com> >>>> To: users@activemq.apache.org >>>> Cc: >>>> Bcc: >>>> Date: Tue, 10 Oct 2017 20:18:38 -0400 >>>> Subject: Re: How to put "properties" on a message so they are >>>> accessible later We could add a new method call to the plugin... >>>> something like replaceMessage. >>>> >>>> With that on hand you could then convert the AMQPMessage to a Core >>>> Message using message.toCore().. and return the transformed message. >>>> >>>> >>>> The message wouldn't be an AMQP message any longer from that point >>>> on.. it would eventually be converted back to whatever other >>>> message protocols it leads on the other side... it would of course >>>> have some performance impact but it would work. >>>> >>>> On Tue, Oct 10, 2017 at 5:55 PM, Timothy Bish <tabish...@gmail.com> wrote: >>>> > On 10/10/2017 05:20 PM, Harrison Tarr wrote: >>>> >> >>>> >> Thanks for the quick reply. Is there any way to change something >>>> >> on the message that my consumer could then access? Maybe not >>>> ApplicationProperties >>>> >> but something else? >>>> > >>>> > >>>> > Nothing that would be accessible via the JMS client API. >>>> > >>>> > >>>> >> Harrison >>>> >> >>>> >> -----Original Message----- >>>> >> From: Timothy Bish [mailto:tabish...@gmail.com] >>>> >> Sent: Tuesday, October 10, 2017 2:11 PM >>>> >> To: users@activemq.apache.org >>>> >> Subject: Re: How to put "properties" on a message so they are >>>> >> accessible later >>>> >> >>>> >> On 10/10/2017 05:06 PM, Harrison Tarr wrote: >>>> >>> >>>> >>> Hello again, >>>> >>> >>>> >>> I wanted to follow up on this as I've done some more experimenting. >>>> >>> I've found that when I use the Core protocol or Openwire >>>> >>> protocol, everything works as expected. I am able to use the >>>> >>> "setStringProperty" >>>> >>> in my ActiveMQServerPlugin and it adds a header that I can then >>>> >>> access in my Camel consumer code. However, if I try to add a >>>> >>> property to a message that was sent using the AMQP protocol, it >>>> >>> does not stay set on the message. It appears to me that this is >>>> >>> because the AMQP message is more protected? Maybe it has all of >>>> >>> the data in an immutable ByteBuffer? I've tried using the >>>> >>> "reencode" method on the >>>> >>> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage >>>> >>> class, but it causes an error; it can't parse the message back >>>> >>> out, it says something about an unknown constructor. (Being >>>> >>> handled here >>>> >>> https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/ >>>> >>> src/mai >>>> >>> n/java/org/apache/qpid/jms/provider/amqp/AmqpConsumer.java#L496 >>>> >>> ) >>>> >> >>>> >> AMQP ApplicationProperties are immutable so you cannot change or >>>> >> add to them in flight, that would violate the AMQP specification. >>>> >> >>>> >>> Justin, I've looked at the remoting interceptors. I think I >>>> >>> decided against using them because it does not expose as much >>>> >>> information to >>>> me as I >>>> >>> wanted. I'm specifically trying to take the authentication >>>> >>> credentials >>>> and >>>> >>> then create some kind of authentication token to attach to the >>>> >>> message >>>> that >>>> >>> I can then use in my consuming code. >>>> >>> >>>> >>> Regards, >>>> >>> Harrison Tarr >>>> >>> >>>> >>> >>>> >>> -----Original Message----- >>>> >>> From: Justin Bertram [mailto:jbert...@redhat.com] >>>> >>> Sent: Tuesday, September 12, 2017 3:28 PM >>>> >>> To: users@activemq.apache.org >>>> >>> Subject: Re: How to put "properties" on a message so they are >>>> >>> accessible later >>>> >>> >>>> >>> I'm not terribly familiar with the ActiveMQServerPlugin >>>> >>> functionality >>>> in >>>> >>> this regard, but I do know that you can make such modifications >>>> >>> to >>>> messages >>>> >>> using remoting interceptors. Have you explored that possibility? >>>> >>> >>>> >>> >>>> >>> Justin >>>> >>> >>>> >>> On Tue, Sep 12, 2017 at 3:45 PM, Harrison Tarr >>>> >>> <harrison.t...@connexta.com> >>>> >>> wrote: >>>> >>> >>>> >>>> Right now I'm using Artemis 2.2.0. >>>> >>>> I've done a bit more research and experimentation. It seems >>>> >>>> that I can set a header in Camel, send the message to a >>>> >>>> queue/topic hosted on Artemis and read the header as a >>>> >>>> "stringProperty". The header keys also show up when I do a >>>> >>>> "getProperties" call. However, if I try to overwrite that >>>> >>>> field in my ActiveMQServerPlugin (specifically the beforeSend >>>> >>>> call), the change is not propagated to Camel. IE, if I >>>> send a >>>> >>>> message with the header "testHeader" >>>> >>>> with a value of "testValue", I can see, in Artemis, >>>> >>>> "testHeader" as a property on the message with the value of >>>> >>>> "testValue". If I then try to overwrite that value with >>>> >>>> "newValue", when I access the message and its headers in the >>>> >>>> consumer, the header is still "testHeader" >>>> >>>> with the value of "testValue", whereas I expect it to be "testHeader" >>>> >>>> with a value of "newValue". >>>> >>>> >>>> >>>> Harrison Tarr >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: tbai...@gmail.com [mailto:tbai...@gmail.com] On Behalf >>>> >>>> Of Tim Bain >>>> >>>> Sent: Monday, September 11, 2017 6:26 PM >>>> >>>> To: ActiveMQ Users <users@activemq.apache.org> >>>> >>>> Subject: RE: How to put "properties" on a message so they are >>>> >>>> accessible later >>>> >>>> >>>> >>>> To be clear, you're asking about doing this in Artemis, not >>>> >>>> ActiveMQ 5.x, right? What version of Artemis? >>>> >>>> >>>> >>>> On Sep 11, 2017 2:48 PM, "Harrison Tarr" >>>> >>>> <harrison.t...@connexta.com> >>>> >>>> wrote: >>>> >>>> >>>> >>>>> I just wanted to follow up: Does anyone know how to put an >>>> >>>>> attribute/property on a message in an ActiveMQServerPlugin >>>> >>>>> that I can then pull out of the message in Camel? >>>> >>>>> >>>> >>>>> Regards, >>>> >>>>> Harrison Tarr >>>> >>>>> >>>> >>>>> -----Original Message----- >>>> >>>>> From: Harrison Tarr [mailto:harrison.t...@connexta.com] >>>> >>>>> Sent: Wednesday, September 6, 2017 8:56 AM >>>> >>>>> To: users@activemq.apache.org >>>> >>>>> Subject: How to put "properties" on a message so they are >>>> >>>>> accessible later >>>> >>>>> >>>> >>>>> Hi, >>>> >>>>> >>>> >>>>> I'm trying to put a StringProperty on a Message in an >>>> >>>>> ActiveMQServerPlugin. As far as I can tell, the property gets >>>> >>>>> set correctly. Later, I'm trying to retrieve the property >>>> >>>>> from a Camel Exchange. I don't see my property anywhere on >>>> >>>>> the Exchange. I did notice that it looks like the properties >>>> >>>>> "firedTime" and "breadcrumbId," which I think come from >>>> >>>>> Artemis, do appear on the Camel Exchange, which makes me >>>> >>>>> think there is some way to propagate my >>>> >>>> >>>> >>>> property from Artemis to Camel. >>>> >>>>> >>>> >>>>> Regards, >>>> >>>>> Harrison Tarr >>>> >>>>> >>>> >> -- >>>> >> Tim Bish >>>> >> twitter: @tabish121 >>>> >> blog: http://timbish.blogspot.com/ >>>> >> >>>> > >>>> > -- >>>> > Tim Bish >>>> > twitter: @tabish121 >>>> > blog: http://timbish.blogspot.com/ >>>> > >>>> >>>> >>>> >>>> -- >>>> Clebert Suconic >>>> >>>> >>>> >>> >>> -- >>> camLine GmbH >>> 85238 Petershausen, Industriering 4a, Deutschland Amtsgericht >>> München HRB 88821 >>> Geschäftsführer: Heinz Linsmaier (CEO), Bernhard Jofer, Georg Ruetz >>> <http://www.camline.com/en/camline/events.html> >>> <http://www.camline.com/en/camline/events.html> >>> <http://www.camline.com/en/camline/events.html> >> >> >> >> -- >> Clebert Suconic > > > > -- > Clebert Suconic -- Clebert Suconic
