Use of @ConditionalOnClass in AuditAutoConfiguration is brittle

[snicoll]

While upgrading to Spring Security 7 snapshots, I've noticed that AuditAutoConfiguration had @ConditionalOnClass on a class that no longer exists. Turns out these conditions on bean methods aren't legit as they don't prevent the signature of the method to be loaded. To be effective, they must but put on a @Configuration class where the condition can backoff before the type is loaded.

Perhaps we should review these usage and add a rule to prevent that from happening?

[wilkinsona]

We discussed this today and think the two methods should move into an inner-class that's protected at the class level with @ConditionalOnClass. We'd also like to add an ArchUnit rule to try and prevent similar arrangements being added in the future.

[nosan]

What ArchRule would you like to add? As I understand it, @ConditionalOnClass(...) should not be used on @Bean methods, correct?

[snicoll]

Thanks @nosan. Yep, that's right.

[nosan]

I've prepared some changes: 3.4.x...nosan:47200

Please let me know whether this is what you had in mind or if I mixed something up

[snicoll]

@nosan that looks like a very good first step. Please open an PR and we can continue the discussion there.