Это действительно зависит от вашего «поставщика кэширования» и реализации CacheManager, в частности. Начиная с абстракции кэша в Spring это просто «абстракция», она позволяет вам подключать различных поставщиков и серверные хранилища данных для поддержки кэшей, необходимых вашему приложению (т.е. как определено аннотациями кэширования Spring или, альтернативно, аннотациями JSR-107-JCache; см. href="https://docs.spring.io/spring/docs/current/spring-framework-reference/integration.html#cache-jsr-107-summary" rel="nofollow noreferrer">здесь) .
В настоящее время нет возможности отключить эту проверку инициализации (т. е. генерировать исключение) для несуществующих кешей. Лучшее, что вы можете сделать, это, подобно реализации ConcurrentMapCacheManager, лениво создать Caches. Однако это сильно зависит от реализации вашего поставщика кэширования. Очевидно, что некоторые провайдеры кэширования более сложны, чем другие, и создание Cache на лету (то есть лениво), возможно, дороже и затратнее, поэтому провайдер кэширования не поддерживает его или не рекомендует.
Тем не менее, вы можете обойти это ограничение, обернув любую реализацию CacheManager (по вашему выбору) и делегировав базовой реализации «существующую» Caches и «безопасно» обработав «несуществующую» Caches, рассматривая ее как промах кеша, просто предоставление некоторых простых реализаций оболочки основных интерфейсов Spring CacheManager и Cache.
Вот пример интеграционного тестового класса, который демонстрирует вашу текущую проблему. Обратите внимание на тест/утверждения для несуществующего Caches.
Затем, вот пример тестового класса интеграции, который демонстрирует, как эффективно отключить кэширование для несуществующего Caches (не предоставляется поставщиком кэширования). Еще раз обратите внимание на test/assertions для безопасного доступа к несуществующему Caches.
Это стало возможным благодаря делегат-оболочка для CacheManager (который упаковывает и делегирует существующему провайдеру кэширования, который в данном случае снова является просто ConcurrentMapCacheManager (см. здесь), но будет работать для любого провайдера кэширования, поддерживаемого Spring Cache Abstraction) вместе с NoOpNamedCache реализация интерфейса Spring Cache. Этот нерабочий экземпляр Cache может быть Singleton и повторно использоваться для всех несуществующих Caches, если вас не волнует имя. Но это дало бы вам степень видимости, в которой «именованные» Caches не настроены с фактическим Cache, поскольку это, скорее всего, повлияет на ваши службы (т.е. методы службы без включенного кэширования, потому что «именованный» кеш не существует ).
В любом случае, это может быть не совсем то, что вам нужно, и я бы даже предостерег вас проявлять особую осторожность, если вы запускаете это в производство, поскольку (я бы сказал) это действительно должно быстро выйти из строя из-за отсутствия Caches, но это действительно достигает того, что вы хочу.
Ясно, что это настраивается, и вы можете сделать его условным на основе имени кеша или других критериев, в том смысле, что если вам действительно все равно или вы не хотите кешировать определенные методы службы в определенных контекстах, тогда это зависит от вас и этот подход является гибким и полностью предоставляет вам этот выбор, если это необходимо.
Надеюсь, это даст вам некоторые идеи.
Спасибо за ваше объяснение. Мне просто интересно, что делает конфигурацию избыточной. Теперь я знаю, что я могу сделать.
person
John Blum
schedule
17.09.2018
