Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

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

    Leave a comment:


  • tece321
    replied
    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..

    Click image for larger version

Name:	eclipse-java-compiler-CORRECTED.gif
Views:	797
Size:	183.0 KB
ID:	270079


    thanks so much for the great pointers.

    Leave a comment:


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


    Click image for larger version

Name:	JAVA-SE-1-8-in-eclipse.gif
Views:	790
Size:	189.6 KB
ID:	270077

    That seems grossly wrong?

    Leave a comment:


  • tece321
    replied
    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
    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.

    Leave a comment:


  • Isomorphic
    replied
    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:


  • tece321
    replied
    Originally posted by tece321 View Post


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

    Leave a comment:


  • tece321
    replied
    Originally posted by Isomorphic View Post
    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.

    Click image for larger version

Name:	eclipse-java-compiler.gif
Views:	963
Size:	238.5 KB
ID:	270072


    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
    So still stumped...

    Leave a comment:


  • Isomorphic
    replied
    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)
    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.
    Last edited by tece321; 27 Apr 2023, 12:02. Reason: Added Java 8 note
Working...
X