Could not find class com/quovadx/cloverleaf/upoc/Cloverleaf

[Chris Bagley]

Hi Cloverleafers!

Got a fun one this morning. I am trying to get to grips with calling Java procs within cloverleaf xlts. The code is as follows:

Code:

import com.quovadx.cloverleaf.upoc.*;
import java.util.*;
import java.sql.*;

public class MyTest extends XLTString {
   public Object xlateString (CloverEnv cloverEnv, Xpm xpm, String inVal)
       throws CloverleafException {

       String outVal = new String();
       try {
           int port = 1972;
           String url = “jdbc:Cache://111.111.11.11:1111/PRD”;
           String user = “USER”;
           String password = “PASSWORD”;
           String stQuery = “VALID SQL QUERY”;

           Class.forName (”com.intersys.jdbc.CacheDriver”);
           Connection dbconnection = DriverManager.getConnection(url,user,password);
           Statement stmt = dbconnection.createStatement();
           java.sql.ResultSet rs = stmt.executeQuery(stQuery);
           ResultSetMetaData rsmd = rs.getMetaData();

           int colnum = rsmd.getColumnCount();
           while (rs.next()) {
               for (int i=1; i<=colnum; i++) {                    outVal = outVal + "," + rs.getString(i);                }            }            dbconnection.close();        } catch (Exception ex) {            System.out.println("Caught exception: " +                               ex.getClass().getName()                               + ": " + ex.getMessage());        }        return outVal;    } }

And I can compile it successfully with:

Code:

javac -cp /opt/healthvision/cis5.8/integrator/ws_jdbc/java_uccs/:/opt/healthvision/cis5.8/integrator/clgui/lib/cljava.jar MyTest.java

And this compiled xlt proc works perfectly when using it within an xlt using the testing tool. But as soon as I try and use it properly it fails with the following.

Code:

Exception in thread “Thread-13” java.lang.NoClassDefFoundError: com/quovadx/cloverleaf/upoc/CloverleafException
Caused by: java.lang.ClassNotFoundException: com.quovadx.cloverleaf.upoc.CloverleafException
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
[xlt :xlat:ERR /0:  test2_xlate:12/03/2012 10:07:23] [0.0.242] Xlate ‘pleasegodwork.xlt’ failed: Tcl callout error
cljXLTStrings {CLASS MyTest} {XLT_STYLE SINGLE}:

errorCode: NONE

errorInfo:
could not find class “com/quovadx/cloverleaf/upoc/CloverleafException”.
Check your CLASSPATH settings.
Currently, the CLASSPATH environment variable is set to:
/opt/healthvision/cis5.8/integrator/clgui/lib/cljava.jar:/opt/healthvision/cis5.8/integrator/clgui/lib/cljava.jar:/opt/healthvision/cis5.8/integrator/ws_jdbc/java_uccs:.:/opt/healthvision/cis5.8/integrator/cloverleaf/java_uccs:/opt/healthvision/cis5.8/integrator/clgui/lib/cljava.jar:/opt/healthvision/cis5.8/integrator/java_uccs:
   while executing
“load [file nativename [file join $directory ${libraryName}[info sharedlibextension]]]”
   (procedure “Cljava_init” line 61)
   invoked from within
“Cljava_init [file join $env(HCIROOT) bin]”
   (procedure “init_Cljava” line 4)
   invoked from within
“init_Cljava”
   (procedure “cljXLTStrings” line 5)
   invoked from within
“cljXLTStrings {CLASS MyTest} {XLT_STYLE SINGLE}”

As you can see the cljava.jar file is in the classpath so I have no idea how it can’t find the CloverleafException.

Any ideas would be immensely welcome!

Topic

[Mitchell Rawlins]

I don’t know that I’ve seen this issue exactly, but there are a few things I might try.

Stop the process, stop and start the host server, then re-start the process.

Update both CLASSPATH and QDXI_CLASSPATH to be equal (or at least point to all the same things that you need for your classes).  I’d probably also doing the re-start process above after refreshing the environment variables.

You could check to make sure your cljava.jar files are still there, and open them up to make sure the appropriate classes are still in there.  Most GUI unzip tools will unzip the jar and let you see the classes inside.

I hope something there helps.  I’m interested to see what you find the issue is.  Good luck!

[Chris Bagley]

Cheers for the idea, but alas no change. The class is definitely in the jar and the jar is in the correct place.

[Author]

Replies