[
https://issues.apache.org/jira/browse/CAMEL-26029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26029.
---------------------------------
Resolution: Fixed
Fixed via https://github.com/apache/camel/pull/28313 (merged to main as
77f024019797).
> Package scanning inside a JAR includes sibling packages that share the
> scanned package name as a prefix
> -------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26029
> URL: https://issues.apache.org/jira/browse/CAMEL-26029
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 4.23.0
> Reporter: Sharang Gupta
> Priority: Major
> Fix For: 4.24.0
>
>
> {{DefaultPackageScanClassResolver}} scans classes packaged in a JAR with a
> plain prefix check ({{doLoadImplementationsInJar}}:
> {{entry.startsWith(parent)}} where {{parent}} is e.g. {{com/acme/routes}}
> without a trailing slash). As a result, scanning package {{com.acme.routes}}
> also returns every class from {{com.acme.routesupport}},
> {{com.acme.routes2}}, ... when the application runs from a JAR. Scanning the
> same packages from a directory on the classpath (e.g. {{target/classes}})
> only returns {{com.acme.routes}} and its sub packages, and the sibling
> {{DefaultPackageScanResourceResolver}} already appends the {{/}} before its
> prefix check, so the JAR branch of the class resolver is the odd one out.
> Ordinary way to hit it: {{camel.main.base-package-scan=com.acme.routes}}
> (RoutesConfigurer / BaseMainSupport use
> {{PackageScanClassResolver.findImplementations(RoutesBuilder.class, ...)}})
> with a {{com.acme.routesupport}} package in the same JAR: its
> {{RoutesBuilder}} / {{@Configuration}} classes get registered too, but only
> in the packaged application, not when running from the IDE or
> {{target/classes}}.
> Reproduced with camel-support 4.23.0 (and {{main}}): a JAR with
> {{com/acme/routes/RouteA.class}}, {{com/acme/routesupport/HelperB.class}},
> {{com/acme/routes2/RouteC.class}}:
> {code}
> new DefaultPackageScanClassResolver().findImplementations(Object.class,
> "com.acme.routes")
> JAR on classpath -> [com.acme.routes.RouteA, com.acme.routes2.RouteC,
> com.acme.routesupport.HelperB]
> DIRECTORY on classpath -> [com.acme.routes.RouteA]
> {code}
> The {{PackageScanClassResolver#findImplementations}} javadoc documents the
> contract as "package names to scan (including subpackages)". The
> {{startsWith}} dates back to the original camel-core implementation and no
> later change (CAMEL-21944, CAMEL-22257 touched the file) looked at it; no
> existing test has a sibling package in its fixture JAR.
> Fix: match {{parent + "/"}} (or the whole JAR for the root package) in
> {{doLoadImplementationsInJar}}, mirroring the directory branch and the
> resource resolver, plus a unit test in camel-support that builds a fixture
> JAR with a sibling package, and an upgrade-guide note (4.24) since a packaged
> application that accidentally relied on the sibling match will no longer
> discover those classes. PR to follow.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
