Re: debugging remote JAI app

Pete Soper <Pete-44l/[email protected]> Mon, 07 Jun 2010 10:52:51 -0400
Newsgroups gmane.org.user-groups.trijug.juglist
Message-ID <[email protected]>
On 06/06/2010 06:28 PM, Tom Roche wrote:
> 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".
>>      
The question is why the class mentioned above isn't seen? It's contained 
in the optional javax.media.jai package, which is part of the "Java 
Advanced Imaging API", which is available here:

http://java.sun.com/products/java-media/jai/downloads/download-1_1_2_01.html

This isn't part of the standard glop of stuff you get when you install 
Java SE, so maybe fetching this and getting it into your classpath will 
do the trick. You can hopefully put it someplace you can write to and 
just include the path to the end of the list with another colon.

-Pete

>> 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]>
>
> _______________________________________________
> Juglist mailing list
> [email protected]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
>