This ImageIO initialization process depended on a bunch of metadata in the JAR manifest that we had to inject in our build, since it was not being preserved by the shadow-jar process. But I could see that there was similar initialization code floating around in our dependencies that would not check the manifest: it had all the attributes JAI used to load from the manifest hard-coded.
Removing the call to ImageIO.scanForPlugins() and instead calling JAIExt.initJAIEXT(), there were no longer any failures even when the attributes were left out of the Manifest. The backend was nonetheless capable of writing a GeoTIFF. But in fact, even removing JAIExt.initJAIEXT() it is still able to write a GeoTIFF. The GeoTools writer now seems to use ImageIOExt directly instead of the original ImageIO. It appears that no scanning is needed now, or that scanning is already done by Geotools.
I have tested exports of TIFF and PNG files and everything seems to work fine with no ImageIO initialization.
This also records the target JVM version in the JAR Manifest, which was causing the worker failure @ansoncfit mentioned in the same issue. I have tested the resulting worker version v5.10.0-10-g6a0f9c7 on production. The worker is able to detect the right JVM version, and starts up properly.
We were manually initializing ImageIO, which is part of Java Advanced Imaging -- old, unmaintained, and originally closed-source Oracle code. Geotools used to depend on this, but has migrated to a newer completely open source implementation of this API called JAI-Ext. See https://www.geosolutionsgroup.com/blog/developers-corner-jai-ext-the-open-source-replacement-for-oracle-jai/
This ImageIO initialization process depended on a bunch of metadata in the JAR manifest that we had to inject in our build, since it was not being preserved by the shadow-jar process. But I could see that there was similar initialization code floating around in our dependencies that would not check the manifest: it had all the attributes JAI used to load from the manifest hard-coded.
Removing the call to
ImageIO.scanForPlugins()and instead callingJAIExt.initJAIEXT(), there were no longer any failures even when the attributes were left out of the Manifest. The backend was nonetheless capable of writing a GeoTIFF. But in fact, even removingJAIExt.initJAIEXT()it is still able to write a GeoTIFF. The GeoTools writer now seems to use ImageIOExt directly instead of the original ImageIO. It appears that no scanning is needed now, or that scanning is already done by Geotools.I have tested exports of TIFF and PNG files and everything seems to work fine with no ImageIO initialization.
This also records the target JVM version in the JAR Manifest, which was causing the worker failure @ansoncfit mentioned in the same issue. I have tested the resulting worker version
v5.10.0-10-g6a0f9c7on production. The worker is able to detect the right JVM version, and starts up properly.