I am spiking on a few ideas around org.junit.jupiter.api.extension.ParameterResolver that requires access to the ApplicationContext. Since Spring Framework has support for @Autowired, I thought that looking at the code would help me apply the same pattern in my own implementation.

As far as I understand, the retrieval of the context has no public API. If that is correct, I'd like that a ParameterResolver implementation could get hold of the ApplicationContext based on an ExtensionContext.

Comment From: sbrannen

I'd like that a ParameterResolver implementation could get hold of the ApplicationContext based on an ExtensionContext.

This is already possible via SpringExtension.getApplicationContext(ExtensionContext).

In light of that, I am closing this issue.

However, if you need something other than that, please post back here with additional details.

Comment From: snicoll

Yes, I do.

My use case is that I'd like to register a ParameterResolver that sources its content from the ApplicationContext (hence my question). Given that SpringExtension is providing this integration, I was hoping I could register additional resolver implementations, perhaps with a dedicated contract that's more framework oriented.

I know I can use ExtendWith but that looks wrong given we already have an extension that takes care of boostraping and handling the ApplicationContext used by the test for us. With the modularization effort, we may have such implementation located where they make sense. Being able to register them using spring.factories or equivalent would be an option worth investigating.

Comment From: snicoll

I've started some rough hacking in a branch based on me trying to handle this in Spring Boot. A few things to consider:

  • SpringExtension is really the one that can provide you the proper ApplicationContext due to #35697. However, there might still be a benefit in moving the implementation that loops over all the implementations and do the call for other integrations that do not use SpringExtension but deal with an application context in a simpler form. DockerComposeTestExtension is an example of that.
  • SpringParameterResolver is very similar to ParameterResolver. I've tried to extend it with default implementations but that doesn't really bring any value, except the explicit link. Also, the default method is retrieving the ApplicationContext without the additional logic of the previous point.
  • The loading of the resolvers does not use a specific ClassLoader - that isn't great and it should have one but I didn't know where to source it from.

I am happy to continue based on feedback, and make sure it integrates as expected.