Monthly Archives: September 2012

Revision 345 – How to Read Nicknames from a BNA Server

Posted on by

Part of our task when installing the VirtualWisdom product is that last-gap: how to make it work within the customer’s ecosystem.

Sure, we don’t have to, but then the customer has a whole lot of extra work to maintain the product. This care-and-feeding, this sort of subtle extra work, is often referred as “friction”.

Revision 345 reduces the friction where there is an exploitable Brocade Network Administration service… and by “exploitable”, I’m not saying this as a bad thing, just something we can leverage.

It’s this simple:

Consider Mike. Poor guy, this guy has no time. He’s busy. He’s got BNA, SanScreen, and VI, and he’d love if any one of those guys read from the others.

Mike’s BNA server is at bna.example.com

Mike grabs a copy of the latest “vict.jar”, the Client Tool, and his Java at java.exe, and runs:

java.exe -jar vict.jar --nickname=bnapsql://bna.example.com

So that’s great, but Mike can’t really do anything with that. OK. Let’s check that out in Revision 346, where there will be rainbows, pots of gold, and something else added to the tools.

With my obsession for standards, yes this is a RFC-1738 -compliant URL. Intentionally. You can indeed give a username, password, and port number in there, if you really want to. I wouldn’t want to lead you astray 🙂

Revision 341

Posted on by

incorporating ER-414 changes based on testing against 10 different versions to yield schema versions (license-permitting)

Posted in Uncategorized

The SAXParseException in WebClient API Against 3.3.0 and Later

Posted on by
Reply

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! 🙁