After fixing this issue the documentation mentioned in description should be updated.

The following example demonstrates that it is impossible to monitor Java object attribute with double-backslash in the name, without additional escaping.

I have Java application with JMX support enabled with the following object and its attribute:
objectName:

com.example:type=Hello

attributeName:

double\\backslash

I add it to Zabbix using frontend, as the following JMX key:

jmx[com.example:type=Hello,double\\backslash]

After some time the item becomes unsupported with the following error message:

getAttribute failed: ModelMBeanAttributeInfo not found for double\backslash

Note the single backslash in the error message!

In the database it's exactly as I was adding it

MariaDB [trunk]> select name,key_ from items where key_ like 'jmx%Hello%double%';
+----------+---------------------------------------------------+
| name     | key_                                              |
+----------+---------------------------------------------------+
| jmx $2   | jmx[com.example:type=Hello,double\\backslash]   |
+----------+---------------------------------------------------+

If I double-quote the attributeName, it won't help. It only helps if I escape every backslash in it, resulting with 4 backlashes. See the following screenshot of combinations of unescaped/escaped quoted/unquoted examples:

Just a note, this is not about escaping dots, the dots in attributes have special meaning - separator. So if there are dots in the attribute name used not as a separator - they must be escaped manually. Besides, we do not escape dots in other items.

This was added in:
ZBX-4663

Right. I got your point. One solution could be to use every member of composite data as separate item parameter:

jmx[com.example:type=Hello,world]
jmx[com.example:type=Hello,cars,bmw]
jmx[com.example:type=Hello,the.fruits,apple]

The first parameter is MBean object name, second is attribute name, in case attribute contains composite data - all other parameters are it's members. I don't remember why we did not follow this idea, there was something making it complicated.

vso yes, I think it was already discussed here
Unfortunately it will not allow us to add more parameters to item key in the future.
Still JMX discovery seems like a more convenient way.

Right, thanks for finding this.

What if in case of attribute being composite data we force users to use quotes? E. g.

jmx[com.example:type=Hello,world]
jmx[com.example:type=Hello,"cars,bmw"]
jmx[com.example:type=Hello,"the.fruits,apple"]

Looks simple and clear. The upgrade patch doesn't look too complicated:

1. If second parameter has unescaped dot, ensure it's quoted.
2. Replace unescaped dot with comma.
3. Replace escaped dot sequence with a dot.
    

Of course, Java gateway need to be modified accordingly. And we should probably make this in new major version.

vso can you please provide example with following example where we want to access ".a" composite data and "f.r.u.i.t.s" is name
f.r.u.i.t.s (Fruits composite data):
a = apple
b = banana
c = cherry

before:

jmx[com.example:type=Hello,f\.r\.u\.i\.t\.s.a]

<dimir> After:

jmx[com.example:type=Hello,"f.r.u.i.t.s,a"]

vso what if it is now, haven't tested though

jmx[com.example:type=Hello,"f,r,u,i,t,s.a"]

Will it become

jmx[com.example:type=Hello,"f\,r\,u\,i\,t\,s,a"]

It is possible that we can solve issue by doing this (not tested):

Index: src/zabbix_java/src/com/zabbix/gateway/HelperFunctionChest.java
===================================================================
--- src/zabbix_java/src/com/zabbix/gateway/HelperFunctionChest.java	(revision 84748)
+++ src/zabbix_java/src/com/zabbix/gateway/HelperFunctionChest.java	(working copy)
@@ -56,8 +56,7 @@
 
 		for (int i = 0; i < input.length(); i++)
 		{
-			if ('\\' == input.charAt(i) && i + 1 < input.length() &&
-					('\\' == input.charAt(i + 1) || '.' == input.charAt(i + 1)))
+			if ('\\' == input.charAt(i) && i + 1 < input.length() && '.' == input.charAt(i + 1))
 			{
 				i++;
 			}

As an extra we would need upgrade patch to

convert \\ to \

Idea is that we shall only unescape dots that are escaped.

However it's not clear what to do in that case:

\\.