Troubleshooting ClassNotFoundException with Filemon (on Windows)

Have you ever run into classpath issues where you could have sworn the class was in a jar, the jar was on a classpath, yet you still got NoClassDefFoundError or ClassNotFoundException. Or perhaps you define several Classloaders in your application each with its own classpath and are not quite sure which one gets the priority in a specific situation.

On Windows, FileMon from SysInternals is a great free tool to resolve exactly those kind of questions.

Imagine you have a very simple java class:

public class Test
{
public static void main(String[] args) throws Exception
{
Class c = Class.forName("somepackage.SomeClass");
}
}

Basically, we are trying to load somepackage.SomeClass into the system. For our test purposes that class does not exist.

Compile this class and run. It comes back with java.lang.ClassNotFoundException: somepackage.SomeClass. As it should.

The question however is what Classpath the JVM was looking for the class on. If your application is a J2EE deployment or anything with custom classloaders, this question may become a hard one to answer.

This is where the FileMon shines. FileMon will show you every file operation on the machine performed by any - or all - of the processes.

Start it up and set the filter to java.exe . If that causes problems you can reset filter to * and check what name your JVM is generating the log entries under.

With FileMon capture enabled, rerun your test or scenario. After you see the ClassNotFoundException, stop the capture. Now search from the capture start for the classname you got in the exception, in this case SomeClass. You should see a sequence of the lines similar to the following (some columns had been cut):

C:\temp\filemontest	SUCCESS
C:\somepackage\SomeClass.class	PATH NOT FOUND
C:\temp\filemontest	SUCCESS
C:\Utils\somepackage\SomeClass.class	PATH NOT FOUND
C:\temp\filemontest	SUCCESS
C:\temp\somepackage\SomeClass.class	PATH NOT FOUND
C:\temp\filemontest	SUCCESS
C:\temp\filemontest\somepackage\SomeClass.class	PATH NOT FOUND

From here, we can figure out that the classpath checked was: C:\;C:\Utils;C:\temp;C:\temp\filemontest.
Now, you can check that against your expectations and figure out how to fix the discrepancy.

If you are on Solaris/Linux machine instead, look into truss/strace for a way to achieve very similar results.

BlogicBlogger Over and Out

XMLStarlet: A gentle introduction into XSLT

In my work as a BEA Tech Support engineer, I have to spend a lot of time dealing with XML content. In the past I tried to grep through the files, but had found that element order and random newlines make it quite hard. I have since found a solution.

Everybody who works with XML probably knows that XSLT/XPATH is supposed to be a good way to manipulate XML files. Unfortunately, XSLT is very verbose and sometimes quite obscure, especially when it comes to plain text output. I have tried using it a couple of times and never got beyond a simple HelloWorld.

Then I discovered XMLStarlet. It is built on libxml2 and libxslt and is provided for several platforms as a all-in-one executable.

XMLStarlet has a number of options; among them are transformation, edit, canonicalization and many others. The one I find most useful is select. With select, XMLStarlet works something like an in-file unix find. You provide command line switches which describe what you are searching for and what you want to display.

And the best part of all is that the proprietary syntax translates into 100% correct XSLT, so when you have outgrown the tool or need more specific tweaking, you take the generated XSLT and start editing that directly.

Let me give you an example. I often have to work with Weblogic's config.xml file which defines the configuration for a whole domain. It describes servers, clusters, JMSQueues, SecurityRealms and many more aspects. And, as config.xml was designed for the software's convinience rather than support engineer's, it groups elements together in a less than intuitive fashion.

Following, is a very small part of config.xml structure (derived from a sample config.xml file using XMLStartlet's xml el -a config.xml command.

Domain

Domain/@Name

....

Domain/Server

Domain/Server/@ListenAddress

Domain/Server/@ListenPort

Domain/Server/@Name

Domain/Server/@Cluster

...

Domain/Server/WebServer

...

A task I need to do often is to check how many servers a client's config.xml has, what their names are and how are they distributed between clusters. Manually, it means searching for <Server tag and then eyeballing for Name attribute.

With XMLStarlet it becomes:
xml sel -t -m //Server -v @Name -n config.xml
with the output of

nhgprdadmin
nhgapp03a
nhgapp03b
nhgapp01a
nhgapp04a
nhgapp01b
nhgapp04b
nhgapp02a
nhgapp02b


In here, -m is match and -v is display. -n is a newline, not something that is obvious in XSLT itself. The parameters are XPATH values.

Do this 5 times and it pays back the time investment involved in learning the command syntax.

Now, let's try to do something more complex. Specifically, I want to check which cluster each server belongs to. And to cut this post short(er), let's say I want it sorted by the cluster.

The command would be:
xml sel -t -m //Server -s ATL @Cluster -v @Cluster -o " - " -v @Name -n config.xml
with the output of

- nhgprdadmin
cehs - nhgapp03a
cehs - nhgapp03b
cehs - nhgapp04a
cehs - nhgapp04b
his1 - nhgapp01a
his1 - nhgapp02a
his2 - nhgapp01b
his2 - nhgapp02b


We can immediately see that there is one non-clustered (admin) server, 4 servers in one cluster and 2 servers each in the other two clusters. In the command above, -s is sort by Cluster attribute and -o is verbose output used for spacing. Instead of -v -o -v, I could use -v "concat(XXX,yyy,ZZZ)", but that required a greater knowledge of XSLT than I had the first time I used the tool.

And just to show you the XSLT that the above command really corresponds to, it is (after removing long header and footer):

<xsl:template match="/">

 <xsl:call-template name="t1"/>

</xsl:template>

<xsl:template name="t1">

 <xsl:for-each select="//Server">

   <xsl:sort order="ascending" data-type="text" case-order="upper-first" select="@Cluster"/>

   <xsl:value-of select="@Cluster"/>

   <xsl:value-of select="' - '"/>

   <xsl:value-of select="@Name"/>

   <xsl:value-of select="'&#10;'"/>

 </xsl:for-each>

</xsl:template>

As you probably can imagine, it takes quite a bit longer for an XSLT beginner to write the code above from scratch.

I hope this was useful and will convince you to have a look at the XMLStarlet.

BloggicBlogger Over and Out

A fitting first post: I love Vim

One's first post should be interesting. And what could make a techie's post more interesting then the Vi vs. Emacs battle. So in my very first post allow me to declare my allegiance to Vi. Or to be more specific Vim.

But it would not be interesting to just announce my preferences and be done with that. Let me instead explain a little what I like in Vim and what I have done to it in making it useful for me.

Following are the basic plugins I have added to my setup:

OTF: On-The-Fly coloring of patterns

This plugin is indispensable if you are trying to track several items happening in a file at once. For example, if you are trying to read a piece of java code and need to keep track of all log messages, just highlight the specific calls with one of OTF's colours and you are done. You can of course do it using search pattern, but then you java lost the search ability. And OTF allows you to do multiple colours, so you can keep track of multiple patterns at the same time.

F: An unfortunately named Find plugin

You may not use it too often, but if you have to look at something that has a line of useful data, couple of lines of junk, another line of useful data, this tool allows you to hide away the junk by folding it away. In some instances, it is better than doing :v/pattern/d because you may actually want to examine the particular context in details. With F, you just open the fold above/bellow.

JavaDecompiler: A Vim frontend for JAD

If you decompile class files for research purposes, you might be annoyed with having to run class file through decompiler, save the result into a second file, open that file in the favourite java editor and then - when you are finished - still having to delete the decompiled file. If Vim is your favourite editor, this instead becomes a true one-click exercise. Find the file, open it and voila. No manual conversion, no deletion. This plugin will do it all for you. Just make sure your .class files are associated with Vim.

And this is my basic setup. I have additional configuration settings and may blog about them another time if there is any interest.

And just as a disclamer, you can do most of those things with Emacs and I have done so in the past. But Vim is the one I kept coming back to and don't think I will change away from it any time soon.

BlogicBlogger Over and Out