qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tabish...@gmail.com>
Subject Re: Questions about disabling sending of UserID with messages QPID-7159/QPIDJMS-163
Date Thu, 31 Mar 2016 16:42:44 GMT
On 03/30/2016 07:12 AM, Robbie Gemmell wrote:
> On 30 March 2016 at 11:40, Oleksandr Rudyy <orudyy@gmail.com> wrote:
>> Hi Robbie,
>> I would like to clarify the name of a connection parameter to disable
>> sending of UserID for both new and legacy JMS clients.
>> New JIRA QPIDJMS-163 requires to implement toggle to enable/disable it
>> but does not specify how toggle is implemented.
> It would be a connection URI option, the new client does essentially
> all its configuration that way at present:
> http://qpid.apache.org/releases/qpid-jms-0.8.0/docs/index.html#connection-uri
>> In suggested changes for legacy JMS client implemented as part of
>> QPID-7159 connection parameter 'attachUserId' is used to disable
>> sending of UserID.
>> I am wondering whether the same name could be used in both old and new clients?
> The name could be the same, but as per the above link the new client
> prefixes properties into groups so unless the old client included the
> same the two would still differ slightly.

I've implemented this feature in the Qpid JMS client code but I've gone 
with a different name which I hope is a bit more clear on what is 
happening when it is enabled.  The configuration for the client would be 
done on the URI using the following type of URI


>> Another interesting question is whether enumeration returned by
>> ConnectionMetaData#getJMSXPropertyNames() should include JMSXUserID
>> when its sending is disabled?
>> It seems that connection will not support JMSXUserID in sent messages
>> but will support it in received messages.
>> JMS spec is very unclear about it.
> Yes it is. It does describe that the existence of such 'JMS-defined'
> properties for a particular message isnt a given, as providers may
> choose to include them on some messages and not others based on the
> ever-present 'administrative or other criteria' escape clause the spec
> loves to use. As such I don't think having the name in the metadata
> while not setting the value on send is actually against the spec,
> though it certainly might not be what some people expect.
>> It looks like that JMSXUserID shall be included into
>> ConnectionMetaData#getJMSXPropertyNames() when sending of UserID is
>> disabled.
>> Any thoughts?
> I think I'd tend towards removing it from the metadata if not setting
> the value on send, but alternatively this all might even suggest a
> second config option to control whether the metadata is exposed or
> not, separate from whether outgoing messages actually have it
> populated or not.I'd probably try to avoid that for now though.
> Its probably worth me putting out there at this point that I actually
> think including the value on sent messages should be disabled by
> default. I tend to think of it as an optional opt-in, as the JMS spec
> itself seems to, and not always particularly desirable. Obviously the
> old client has been including it for some time, so I wouldnt change
> that to avoid breaking existing stuff, but when implementing this on
> the new client I'd tend toward changing the default behaviour (or
> rather, also leaving it as it has effectively been all along for the
> new client)

I've implemented this in an off by default manner as in most cases in 
the past I've seen more users request not to include this information 
than want it included.  I have not removed the advertisement of 
JMSXUserID from the metadata though as this value is used not only to 
indicate that the sender can apply it but also that the receive can ask 
for it and get a meaningful answer back if the remote happens to support 
populating it.  If it becomes an issue I'd suggest we would provide an 
additional configuration option to control what values are exposed in 
the metadata.

> Robbie
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message