debugging remote JAI app

Tom Roche <[email protected]> Sun, 06 Jun 2010 18:28:48 -0400
Newsgroups gmane.org.user-groups.trijug.juglist
Message-ID <[email protected]>
Greetings from a Java refugee:

It's been several years since I've worked with Java apps (lately it's
mostly C and Fortran), so I'd appreciate suggestions that I could
forward to the admins of a remote Java app that I'd like to use,
but which doesn't WFM now ...

I'm working with an atmospheric model

* that runs on a large Linux cluster on which I am very not root

* which I access via X over ssh over a Cisco VPN

* that produces and consumes very large files in a particular format
  (NetCDF) representing environmental quantities (e.g. air pressure,
  chemical concentrations) over some geography.

To visualize those large files, the cluster admins have provided me
with VERDI (yes, it is an acronym), a java app. Unfortunately, VERDI
as installed doesn't Work For Me: when I attempt to reproduce a VERDI
example script (from the user's manual) using VERDI sample data, I get

> WARNING: Can't load a service for category "MathTransformProvider". Cause is "NoClassDefFoundError: javax/media/jai/WarpAffine".
> Exception in thread "main" java.lang.NullPointerException
> at anl.verdi.core.VerdiApplication$1.messageReceived(VerdiApplication.java:86)
> at simphony.util.messages.MessageCenter.fireMessageEvent(MessageCenter.java:141)
> at simphony.util.messages.MessageCenter.error(MessageCenter.java:126)
> at saf.core.runtime.Boot.run(Boot.java:90)
> at saf.core.runtime.Boot.main(Boot.java:169)

This suggests that the java installed on the cluster is missing all or
part of Java Advanced Imagining (JAI) or its dependencies. However,
when I reported this to the cluster admins, one replied

>> I followed the steps you outlined under both bash and tcsh shells
>> and I could not replicate your error; verdi initializes fine. I was
>> running from a Windows XP machine here on campus with XWin-32.

Since VERDI is running remotely (on the cluster), I strongly suspect
information about X servers (i.e. the client-side part of X) is
irrelevant. Particularly, I don't see how an X problem could cause the
java trace/throws above. (Esp since my X server is on my Ubuntu 9.10
box, on which I *strongly* suspect the relevant toolchain (X, ssh, etc)
is way more standards-compliant than that found on any Windows box.)
Am I missing something?

If not, is there anything else on the client side that could cause or
contribute to the problem? (I don't think so, but ICBW.)

If not, that leaves the server side: what could differ in our
environments on the cluster that could cause such differing results? I
suspect $PATH is not the answer: VERDI is freshly installed on the
cluster, so I suspect there is not more than one version. So the first
thing that comes to my mind is, java version. Does that seem
reasonable? If so, I know how to ask the admin(s) to check that (i.e.
`java -version`). I'm wondering, what else should I have them check?

TIA, Tom Roche <[email protected]>