[JAPEX-27] invalid XML output Created: 20/Feb/09  Updated: 25/Feb/09

Status: Open
Project: japex
Component/s: engine
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: dprunier Assignee: Santiago Pericas-Geertsen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 27


If configuration file contains parameters with entities (e.g. %lt, the XML
serialization does not escape such characters resulting in invalid output.

Comment by Santiago Pericas-Geertsen [ 25/Feb/09 ]

Did you mean < instead of %lt;? If so, it would be a character entity. Would it be possible for you to
attach a config file showing the problem?

Comment by dprunier [ 25/Feb/09 ]

Yeah, the entity <. It is correcly decoded (thanks to jaxb) but when
serialized to XM it is not encoded back to <. It is very easy to reproduce:
simply add a param <param name="test" value="<" /> in any valid configuration
file and look the XML report.

Comment by dprunier [ 25/Feb/09 ]

BTW, the issue is the same for every element in the config file. The fact that
it is actually parsed with a real XML parser but serialized printing strings to
a file is very likely to lead to corruption of the output.

Morover, this is a slightly different issue, but having parameter names
serialized as element names may also leads to invalid XML (since parameters
names are not explicitely restricted to NMTOKEN).

Comment by Santiago Pericas-Geertsen [ 25/Feb/09 ]

Sure, this makes sense. I believe someone else reported this before. It is kind of a global change, so I
don't think I'll be able to get to it anytime soon. Hopefully, you can work around it.

Comment by dprunier [ 25/Feb/09 ]

This is not that much complicated to throw in a ContentHandler instead of a
StringBuffer (done this millions of times), and that could be backward
compatible (keeping the old method). If i have some time, i might give it a shot.

For the parameter name as element name, this is not big deal, it should simply
be checked by the schema.


Generated at Wed May 27 16:43:42 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.