Recently commons-compresswas updated to 1.26.x (here) which requires commons-io:2.15.1
This was not noticed in the deployer CI but rather surfaced down in the Cloud Foundry ATs as an obscure NoClassDefFoundError (nobody likes that).
Doing a basic task launch (timestamp) resulted in:
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT java.lang.NoClassDefFoundError: org/apache/commons/io/build/AbstractStreamBuilder
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:858) ~[commons-compress-1.26.0.jar:1.26.0]
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:930) ~[commons-compress-1.26.0.jar:1.26.0]
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:818) ~[commons-compress-1.26.0.jar:1.26.0]
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:794) ~[commons-compress-1.26.0.jar:1.26.0]
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:714) ~[commons-compress-1.26.0.jar:1.26.0]
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:701) ~[commons-compress-1.26.0.jar:1.26.0]
2024-05-16T13:53:50.21-0500 [APP/PROC/WEB/0] OUT at org.cloudfoundry.util.ResourceMatchingUtils.getArtifactMetadataFromZip(ResourceMatchingUtils.java:80)
We should see if we can mock CloudFoundry out and add a test for this here in this repo because things are harder to diagnose the further up the testing pyramid. If we can't mock it and it truly needs CF available to test this, that is fine.
Recently
commons-compress
was updated to1.26.x
(here) which requirescommons-io:2.15.1
This was not noticed in the deployer CI but rather surfaced down in the Cloud Foundry ATs as an obscure
NoClassDefFoundError
(nobody likes that).Doing a basic task launch (
timestamp
) resulted in:We should see if we can mock CloudFoundry out and add a test for this here in this repo because things are harder to diagnose the further up the testing pyramid. If we can't mock it and it truly needs CF available to test this, that is fine.
FYI - this was the commit that fixed the issue https://github.com/spring-cloud/spring-cloud-deployer/commit/310f4fd37ab480f7d665e5cb38eedbbfa2623072