java.lang.NoClassDefFoundError: org/ietf/jgss/GSSException

[tece321]

SmartClient Version: v13.0p_2023-04-25/PowerEdition Deployment (built 2023-04-25)

This is a stretch for a question, but am stumped at present.

I am trying out a new version of 13.0p, from nightly build 2023-04-25. Everything compiles with no errors, but there is this error at runtime, i.e. loading the webApp, just at the start:

== 2023-04-27 12:45:42,802 [1-64] DEBUG SQLDriver - BEER: Passing JDBC URL only to getConnection
[WARN] Server class 'org.ietf.jgss.GSSException' could not be found in the web app, but was found on the system classpath
   [ERROR] Found resouce but unrecognized URL format: 'jrt:/java.security.jgss/org/ietf/jgss/GSSException.class'
=== 2023-04-27 12:45:42,806 [1-64] DEBUG DSRequest - About to free up resources for request of type fetch on DataSource Users
=== 2023-04-27 12:45:42,807 [1-64] WARN RequestContext - dsRequest.execute() failed:
java.lang.NoClassDefFoundError: org/ietf/jgss/GSSException
    at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:621)

There must be something wrong in my classpath? Never seen this problem before.

Previous version was 13.0p 2022-05-17, almost a year ago.

I should note that we are using Java 8 version.

[Isomorphic]

That's an odd one. That exception is supposed to part of core .jars in your JRE, and it's not at all new (it was introduced before Java 5).

Best guess would be something like: you are using the "java" binary from JDK 9+, but the classpath is set to look to JDK 8 jars (or vice versa).

The reason for this guess is that in JDK 9 they reorganized things and made them modular. JDK 9+ would look for this class in "jrt.jar" but it was "rt.jar" in JDK 8 and lower.

So just run "java -version" (or echo it from your launch script or whatever) to see what Java binary you are actually running.

[tece321]

That's an odd one. That exception is supposed to part of core .jars in your JRE, and it's not at all new (it was introduced before Java 5).

Best guess would be something like: you are using the "java" binary from JDK 9+, but the classpath is set to look to JDK 8 jars (or vice versa).

Thanks for the prompt reply.

Well I'm running from within eclipse. It is definitely configured to run Java 1.8.




The bottom of the exception stack (see top in post #1) looks like:

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
    at java.base/java.lang.Thread.run(Thread.java:835)
Caused by: java.lang.ClassNotFoundException: org.ietf.jgss.GSSException
    at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload$WebAppClassLoaderExtension.findClass(JettyLauncher.java:478)
    at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:441)
    at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:403)
    ... 52 more

So still stumped...

[tece321]

So still stumped...

Just to try something else, I deployed this build to a tomcat server, and it works just fine. Connections to database work, and UI (the small part I tested) seems to be fine.

So is this a jetty problem /incompatibility? The original issue of the exception occurs when I run from within eclipse, using the local jetty, and attempting to run in debug mode.

Suppose I'm still stumped...

[Isomorphic]

We're still suspicious of what Java binary is actually executing. You can use the command-line tool "jcmd" to send the "VM.version" command.

Also, in JDK9+, where the core runtime has been split into modules, you would need to configure that JDK to make the GSS module available. So again, that would be a way this could happen if you were actually running the java binary from JDK9+

--add-modules java.security.jgss

If we're barking up the wrong tree with JDK versions, the remaining possibilities would be:

1. Eclipse is just badly confused, and is feeding the internal Jetty bad information. Restart Eclipse to check on this.

2. you've gotten Jetty's classloading system badly confused due to placement of .jars. This would be something bizarre like a developer copied core JDK jars (maybe rt.jar) directly into WEB-INF/lib, so the classloader thinks core JDK libraries are kind of simultaneously part of just this web app and part of the JRE.

[tece321]

Yes there is something weird seen when using the jcmd -l from the terminal:

% jcmd -l
Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/export/BEER/users/oconnor/tmpdir
141096 /projects/BEER/A0/tools/eclipse.photon//plugins/org.eclipse.equinox.launcher_1.5.0.v20180512-1130.jar -data /export/BEER/users/to920136/gitDevOC/BEER/eclipse -os linux -ws gtk -arch x86_64 -showsplash /projects/BEER/A0/tools/eclipse.photon//plugins/org.eclipse.epp.package.common_4.8.0.20180619-1200/splash.bmp -launcher /projects/BEER/A0/tools/eclipse.photon/eclipse -name Eclipse --launcher.library /projects/BEER/A0/tools/eclipse.photon//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.700.v20180518-1200/eclipse_1705.so -startup /projects/BEER/A0/tools/eclipse.photon//plugins/org.eclipse.equinox.launcher_1.5.0.v20180512-1130.jar --launcher.appendVmargs -exitdata 9800ae -product org.eclipse.epp.package.jee.product -vm /tools/oss/packages/x86_64-rhel7/java/jdk-12.0.2/bin/java -vmargs -Dosgi.requiredJavaVersion=1.8 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication -Dosgi.requiredJavaVersion=1.8 -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx1024m -j
119274 sun.tools.jcmd.JCmd -l
117279 com.google.gwt.dev.DevMode -remoteUI 39737:4266811869202784 -logLevel INFO -codeServerPort 30011 -port 8815 -war /export/BEER/users/to920136/gitDevOC/BEER/eclipse/BEER/war -startupUrl BeerMain.html -bindAddress 0.0.0.0 beer.BeerMain


[lvn-beer-stb-01->eclipse/BEER] (trunk) :718% env |grep JA
JAVA_HOME=/tools/oss/packages/x86_64-rhel7/java/jdk1.8.0_144
_JAVA_OPTIONS=-Djava.io.tmpdir=/export/BEER/users/oconnor/tmpdir
JAVAVER=jdk1.8.0_144

Is that a reference to a version 12 lib of the jdk? Wonder where that is coming from? I'm not familiar with the jcmd utility.

-vm /tools/oss/packages/x86_64-rhel7/java/jdk-12.0.2/bin/java

That is where IT stores versions of libs for this OS.


The final command was me searching in my terminal env for all JAVA variables.

[tece321]

When I expand in my eclipse the JavaSE 1.8 lib reference I see this:




That seems grossly wrong?

[tece321]

Eureka !

That was it. I have NO IDEA how my eclipse was pointing to the wrong version of VM/JRE. But I configured it manually and now there are NO exceptions from eclipse. Works just fine..




thanks so much for the great pointers.

[Isomorphic]

Aha, mismatched java binary & libs versions, as suspected. All is right in the world again!