The SAXParseException in WebClient API Against 3.3.0 and Later

Posted on by

After installing 3.3.0, I started to get:

org.xml.sax.SAXParseException: The element type "init" must be terminated by the matching end-tag "</init>"

This would appear to be a structure mismatch in the WebClient API during initial login, as a result of 3.3.0, but as a reminder going forward, this <init> might actually be part of this exception dump, which is blindly sent un-URL-escaped to the client:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 500 com/virtualinstruments/cli/ICommandServer</title>
</head>
<body><h2>HTTP ERROR: 500</h2><pre>com/virtualinstruments/cli/ICommandServer</pre>
<p>RequestURI=/WebServices</p><h3>Caused by:</h3><pre>java.lang.NoClassDefFoundError: com/virtualinstruments/cli/ICommandServer
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.finisar.util.XStreamFactory.createXStream(XStreamFactory.java:60)
at com.finisar.web.WebServicesServlet.<init>(WebServicesServlet.java:36)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

Do you see the third-last line?  The “<init>” is right there.  Since it’s in the middle of XML-ish HTML, it really needs to have a “</init>”, which is really the underlying cause of the Exception.

I guess this is one case where unclean text is just sent across, hindering any graceful attempt to pull out the status message and react accordingly — because part of the message is trashed, so it’s all trashed.

For when I run into it again, the real error is hidden somewhere on the server, and a quick text dump in code helps:

  httpPost.setEntity(new StringEntity(loginMessage));
  response = httpClient.execute(httpPost);
+ response.getEntity().writeTo(System.out);

Unfortunately, this dump occurs before the error is realized, so we can’t just react to the error by dumping the raw message — it’s already consumed! 🙁