Announcement
Collapse
No announcement yet.
X
-
Aha, mismatched java binary & libs versions, as suspected. All is right in the world again!
-
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.
Leave a comment:
-
When I expand in my eclipse the JavaSE 1.8 lib reference I see this:
That seems grossly wrong?
Leave a comment:
-
Yes there is something weird seen when using the jcmd -l from the terminal:
Code:% 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
-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.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by tece321 View Post
So still stumped...
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...
Leave a comment:
-
Originally posted by Isomorphic View PostThat'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).
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:
Code: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
Leave a comment:
-
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.
Leave a comment:
-
java.lang.NoClassDefFoundError: org/ietf/jgss/GSSException
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:
Code:== 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)
Previous version was 13.0p 2022-05-17, almost a year ago.
I should note that we are using Java 8 version.
Tags: None
Leave a comment: