Skip to content
This repository was archived by the owner on Feb 23, 2023. It is now read-only.

More advanced spring.factories key processing to address test issues #839

Closed
aclement opened this issue Jun 19, 2021 · 1 comment
Closed
Assignees
Labels
type: compatibility Native image compatibility issue
Milestone

Comments

@aclement
Copy link
Contributor

The native image creation for tests has uncovered somewhere we haven't explored. Right now we are only 'processing' (as in computing the optimal related contents for StaticSpringFactories .java and *.json files) configurations pointed to by the EnableAutoConfiguration key in spring.factories. The test infrastructure in Spring Boot is referencing all manner of extra auto configurations from keys other than that. For example:

org.springframework.boot.test.autoconfigure.web.reactive.AutoConfigureWebTestClient=\
org.springframework.boot.autoconfigure.security.oauth2.client.reactive.ReactiveOAuth2ClientAutoConfiguration,\
org.springframework.boot.autoconfigure.security.oauth2.resource.reactive.ReactiveOAuth2ResourceServerAutoConfiguration,\
org.springframework.boot.autoconfigure.security.reactive.ReactiveSecurityAutoConfiguration,\
org.springframework.boot.autoconfigure.security.reactive.ReactiveUserDetailsServiceAutoConfiguration,\
org.springframework.boot.test.autoconfigure.web.reactive.WebTestClientAutoConfiguration

There are two problems here. Firstly if we don't process it in detail when computing StaticSpringFactories, we end up registering a bunch of random configurations that in fact wouldn't pass ConditionalOnClass/etc checks. This would lead to a bloated image, but we don't get as far as a working image because the backend is not doing the computation for the *.json files because we are not processing configurations reachable by these other keys there either.

This is why the ci for spring-native is failing. The webflux-thymeleaf sample is failing because FreeMarkerAutoConfiguration cannot be found as a resource file when starting the image. Two problems here:

  • the backend didn't follow the chain from the org.springframework.boot.test.autoconfigure.web.reactive.AutoConfigureWebFlux key that points to it so it never got added as a resource entry in resource-config.json
  • it never should have made it that far anyway because it shouldn't really be in StaticSpringFactories because it wouldn't pass ConditionalOnClass checks.

Fix one is being smarter up front to allow more than just EnableAutoConfiguration keys to reference auto configurations and processing (and discarding) them when necessary.

This would mean the right ones get into StaticSpringFactories.java

Then we have to fix the backend to do the same thing, follow auto configurations that are rooted at these keys other than EnableAutoConfiguration. With these two changes, webflux-thymeleaf fully passes for me locally.

@aclement aclement self-assigned this Jun 19, 2021
@aclement aclement added the type: compatibility Native image compatibility issue label Jun 19, 2021
@aclement aclement added this to the 0.10.1 milestone Jun 19, 2021
@aclement
Copy link
Contributor Author

I've pushed a commit, let's see what the build machine makes of it. It is a little more radical than recent changes although I've tried to take care and make sure this first variant only impacts the testing situation. The commit should fix:

  • problems with FreeMarkerAutoConfiguration
  • problems with WebTestClientAutoConfiguration
  • problems with jdbc-tx related to WebEnvironment (I fixed this with a simple change that introduces hints for SpringBootTests)

Depending what happens on the build machine I will re-open this or open a follow on for next steps.

sdeleuze added a commit that referenced this issue Jun 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: compatibility Native image compatibility issue
Development

No branches or pull requests

1 participant