In our efforts to get rid of bean overriding in the core framework, I am trying to migrate tests that use bean overriding.

JCacheCustomInterceptorTests is one of those, it exposes a JCacheInterceptor bean that should replace the infrastructure one that @EnableCaching produces. Now I've done the full exercise, I came to the conclusion that the test does not longer reproduce a valid use case (i.e. if a user tries to customize the infratructure, it will face the same problem).

Things I've tried:

  • Remove @EnableCaching and then import the individual components with an override for the one I want to customize: the infrastructure relies on @EnableCaching to be present and fail hard if it's not present.
  • I've removed that locally and now that's AutoProxyRegistrar that doesn't do anything (silently) as it can't find an @Enable-like annotation that provides the mode and proxyTargetClass attributes.
  • Reverting all of that and using a BeanPostProcessor to replace the interceptor bean. It's extra hard as the BPP needs to be configured before the caching infrastructure is registered.

I've managed to make it work by calling addBeanPostProcessor before registering the configuration class that enables caching.

It would be interesting to see how far we want to go with this. If we test this, then it must be possible for a user to have a valid configuration arrangement that does a similar thing.

Comment From: snicoll

I actually implemented something in #31288. Anything that's more involved would require spring-test anyway and I am sure we'll collect such feedback down the road.

Comment From: douxiaofeng99

Does the task delayed? In my work, i need intercept the put and evict action to send redis message.

Comment From: snicoll

You’re asking this on the wrong channel. Please ask usage questions on Stackoverlow. This was mostly internal.