CAMEL-23370 fix camel.main.routes-include-pattern usage with multi-level wildcard matchers in springboot jars

[vilmosnagy]

Using classpath:**/*.xml (like any xml in any dir) was broken since probably CAMEL-21944 & #17716

Description

See CAMEL-23370; but it seems to me that multi-level include-route matchers are broken since #17716.

This worked with Camel 4.11:

camel:
  main:
    routes-include-pattern: classpath:camel/**/*.xml

and does not work with latest snapshot.

I'm not sure how to write tests for my use-case though; and not sure if it ain't broke anything, 'cause there seem to bit not much tests around this part of the codebase.

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.

• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• core/camel-support

ℹ️ Dependent modules were not tested because the total number of affected modules exceeded the threshold (50). Use the test-dependents label to force testing all dependents.

---

⚙️ View full build and test results

[Croway]

Hi @vilmosnagy thanks for the fix. You can add a test in the camel-spring-boot repository, for example, similar to the following one https://github.com/apache/camel-spring-boot/blob/4bdea8a87e75c67d0a242752264f42646ea8551b/core/camel-spring-boot/src/test/java/org/apache/camel/spring/boot/CamelXmlRoutesTest.java#L35

[vilmosnagy]

Hi @Croway, thanks for the direction!

I've added a test in my fork:
apache/camel-spring-boot@main...vilmosnagy:camel-spring-boot:vilmos/testing-wildcard-globs

My understanding is that this bug is only triggered when Camel is run via java -jar. All tests in my production project pass when run with the Maven Surefire Plugin using glob matchers, and the issue only appears when starting the application on Kubernetes.

From debugging, it seems that when running with Surefire, file.isDirectory() returns true here:
https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/scan/DefaultPackageScanResourceResolver.java#L165-L168
which causes a different code path to be executed.

The only way I was able to reproduce the faulty behavior was:

• adding a new module called test-resources-in-jar and placing the route there
• adding this module as a test-scoped dependency to the camel-spring-boot module
• running the tests via the Maven CLI (in this case, they fail)

Interestingly, my JetBrains IDE seems to use a different classloading approach and still loads these resources directly from the filesystem rather than from the JAR, so the issue does not appear there.

If you have a better idea for reproducing this, please let me know. Also, camel-observation-starter has failing tests on my machine on the main branch, so I’m not entirely sure all tests ran successfully—but as far as I can tell, my change resolves this issue.

[davsclaus]

yeah its not easy to test and the idea of building a -jar as another maven module is correct. I wonder if the test can be moved into the tests folder instead so its not in the core. And this would then require to add a new module specially for this test camel-itest-spring-boot-farjar or a name like that. Then we can add other farjar tests in the future

[vilmosnagy]

@davsclaus I almost have the test done: do you have any example on how can I set a custom camel.main.routes-include-pattern value in the camel-itest-spring-boot package, or should I create a new way for that? I have ideas, but in a hurry right now. If you don't have a ready-to-copy solution, I'll describe my idea over the weekend.

[davsclaus]

I am not sure how you run the test, though the regular unit tests for SB allow to declare custom values for its application.properties in those annotations.

But feel free to provide what you have and we can take a look to help last bit. But we dont have a release in a hurry so there is plenty of time to get this done over the following weeks

[vilmosnagy]

I hope this is the test you were thinking of: apache/camel-spring-boot#1773

At first, I tried to write a test similar to the existing ones in the camel-itest-spring-boot module. As far as I understand, they don’t use the @SpringBootTest annotation (or other Spring Boot testing features). Instead, they generate a temporary Maven project and bootstrap a Spring Boot application from the built artifacts of that project.

I wasn’t able to write a similar test for loading XML routes from another module, because the test-resources-in-jar JAR would not be accessible from the generated Maven project in that setup.

In the end, I moved my previous attempt to the tests module and added test-scoped dependencies to the camel-itest-spring-boot module. This allows running tests annotated with @SpringBootTest.

I’m not fully happy with this solution, but I don’t see a better alternative at the moment. This still applies from my previous comment:

Interestingly, my JetBrains IDE seems to use a different classloading approach and still loads these resources directly from the filesystem rather than from the JAR, so the issue does not appear there.

[Croway]

I reviewed apache/camel-spring-boot#1773 . I think that we can merge it, and have the tests merged later. Thanks for your contributions @vilmosnagy

[davsclaus]

ok