Re: org.apache.activemq.SERIALIZABLE_PACKAGES property affecting Map Messages

[khandelwalanuj]

> Try org.apache.activemq, since that's where MapMessage lives. 
Nope. doesn't work with "org.apache.activemq" or "org.apache". 

It only works with "org"





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Kahadb index updates taking too much time on ActiveMQ 5.11

[Devlin]

Samples for cpu self-time, total-time, and memory usage:

 

 

 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Should master/slave brokers share tmp_storage directory?

[Devlin]

It's my understanding with kahadb the store folder location is shared between
master and slave brokers using the following config:

   

   


Why is it that temp storage does not use the same, shared location? By
default, the location for tmp_storage appears to be local to the broker
itself:

2017-10-11 11:57:30,424 [AMQ-1-thread-1 ] INFO  PListStoreImpl
- PListStore:
[/opt/activemq/data/amqdata/seattlebroker-a1/tmp_storage] started
2017-10-11 11:57:30,603 [AMQ-1-thread-1 ] DEBUG KahaDBStore   
- Store OpenWire version configured as: 6

For master/slave broker groups, should the temp storage location be shared
with explicit config like this?

 



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: artemis hierachic topic and clustering

[Justin Bertram]

This looks like a bug to me.  Do you have a test-case that I could use to
reproduce the issue?  If not, could you create one (potentially based on
the "clustered-static-discovery" example shipped with the broker)?


Justin

On Mon, Sep 25, 2017 at 5:25 AM, Helge Waastad  wrote:

> Hi,
> I have a java artemis (2.3.0) consumer listening to a "my-topic.#"
>
> if I listen and produce on the same artemis instance, It's working
> fine.
>
> However, moving the consumer to another instance in a static configured
> cluster, the artmis receiving the messages:
>
> 12:01:18,873
> WARN  [org.apache.activemq.artemis.core.protocol.mqtt.MQTTPublishManage
> r] null: java.lang.StackOverflowError
> at
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> [rt.jar:1.8.0_131]
> at
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.getNextBi
> nding(BindingsImpl.java:321) [artemis-server-2.3.0.jar:2.3.0]
>
>
> Can this be a configuration issue?
>
> relevant config:
> b1:
> 
>  
> netty-connector
> 500
> true
> ON_DEMAND
> 1
>  
>   
>
> 
>
>  
>
>  
>
> b2:
> 
>  tcp://localhost:61617
>  tcp://localhost:61616
>
>   
>  
> netty-connector
> 500
> true
> ON_DEMAND
> 1
> 
>b1-connector
> 
>  
>   
>
> consumer on queue "my-topic.#"
> client: mosquitto_pub -m hei -t my-topic.xxx -p 1883
>

Re: User: null does not have permission='CREATE_DURABLE_QUEUE' on address $sys.mqtt.queue.qos2.JavaSample

[Justin Bertram]

Adding security-settings was the work-around provided on the JIRA.


Justin

On Wed, Oct 11, 2017 at 1:44 PM, Clebert Suconic 
wrote:

> What about adding the Security Settings for that address?
>
> On Wed, Oct 11, 2017 at 2:08 PM, Justin Bertram 
> wrote:
> > Could you provide the full stack-trace?
> >
> > Also, it's worth noting that a work-around for the issue was posted on
> the
> > aforementioned JIRA a day after it was opened back in February.
> >
> >
> > Justin
> >
> > On Mon, Oct 9, 2017 at 2:19 AM, martin_activeMQ <
> martin.ahch...@bosch-si.com
> >> wrote:
> >
> >> Hi Justin,
> >>
> >> I'm using the latest available version 1.5.5 and it seems that the
> problem
> >> is reproducible. Any suggestion to workaround this limitation?
> >>
> >> address=activemq.notifications,properties=TypedProperties[_AMQ_User=
> >> X,_AMQ_Address=$sys.mqtt.queue.qos2..$sys.mqtt.
> >> queue.qos2.,_AMQ_NotifType=SECURITY_PERMISSION_
> >> VIOLATION,_AMQ_NotifTimestamp=1507531272068,_AMQ_CheckType=
> >> CONSUME]]@1606453679
> >> is not going anywhere as it didn't have a binding on
> >> address:activemq.notifications
> >> 09:41:12,071 DEBUG [org.apache.activemq.artemis.core.protocol.mqtt]
> Error
> >> processing Control Packet, Disconnecting Client:
> >> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION
> message=AMQ119032:
> >> User:  does not have permission='CONSUME' on address
> >> $sys.mqtt.queue.qos2..$sys.mqtt.queue.qos2.]
> >> at
> >> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(
> >> SecurityStoreImpl.java:201)
> >> [artemis-server-1.5.5.jar:1.5.5]
> >> at
> >> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.
> >> securityCheck(ServerSessionImpl.java:401)
> >> [artemis-server-1.5.5.jar:1.5.5]
> >>
> >> Best regards,
> >> Martin
> >>
> >>
> >>
> >> --
> >> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> >> f2341805.html
> >>
>
>
>
> --
> Clebert Suconic
>

Re: User: null does not have permission='CREATE_DURABLE_QUEUE' on address $sys.mqtt.queue.qos2.JavaSample

[Clebert Suconic]

What about adding the Security Settings for that address?

On Wed, Oct 11, 2017 at 2:08 PM, Justin Bertram  wrote:
> Could you provide the full stack-trace?
>
> Also, it's worth noting that a work-around for the issue was posted on the
> aforementioned JIRA a day after it was opened back in February.
>
>
> Justin
>
> On Mon, Oct 9, 2017 at 2:19 AM, martin_activeMQ > wrote:
>
>> Hi Justin,
>>
>> I'm using the latest available version 1.5.5 and it seems that the problem
>> is reproducible. Any suggestion to workaround this limitation?
>>
>> address=activemq.notifications,properties=TypedProperties[_AMQ_User=
>> X,_AMQ_Address=$sys.mqtt.queue.qos2..$sys.mqtt.
>> queue.qos2.,_AMQ_NotifType=SECURITY_PERMISSION_
>> VIOLATION,_AMQ_NotifTimestamp=1507531272068,_AMQ_CheckType=
>> CONSUME]]@1606453679
>> is not going anywhere as it didn't have a binding on
>> address:activemq.notifications
>> 09:41:12,071 DEBUG [org.apache.activemq.artemis.core.protocol.mqtt] Error
>> processing Control Packet, Disconnecting Client:
>> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119032:
>> User:  does not have permission='CONSUME' on address
>> $sys.mqtt.queue.qos2..$sys.mqtt.queue.qos2.]
>> at
>> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(
>> SecurityStoreImpl.java:201)
>> [artemis-server-1.5.5.jar:1.5.5]
>> at
>> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.
>> securityCheck(ServerSessionImpl.java:401)
>> [artemis-server-1.5.5.jar:1.5.5]
>>
>> Best regards,
>> Martin
>>
>>
>>
>> --
>> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
>> f2341805.html
>>



-- 
Clebert Suconic

Re: User: null does not have permission='CREATE_DURABLE_QUEUE' on address $sys.mqtt.queue.qos2.JavaSample

[Justin Bertram]

Could you provide the full stack-trace?

Also, it's worth noting that a work-around for the issue was posted on the
aforementioned JIRA a day after it was opened back in February.


Justin

On Mon, Oct 9, 2017 at 2:19 AM, martin_activeMQ  wrote:

> Hi Justin,
>
> I'm using the latest available version 1.5.5 and it seems that the problem
> is reproducible. Any suggestion to workaround this limitation?
>
> address=activemq.notifications,properties=TypedProperties[_AMQ_User=
> X,_AMQ_Address=$sys.mqtt.queue.qos2..$sys.mqtt.
> queue.qos2.,_AMQ_NotifType=SECURITY_PERMISSION_
> VIOLATION,_AMQ_NotifTimestamp=1507531272068,_AMQ_CheckType=
> CONSUME]]@1606453679
> is not going anywhere as it didn't have a binding on
> address:activemq.notifications
> 09:41:12,071 DEBUG [org.apache.activemq.artemis.core.protocol.mqtt] Error
> processing Control Packet, Disconnecting Client:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119032:
> User:  does not have permission='CONSUME' on address
> $sys.mqtt.queue.qos2..$sys.mqtt.queue.qos2.]
> at
> org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.check(
> SecurityStoreImpl.java:201)
> [artemis-server-1.5.5.jar:1.5.5]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.
> securityCheck(ServerSessionImpl.java:401)
> [artemis-server-1.5.5.jar:1.5.5]
>
> Best regards,
> Martin
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

Re: How to put "properties" on a message so they are accessible later

[Justin Bertram]

That's weird.  I tried the link from your previous email too and it gave me
a 404 as well.  However, it's working now.  It must have been a GitHub
hiccup or something.


Justin

On Wed, Oct 11, 2017 at 11:14 AM, Clebert Suconic  wrote:

> Just opened and it works for me
>
> https://github.com/apache/activemq-artemis/pull/1584
>
>
> On Wed, Oct 11, 2017 at 12:02 PM Harrison Tarr  >
> wrote:
>
> > 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
> > >  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
> > >>  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 
> >  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 
> > 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 

Re: How to put "properties" on a message so they are accessible later

[Clebert Suconic]

Just opened and it works for me

https://github.com/apache/activemq-artemis/pull/1584


On Wed, Oct 11, 2017 at 12:02 PM Harrison Tarr 
wrote:

> 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
> >  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
> >>  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 
>  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 
> 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 

RE: How to put "properties" on a message so they are accessible later

[Harrison Tarr]

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  
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 
>  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 
>>  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 
 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  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 
 >>> 

Re: How to put "properties" on a message so they are accessible later

[Clebert Suconic]

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
 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
>  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
>>  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 
 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  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
 >>> 

Re: How to put "properties" on a message so they are accessible later

[Clebert Suconic]

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
 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
>  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 
>>> 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  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 

RE: How to put "properties" on a message so they are accessible later

[Harrison Tarr]

Hi Matthias, 

I ended up coming up with a "solution". It does prevent me from consuming using 
AMQP. What I do is send the message to the broker using AMQP but then I 
retrieve the message using the Core protocol.  I'll include my snippet of code 
that does the modification to the AMQP message. 

I believe there's a bug in the "reencode" method of the AMQPMessage class. I 
noticed that if I call the reencode method but then manually set the "sendFrom" 
field to 0 ( a private field), the message is successfully reencoded and sent 
and retrieved by an AMQP consumer. Alternatively, if I disconnect the consumer, 
remove the reencode call from the server plugin, and then reattach the 
consumer, the messages that had been failing (and were persisted to disk after 
the consumer disconnected) are successfully delivered to the consumer after 
it's reattached. I think this is because the method "reloadPersistence" is 
called and resets the data, sendFrom, and bufferValid fields. Maybe one of the 
designers of this piece of code can chime in? 

Anyway, here's my implementation of the ActiveMQServerPlugin:

public class MyTestServerPlugin implements ActiveMQServerPlugin {

@Override
public void beforeSend(ServerSession session, Transaction tx, Message 
message, boolean direct,
boolean noAutoCreateQueue) {
System.out.println(String.format("Username: %s, Password: %s",
session.getUsername(),
session.getPassword()));

message.putStringProperty("testHeaderOne", session.getUsername());

if (message instanceof AMQPMessage) {
Map applicationPropertiesMap = ((AMQPMessage) 
message).getProtonMessage()
.getApplicationProperties()
.getValue();
applicationPropertiesMap.put("testHeaderOne", 
session.getUsername());
((AMQPMessage) message).getProtonMessage()
.setApplicationProperties(new 
ApplicationProperties(applicationPropertiesMap));
}
}
}

Harrison Tarr


-Original Message-
From: Matthias Hanisch [mailto:matthias.hani...@camline.com] 
Sent: Wednesday, October 11, 2017 1:46 AM
To: users@activemq.apache.org
Subject: Re: How to put "properties" on a message so they are accessible later

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 
> 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  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, 

Re: How to put "properties" on a message so they are accessible later

[Clebert Suconic]

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
 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 
>> 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  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 

Re: new to ActiveMq - is JDBC only the backend storage option ?

[Justin Bertram]

It's not clear to me if you're asking about the ActiveMQ 5.x broker or the
ActiveMQ Artemis broker.  Christian answered your question in the context
of 5.x.  For Artemis the default storage is a set of journal files that
would work fine on a SAN.


Justin

On Wed, Oct 11, 2017 at 10:33 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> The default storage backend is kahadb. Kahadb works with simple files. So
> it is suitable for a SAN. Make sure though that the SAN provides a good
> shared file lock. This is required for master  / slave mode.
>
> JDBC is typically a lot slower than kahadb. So I would rather not use jdbc.
>
> Christian
>
> 2017-10-11 16:45 GMT+02:00 uraees :
>
> > New to ActiveMq and trying to learn - is JDBC only the back-end storage
> > option ? our firm mostly encourages to use a SAN file based back-end
> > storage
> > if possible; is that option available for this product ?  and is there
> any
> > performance implications vs JDBC storage!.
> >
> > Also does the product need to be deployed in an app server ? or does it
> has
> > a stand alone run-time  ?
> >
> > thanks
> > Raees
> >
> >
> >
> >
> > --
> > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> > f2341805.html
> >
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>  46=http%3a%2f%2fwww.liquid-reality.de>
>
> Computer Scientist
> http://www.adobe.com
>

Re: new to ActiveMq - is JDBC only the backend storage option ?

[Christian Schneider]

The default storage backend is kahadb. Kahadb works with simple files. So
it is suitable for a SAN. Make sure though that the SAN provides a good
shared file lock. This is required for master  / slave mode.

JDBC is typically a lot slower than kahadb. So I would rather not use jdbc.

Christian

2017-10-11 16:45 GMT+02:00 uraees :

> New to ActiveMq and trying to learn - is JDBC only the back-end storage
> option ? our firm mostly encourages to use a SAN file based back-end
> storage
> if possible; is that option available for this product ?  and is there any
> performance implications vs JDBC storage!.
>
> Also does the product need to be deployed in an app server ? or does it has
> a stand alone run-time  ?
>
> thanks
> Raees
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Computer Scientist
http://www.adobe.com

new to ActiveMq - is JDBC only the backend storage option ?

[uraees]

New to ActiveMq and trying to learn - is JDBC only the back-end storage
option ? our firm mostly encourages to use a SAN file based back-end storage
if possible; is that option available for this product ?  and is there any
performance implications vs JDBC storage!. 

Also does the product need to be deployed in an app server ? or does it has
a stand alone run-time  ?

thanks 
Raees




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: org.apache.activemq.SERIALIZABLE_PACKAGES property affecting Map Messages

[Tim Bain]

Try org.apache.activemq, since that's where MapMessage lives.

On Oct 11, 2017 12:47 AM, "khandelwalanuj" 
wrote:

> Ok. I am able to make it work by adding "org" in the serializable package
> property.
>
> Details:
>
> -Dorg.apache.activemq.SERIALIZABLE_PACKAGES=java,*
> org*,com.test,test,local"
>
> Can anyone explain what exact package I need to add to make it work as
> "org"
> is huge ? Also shouldn't these packages be taken care by ActiveMQ itself
> rather thn specifying as a property ?
>
>
> Thanks,
> Anuj
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

BrokerFilter how to respond to client with Error Message

[davidh]

hi

I have implemented a BrokerFilter which Authenticates a connection on
"addConnection" and Authorises on "addConsumer".

This works but my question is about error handling - "addConnection" returns
a void and throws Exception.  If I raise an exception (with a message) the
exception not only gets written to the log but also returns full stacktrace
to the client.  

Is there any way to only return the message? - returning the stacktrace
doesn't feel right for a security plugin.  At the moment I am catching
Exceptions within the function, logging them then setting
"context.setDontSendResponse(true);" so the client doesn't get any detail on
the error.

I would like my client to be able to handle the errors differently - e.g.
"Token Expired" would be different from ActiveMQ not being available to the
client.  



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: How to put "properties" on a message so they are accessible later

[Matthias Hanisch]

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 
> 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  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
> >>> 
> >>> wrote:
> >>>
>  Right now I'm 

Re: org.apache.activemq.SERIALIZABLE_PACKAGES property affecting Map Messages

[khandelwalanuj]

Ok. I am able to make it work by adding "org" in the serializable package
property. 

Details:

-Dorg.apache.activemq.SERIALIZABLE_PACKAGES=java,*org*,com.test,test,local"

Can anyone explain what exact package I need to add to make it work as "org"
is huge ? Also shouldn't these packages be taken care by ActiveMQ itself
rather thn specifying as a property ?


Thanks,
Anuj



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

org.apache.activemq.SERIALIZABLE_PACKAGES property affecting Map Messages

[khandelwalanuj]

Hi,

I am using ActiveMQv5.14.5 and observing below mentioned behavior with
ActiveMQ. 

We have a use case where python producer using stomp send json data({'P1':
False, 'end_date': '20170911'}) to Java Consmer where Java Consumer expect
to receive it as jms MapMessage.

When I run ActiveMQ broker with
"org.apache.activemq.SERIALIZABLE_PACKAGES=*", the workflow works fine and
consumer is able to receive message.

However we I specify some specific package which are used 
"org.apache.activemq.SERIALIZABLE_PACKAGES=java,com.test,test,local" I
receive the same message as JMS TextMessage. And received text message
contents are : 

producer side message: {'P1': False, 'end_date': '20170911'}
Consumer side received text message:

P1False
end_date20170911


I have no idea why this property which is supposed to be used for
ObejctMessages is affecting this workflow. This sounds like a bug. Any help
would be appreciated. 

Thanks,
Anuj





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html