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]>