This is pretty long - there is a TL;DR with action items at the bottom. ----
The Spring 5 update is now largely complete. Pull request here: https://github.com/geoserver/geoserver/pull/3202 There have been substantial changes in security that could do with a thorough review, most everything else has been relatively minor bugfixes. All core tests should be passing when run on Java 11. Some extensions may still be failing. ---- Separately, tests fail when run on Java 8 (I think GeoTools needs to be built with Java 11 for these failures to occur). These failures seem to be caused by covariant return types introduces in Java 11; basically we are running into the issue described here: https://github.com/apache/felix/pull/114 *Note:* These failures appear unrelated to the Spring 5 update, they were just masked by other issues until recently. The test failures are mostly of the form: No reader for /Users/tbarsballe/repos/GeoServer/geoserver/src/main/target/default7340521811081519346data/watertemp with format ImageMosaic This is ultimately caused by a JVM failure deep in file handling; typically via GeoTools NIOUtilities - that failure is of the form java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; I've looked into fixing this on GeoTools - an initial attempt is on the jdk11 branch here: https://github.com/geotools/geotools/commit/5246a20249bc42ab0b047170003fddf4d36e4ec3 That wasn't entirely successful, so I've attempted a more in-depth fix, currently in a PR here: https://github.com/geotools/geotools/pull/2141 Local testing has not been promising; It seems like more than just ByteBuffer is having this problem - I have most recently been seeing failures of the form java.lang.NoSuchMethodError: java.nio.CharBuffer.flip()Ljava/nio/CharBuffer; So, it seems like we will either need a more in-depth fix, or will not be able to build JDK8 artifacts using JDK11, even if compliance level is 1.8. ---- *TL;DR - What needs doing:* - Review https://github.com/geoserver/geoserver/pull/3202 , especially the gs-security changes - Test that PR / the spring-5.1 branch with some old data dirs that have encoded passwords to verify encoding/decoding is still backwards compatible (the unit tests ought to have caught this, but I don't quite trust them that far) - Fix any remaining test failures from the Spring 5.1 update (e.g. in extensions) - Determine a solution for JDK8 vs JDK11 artifacts, based on the information above. Cheers, Torben
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
