Are you creating xml out of those json data? I think xml elements have to start with non-digits. I would add a check in your program to add a prefix. (We use for example _ in some cases).

if you show the whole stack trace it’s easier to tell, but I suspect the error might be from xml parser not from JDom.

Thank you @ecki for the quick response.

Yes, I am converting xml out of json data, yes, xml elements have to start with non-digit hence it is throwing error, but it was working fine with dom4j 1.5.2, the only difference is if I replace dom4j 1.5.2 to with dom4j 2.1.3 it is failing.

Below is my code, here the Node is dom4j node:

public List serializeToXml(String tag) {
List list = new ArrayList();
return list;
}

in the above function if the tag value starts with digit it is failing, I am converting the tag like this:

private String makeXmlCompliantTag(String tag) {
if (Character.isDigit(tag.charAt(0))) {
return "prefixstr_" + tag;
}
return tag;
}

**after this it is working fine, but the json I am getting is from external application hence I don't want to modify the data, is there any other way to resolve this issue? **

why is it failing after dom4j upgrade?

anything I can do to avoid strict check by dom4j?

Really appreciate your help.

Thanks
Ashok.

Well, it looks like an intentional fix to make JDom more compliant.

This is the change: c2a99d7
Not sure if @FilipJirsak would like to make it configurable.
I can only recommend to not rely on not-standard compliant file formats.

yes @ecki I agree with you it is to make it more compliant, but it is another application which I cannot control, can you make it configurable? because of this issue I got stuck with old dom4j(1.5.2), with this I am not able to address the vulnerabilities in my product.

Thank you again for your prompt response.
@FilipJirsak can you please make this validation configurable?

Thanks
Ashok.

I don't want to add configuration options to these classes, because testing the configuration options would slow down code for everyone. In the future, I rather consider that it should be possible to use a custom implementation of these classes (i.e. QName and Namespace would become an interface, as is the case with Node and its descendants).
At the moment, probably the only option is to build dom4j yourself from source and comment the above test there.
In general, I'd recommend trying to avoid using non-standard XML, because you're bound to run into similar problems in virtually any software where you work with such XML.