New Sample: Spring Boot 3 + Ehcache 3 XML config with Spring Bean Wiring

[mathieucarbou]

Depends on ehcache/ehcache3#3190

This sample is a PoC for an upcoming spring-boot-ehcache3 (or ehcache3-spring-boot ?) module that will automatically configure Spring Boot Caching with Ehcache / JCache (@EnableCaching), and at the same time allow spring beans to be used within the Ehcache XML configuration.

How to run this sample:

1. Requires: Java 17
2. You must first get an API key at https://freecurrencyapi.com/
3. Build: ./mvnw package
4. Run: ./target/spring-boot-ehcache-0.0.1-SNAPSHOT.jar --app.freecurrencyapi.key=<your-api-key>
5. Open your browser at http://localhost:8080/
6. Execute some currency conversion
7. Look at the logs below
8. Look at Spring Boot actuator endpoints at http://localhost:8080/actuator to see the metrics and caches and verify
   that the caching works.

[mathieucarbou]

this is a spring beans containing some @Autowire and depending on Spring injection

[mathieucarbou]

The serialiser is a spring beans containing some @Autowire and depending on Spring injection

[mathieucarbou]

This class would go in a spring-boot-ehcache module and will allow an automatic Ehcache wiring in Spring Boot.

[chrisdennis]

If we're in "Ehcache-land" at this point (or we know we're not and can avoid any more work), why not just cast the CachingProvider to a implementation specific type and pass the services that way? Then we could do things in a much safer way rather than having to pass things through a properties object?

[mathieucarbou]

We are not: here, we do exactly like the spring boot code is doing, which is creating a jsr CacheManager based on a potentially provided and customised CacheProperties, and then customise the created jsr CacheManager.

The only Ehcache related thing is setting this ehcache.service.instantiatorService for the JSR provider implementation.

Spring is providing the config URI and jsr properties. And we cannot call directly Ehcache implementation EhcacheCachingProvider.getCacheManager(uri, configuration, properties) because it would mean we have to duplicate the Ehcahe internal code to parse the configuration from a URI or provide a default one (ConfigSupplier code). And the ConfigSupplier class is not even publicly usable.

[chrisdennis]

It's not clear to me what the right sequence of delegation is here. Right now we're saying:

BeanFactory first, then, if available, the users InstantiatorService bean otherwise the DefaultInstantiatorService.

Would this be better?

The users InstantiatorService bean (if available), otherwise the beanFactory delegating to the DefaultInstantiatorService

Also, what about if the user has tried to override the instantiator service using the Ehcache dependency mechanism? Should it then be:

The users InstantiatorService bean (if available), otherwise the beanFactory delegating to the service found using the Ehcache system?

[mathieucarbou]

The proposition in the middle makes sense from a spring boot perspective:

  @Bean
  @ConditionalOnMissingBean
  public InstantiatorService instantiatorService() {
    return new SpringBootInstantiatorService();
  }

If a user provides its own InstantiatorService, it will be used (and user is then responsible of the wiring), otherwise we use the spring wired one

If a user tries to override the service in Ehcache and he uses spring boot, I guess Ehcache will complain because it will see 2 instantiator services right ? One from the user, one from spring boot. And this is OK because the user is using Ehcache in a spring boot app so he should provide his instantiator from spring as a normal configured bean.