Announcement

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

    Strange error when including smartgwt tools in project

    Smartgwt Pro 13.0-d20200824, GWT 2.9.0

    Have a strange issue. I have a working project with the above versions. Started trying to use "schemabean" in a ds. Had to add isomorphic-tools as a maven dependency on the project. This results in me unable to run the project. I get the error below and Jetty exits. I remove the jar-file and it starts working again.

    I have no idea what it means, you got any thoughts?

    Code:
    java.lang.IncompatibleClassChangeError: class com.google.gwt.dev.javac.BytecodeSignatureMaker$CompileDependencyVisitor has interface org.objectweb.asm.ClassVisitor as super class
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
        at com.google.gwt.dev.javac.BytecodeSignatureMaker.visitCompileDependenciesInBytecode(BytecodeSignatureMaker.java:227)
        at com.google.gwt.dev.javac.BytecodeSignatureMaker.getCompileDependencySignature(BytecodeSignatureMaker.java:209)
        at com.google.gwt.dev.javac.CompiledClass.getSignatureHash(CompiledClass.java:166)
        at com.google.gwt.dev.javac.Dependencies$Ref.<init>(Dependencies.java:41)
        at com.google.gwt.dev.javac.Dependencies$Ref.<init>(Dependencies.java:36)
        at com.google.gwt.dev.javac.Dependencies.resolve(Dependencies.java:100)
        at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:349)
        at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:532)
        at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:464)
        at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:423)
        at com.google.gwt.dev.codeserver.Recompiler.initWithoutPrecompile(Recompiler.java:213)
        at com.google.gwt.dev.codeserver.Outbox.maybePrecompile(Outbox.java:89)
        at com.google.gwt.dev.codeserver.Outbox.<init>(Outbox.java:61)
        at com.google.gwt.dev.codeserver.CodeServer.makeOutboxTable(CodeServer.java:192)
        at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:151)
        at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:104)
        at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:55)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.google.gwt.dev.shell.SuperDevListener.runCodeServer(SuperDevListener.java:112)
        at com.google.gwt.dev.shell.SuperDevListener.start(SuperDevListener.java:91)
        at com.google.gwt.dev.DevMode.ensureCodeServerListener(DevMode.java:666)
        at com.google.gwt.dev.DevModeBase.doStartup(DevModeBase.java:785)
        at com.google.gwt.dev.DevMode.doStartup(DevMode.java:551)
        at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:888)
        at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:705)
        at com.google.gwt.dev.DevMode.main(DevMode.java:432)

    #2
    That exception looks similar to what we see with our BuiltInDS sample project if the old asm-5.x JAR is used instead of the new asm-8.x JAR, required for GWT 2.9.0.

    The download you mentioned should contain that sample under /samples/built-in-ds. Take a look at the classpath in that sample to see what JARs you should be using. If you're using GWT 2.9.0 exclusively you can probably remove the older asm JAR versions from the lib/ directory under your installation of SGWT.

    Note that we're also looking into whether there's an issue with our Maven files, but the above should get you running again.
    Last edited by Isomorphic; 9th Sep 2020, 18:13.

    Comment


      #3
      ok. I took a look at the maven dependency graph for my War project (i get your stuff through maven) :

      Code:
      [INFO] +- com.isomorphic.smartgwt.pro:isomorphic-tools:jar:13.0-d20200824:compile
      [INFO] |  +- com.isomorphic.smartgwt.pro:isomorphic-sql:jar:13.0-d20200824:compile
      [INFO] |  \- com.isomorphic.smartgwt.pro:isomorphic-hibernate:jar:13.0-d20200824:compile
      [INFO] |     \- org.hibernate:hibernate-entitymanager:jar:3.6.10.Final:compile
      [INFO] |        +- cglib:cglib:jar:2.2:compile
      [INFO] |        |  \- asm:asm:jar:3.1:compile
      [INFO] |        +- javassist:javassist:jar:3.12.0.GA:compile
      [INFO] |        \- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile
      In your own pom files, there is no mention of any asm dependency.

      Comment


        #4
        As mentioned in post #2, we're looking into correcting the Maven files, but for now you can work around the issue by either removing the asm JAR completely (if your project doesn't actually need it), or by changing your classpath to pick up the asm-8.x JAR instead of the earlier version. The asm-8.x JAR should already be in the lib/ directory under the root of your installation of SGWT Pro 13.0.

        Comment


          #5
          Saw you post, was just trying to help with the printout. Ok thanks great stuff, good to know.

          (Just an FYI from a user perspective, our process is not that we tend to download and look in that lib dir, we exclusively use maven for everything related to our project setup. I would suspect we're not alone. Might be right or wrong from your perspective, but that's how many work :) )

          Comment


            #6
            We weren't suggesting that customers take the approach of hand-picking JARs from the lib/ directory - we were just pointing out that the JAR you need to work around the reported issue is there.

            Those using Eclipse but not Maven can get the right build configuration by importing the samples/built-in-ds project from the Eclipse "File" menu. That will load the BuiltInDS project with a predefined list of JAR dependencies from lib/, as well as a prebuilt launch configuration.

            Comment


              #7
              Gotcha. Great.

              Comment

              Working...
              X