When using ApplicationContextRunner condition evaluation does not use runner's class loader

[mbhave]

Test here.

[wilkinsona]

The condition is being evaluated but it's using the wrong class loader. The class loader that's used for condition evaluation is captured when the application context is constructed. Setting it after that point has no effect. To get this to work, the context needs to be created with a bean factory that has a custom bean class loader. This change does that but in a way that I don't really like. It requires the context factory in each runner to know about the need to customise the bean factory and isn't backwards compatible.

[wilkinsona]

I thought I'd found a slightly better way to solve this. A side-effect of calling setEnvironment on AnnotationConfigApplicationContext is that the condition evaluator is recreated. This provides a (hacky) way to get it to use the updated bean class loader. Unfortunately, the same is not true of the two web application contexts that the runners also support. They do not allow access to their bean factories until after they have been refreshed, at which point it's too late. Using a bean factory post-processor also does not work as it's called to late during refresh processing.

I've also noticed that my earlier attempt is more flawed than I originally thought. It's inadvertently changed the type of context that's used by the two web context runners. Changing to use the intended context types does not work as neither of them allows the bean factory to be passed as a constructor argument.

I'm starting to think that we may need a Framework change to fix this. I've yet to find a way, let alone an elegant way, to customise the class loader early enough so that it's used for condition evaluation across all the different application context implementations. It's relatively straightforward for GenericApplicationContext subclasses but, as far as I can tell, is not possible for AbstractRefreshableApplicationContext subclasses.