Am 18.06.24 um 10:37 schrieb Rémy Maucherat:
On Tue, Jun 18, 2024 at 9:45 AM Rainer Jung <rainer.j...@kippdata.de> wrote:

Hi there,

the test classes org.apache.catalina.users.TestDataSourceUserDatabase
and org.apache.catalina.realm.TestDataSourceRealm have a filing test
which needs Java 17 due to the class version of
org/apache/derby/jdbc/EmbeddedDriver. For TC 10.1 this leads to failures
when testing with JDK 11-16.

More build dependencies now need Java 17 for the testsuite (bnd in
particular, and even the Ant from my Fedora ...). How do you work
around that to reach the test ?

Good point, thanks for asking:

- I provide (recent) ant myselve and add it to the PATH

- I first build everything using the release JDK version, so for instance Java 22 (just on one platform, currently RHEL 8).

- for each test platform and JVM version I use a copy of the resulting build and output tree and I adjust build.xml to be able to only run the tests:

- I set an additional custom property skip.build.java.version=true in build.properties

  - The block "<!-- Check Java Build Version -->" ist changed from

    <condition>
      <not><javaversion atleast="${build.java.version}" /></not>
    </condition>

to

    <condition>
      <and>
        <not><javaversion atleast="${build.java.version}" /></not>
        <not><isset property="skip.build.java.version"/></not>
      </and>
    </condition>

- the targets setup-bnd and add-osgi get an additional unless="skip.build.java.version" to supress them during the pure test run

  - the nio and nio2 test targets are duplicated and slightly adjusted
    (dropping the dependencies test-compile and deploy).
    Originally:

<target name="test-nio" description="Runs the JUnit test cases for NIO2. Does not stop on errors."

depends="setup-jacoco,test-compile,deploy,test-openssl-exists" if="${execute.test.nio}">
     <runtests protocol="org.apache.coyote.http11.Http11Nio2Protocol"
               extension=".NIO" />
   </target>

<target name="test-nio2" description="Runs the JUnit test cases for NIO2. Does not stop on errors."

depends="setup-jacoco,test-compile,deploy,test-openssl-exists" if="${execute.test.nio2}">
     <runtests protocol="org.apache.coyote.http11.Http11Nio2Protocol"
               extension=".NIO2" />
   </target>

  The added targets:

<target name="test-only-nio" description="Runs the JUnit test cases or NIO without test preparations. Does not stop on errors." depends="setup-jacoco,test-openssl-exists" f="${execute.test.nio}">
    <runtests protocol="org.apache.coyote.http11.Http11Nio2Protocol"
              extension=".NIO" />
  </target>

<target name="test-only-nio2" description="Runs the JUnit test cases or NIO2 without test preparations. Does not stop on errors." depends="setup-jacoco,test-openssl-exists" f="${execute.test.nio2}">
    <runtests protocol="org.apache.coyote.http11.Http11Nio2Protocol"
              extension=".NIO2" />
  </target>

  - finally the main test target alslo gets a slighty adjusted twin
    (drop coverage-report, call the new "only" targets).
    Originally

  <target name="test" description="Runs the JUnit test cases"
          depends="test-nio,test-nio2,coverage-report,test-status" />

   The added target:

  <target name="test-only" description="Runs the JUnit test cases"
          depends="test-only-nio,test-only-nio2,test-status" />


- call the new "test-only" target.

There are probably more clever ways to achieve this, but that's at least what I use to be able to run the tests on older JVM versions.

Since I do not apply changes to the tests temselves, this means, that tests assuming a newer JVM version than the minimal runtime version will fail when I run them. Of course I can suppress them with test.exclude (probably only the whole class, not just individual failing tests?). I will do that, if the derby dependency was intentionally updated.

Thanks and regards,

Rainer

Rémy

Details:

Testcase: testBasicUserRoleDatabase took 0.749 sec
          Caused an ERROR
org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
version of the Java Runtime (class file version 61.0), this version of
the Java Runtime only recognizes class file versions up to 55.0
java.lang.UnsupportedClassVersionError:
org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
version of the Java Runtime (class file version 61.0), this version of
the Java Runtime only recognizes class file versions up to 55.0
          at java.base/java.lang.ClassLoader.defineClass1(Native Method)
          at
java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
          at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
          at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
          at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
          at java.base/java.lang.Class.forName0(Native Method)
          at java.base/java.lang.Class.forName(Class.java:315)
          at
org.apache.catalina.users.TestDataSourceUserDatabase$DerbyUserDatabase.open(TestDataSourceUserDatabase.java:103)
          at
org.apache.catalina.users.TestDataSourceUserDatabase.testBasicUserRoleDatabase(TestDataSourceUserDatabase.java:131)
          at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
          at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
          at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

and

Testcase: testRealm took 1.298 sec
          Caused an ERROR
org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
version of the Java Runtime (class file version 61.0), this version of
the Java Runtime only recognizes class file versions up to 55.0
java.lang.UnsupportedClassVersionError:
org/apache/derby/jdbc/EmbeddedDriver has been compiled by a more recent
version of the Java Runtime (class file version 61.0), this version of
the Java Runtime only recognizes class file versions up to 55.0
          at java.base/java.lang.ClassLoader.defineClass1(Native Method)
          at
java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
          at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
          at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
          at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
          at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
          at java.base/java.lang.Class.forName0(Native Method)
          at java.base/java.lang.Class.forName(Class.java:315)
          at
org.apache.catalina.realm.TestDataSourceRealm$DerbyDataSourceRealm.open(TestDataSourceRealm.java:61)
          at
org.apache.catalina.realm.TestDataSourceRealm.testRealm(TestDataSourceRealm.java:106)
          at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
          at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
          at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


Best regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to