Support registration of resource hints for classpath location patterns

[sbrannen]

Overview

Prior to 6.1 M4 we did not have a need for registering resource hints for GraalVM native image for classpath location patterns (i.e., locations containing wildcards (**, *, or ?) or using the classpath*: prefix). Rather, we only had a concrete need to support static classpath locations.

However, since the introduction of support for location patterns in @PropertySource and @TestPropertySource, we now need to be able to register resource hints for patterns such as classpath*:my/config/**/file?.properties.

The Challenge

Class-path and module-path scanning uses PathMatchingResourcePatternResolver behind the scenes. To resolve the actual resources for a location pattern, we have to use that ResourcePatternResolver which returns resource types such as FileSystemResource and UrlResource instead of ClassPathResource, and it is not possible to easily infer the "path within the classpath" for a Resource type other than ClassPathResource.

For example, if we supply classpath*:**/aot/samples/basic/test?.yaml as the location pattern to @TestPropertySource and use PathMatchingResourcePatternResolver to resolve the actual locations, we end up with filesystem-based paths such as the following.

• /Users/example/spring-framework/spring-test/bin/test/org/springframework/test/context/aot/samples/basic/test1.yaml
• /Users/example/spring-framework/spring-test/bin/test/org/springframework/test/context/aot/samples/basic/test2.yaml

Whereas, what we actually need (in order to register resource hints) are the following paths within the classpath.

• org/springframework/test/context/aot/samples/basic/test1.yaml
• org/springframework/test/context/aot/samples/basic/test2.yaml

Brainstorming

One option is to use PathMatchingResourcePatternResolver to resolve the actual locations and then infer the "path within the classpath" by implementing logic specific to each resource type (e.g., FileSystemResource and UrlResource). I spiked an implementation that supports FileSystemResource by iterating over all classpath roots for the current JVM to find a given classpath root that is the base directory for the given FileSystemResource and then extracting the "path within the classpath" by removing the base directory.

That approach could work (and does work in my local tests); however, it does not take into account JARs in the classpath, URLClassLoader inspection, JAR manifests, etc. -- features that PathMatchingResourcePatternResolver supports while resolving the resources. In addition, it requires duplication of much of the logic in PathMatchingResourcePatternResolver.

Another option would be to introduce first-class support for registering an Ant-style classpath pattern in org.springframework.aot.hint.ResourceHints that transparently converts Ant-style wildcards into an analogous regular expression.

If we don't implement first-class support for Ant-style patterns and don't want to go with the PathMatchingResourcePatternResolver option (which I am currently not in favor of due to the aforementioned drawbacks), we could introduce a utility that converts from Ant-style patterns to our simplistic "Spring resource hint patterns" (i.e., only supports *) as follows.

private String convertAntPatternToHintPattern(String pattern) {
    pattern = pattern.replace('?', '*');              // ?     --> *
    pattern = pattern.replaceAll("(\\*)+", "\\*");    // (*)+  --> *
    pattern = pattern.replaceAll("(/\\*)+", "/\\*");  // (/*)+ --> /*
    pattern = pattern.replaceAll("(/\\*/)+", "/\\*"); // /*/   --> /*
    return pattern;
}

Passing the result of that function to ResourceHints#registerPattern works in my local test. However, that results in a lossy conversion from an Ant-style pattern TO a "Spring resource hint pattern" TO a regular expression (which is what is actually used in the JSON resource configuration file for GraalVM native image). Consequently, I am not in favor of introducing this utility: I've only included it here for the sake of completeness.

Related Issues

• Support resource patterns in @PropertySource locations [SPR-16785] #21325
• Support resource patterns in @TestPropertySource locations #31055
• Prepare AOT resource hints for GraalVM changes #31340
• Log warning and skip resource hint registration for classpath location patterns #31429

⚠️ The following issues are currently blocked by this issue.

• Register resource hints for @PropertySource location patterns #31161
• Register resource hints for @TestPropertySource location patterns #31088

Deliverables

• Introduce a mechanism to support the registration of resource hints for classpath location patterns.

[bclozel]

A related topic came up during a meeting with the GraalVM team. Right now the resource configuration format in GraalVM accepts regexps, but they will restrict that in the future to only accept a subset - something like "org/springframework/test/context/aot/samples/basic/*" and "*.yaml". The actual behavior is not defined yet.

This will need to happen because the runtime will start enforcing missing reflection and resource entries as exceptions. If you didn't register for it, you will get an exception at runtime if check for that resource. Doing that with extensive regexps is not a good fit at runtime.

[sbrannen]

they will restrict that in the future to only accept a subset

Thanks for the heads-up, @bclozel. That could certainly influence our decision.

[sbrannen]

Update

The GraalVM team has merged support to "restrict the Expressivity of Patterns in resource-config.json" in PR oracle/graal#8715 for inclusion in GraalVM for JDK 23 (September 17, 2024).

• For details, see [GR-49770] Restrict the Expressivity of Patterns in resource-config.json oracle/graal#7487