0

I am writing a junit test that is testing and older piece of code. This code works on our iplanet webservers and our local Tomcat servers and runs with no problems. However when run by the JUNIT test I get this exception.

Background: It pulls an XSL file from a JAR then transforms it with an xml document that is read in from a resource file.

I have tried changing transformer factories, changing encoding, and checked all files for null characters using a hex editor. Any ideas?

[Fatal Error] :2251:46: An invalid XML character (Unicode: 0x0) was found in the value of attribute "test" and element is "xsl:when". SystemId Unknown; Line #2251; Column #46; org.xml.sax.SAXParseException; lineNumber: 2251; columnNumber: 46; An invalid XML character (Unicode: 0x0) was found in the value of attribute "test" and element is "xsl:when".

**UPDATE I have found that if I use the project's class folder where the XSL is held and move it about the jar's dependency it works, but if it uses the xsl out of the jar it breaks

3 Answers3

0

SUGGESTIONS:

1) Make sure your library versions all match.

2) I suspect that " An invalid XML character (Unicode: 0x0) was found" might be caused by any of several completely different things. You should investigate each of them.

3) First, most obvious - check your input for a null character :)

4) Second, check your encoding - perhaps your sender is writing UTF-16, but your reader is expecting UTF-8. Here's a good link:

* Error about invalid XML characters on Java

This is an encoding issue. Either you read it the inputstream as UTF8 and it isn't or the other way around.

You should specify the encoding explicitly when you read the content. E.g. via

new InputStreamReader(getInputStream(), "UTF-8")

Another problem could be the tomcat. Try to add URIEncoding="UTF-8" in your tomcat’s connector settings in the server.xml file

5) The root cause might also be a failed read or a missing object of some kind. A missing definition, perhaps.

Q: What is "SystemId"? What might cause it to "go missing"?

6) One possibility is that "resolveEntity()" is failing:

InputSource resolveEntity(String publicId, String systemId)

Here are a couple of links regarding that problem:

7) Both of these links suggest "resolveEntity() might be failing because you can't connect to a specified host. Check the network host names listed in your XML, and make sure you can "ping" them.

Community
  • 1
  • 1
paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • I am not sure what it means by systemId. I have seen that listed with this error other places. I don't think anything is missing since is the exact code running fine on the servers. I will check my code to make sure there isn't a small bit of code that is run before the test code that could cause it. – user1943539 Jan 02 '13 at 18:57
0

If it's got as far as line 2251 that suggests strongly that there's something wrong with the file contents around that location. If there's nothing wrong with the file at that location, my next suggestion would be that something's wrong with the parser. I know it sounds crazy, but the XML parser built in to the JDK is seriously buggy, and I would check whether the problem goes away if you install the Apache version of Xerces in its place. In many cases this is simply a question of putting the relevant JAR files in the lib/endorsed directory of the JDK installation.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • Thanks, that cleared some of the errors. Now it throws another issue: "The end-tag for element type "xsl:text" must end with a '>' delimiter." I checked and the '>' is located in the spot that it is saying that it isn't. – user1943539 Jan 03 '13 at 18:30
  • I took the xsl file and the XML file that it is transformed with and used an online transformer and it worked perfectly. – user1943539 Jan 03 '13 at 19:26
  • Clearly there's something odd going on, and we're not going to be able to help identify it without more complete information. – Michael Kay Jan 07 '13 at 09:19
0

This was caused because the XSL files I was trying to transform were still in a JAR. I had to have Maven extract the files into the target directory first.