Classpath scanning ignores classes within Spring Boot's "repackaged" JARs
Description
Activity
Show:

Yoann Rodière October 28, 2022 at 2:33 PM
Related:
Fixed
Assignee

Reporter

Components
Sprint
None
Fix versions
Affects versions
Priority
Created October 21, 2022 at 2:25 PM
Updated July 3, 2023 at 11:27 AM
Resolved November 10, 2022 at 4:32 AM
The code within
org.hibernate.search.util.common.jar.impl.JarUtils#jarOrDirectoryPath
only works for “normal” JARs where the classes directory is the root of the JAR.It will not work for Spring-boot’s repackaged JARs in particular, where classes are located in
/BOOT-INF/classes
within the JAR, or worse, in a JAR within the JAR (in/BOOT-INF/lib/*.jar
). Note that in the first case, theMETA-INF/jandex.idx
is still located at the root of the JAR; only classes aren’t. In the second caseMETA-INF/jandex.idx
is still within the nested JAR.This makes the feature useless in a Spring Boot applications that rely on repackaged JARs, which I think might be the default in JHipster in particular, and maybe others.
It’s unclear whether this affects other frameworks.
See also: