On 03/30/2016 07:12 AM, Robbie Gemmell wrote:
On 30 March 2016 at 11:40, Oleksandr Rudyy <oru...@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
amqp://localhost:5672?jms.populateJMSXUserID=true
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
