Description
Bug report
After upgrading to Spring Boot 3.2, my application stops working, until I add the <loaderImplementation>CLASSIC</loaderImplementation> configuration to the repackage Maven goal.
The particularity of my application, is that one of the jars is a security library which is signed (the library recuperates the signature via Class::getSigners() to verify it when initializing). In previous versions of Spring Boot, requiresUnpack used to do the trick:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<requiresUnpack>
<dependency>
<groupId>eu.europa.ec.digit.iam.eulogin.client</groupId>
<artifactId>eulogin-tomcat-10.0</artifactId>
</dependency>
</requiresUnpack>
</configuration>
...
</plugin>Now, the application only works by reverting to the CLASSIC loader implementation.
By debugging the application, I see the following differences between the two cases:
In the CLASSIC loader, the library is loaded via LaunchedURLClassLoader using the scheme file:/...
and the signers are correctly returned:
In the new loader, the library is loaded via LaunchedClassLoader using the scheme jar:file:/...
and the signers are lost:
It would be desirable that the getSigners() info of signed jars is preserved by the loader, when using the repackage Maven goal.