В моем
предыдущем посте я объяснил, как настроить
плагин Spring Cache, чтобы мы могли кешировать контент с учетом того, какой пользователь вошел в систему или нет. Однако этот код был написан с использованием версии 1.2.1 плагина, и если вы хотите обновить его до последней версии, которая в настоящее время является 1.3.1, то в этом коде необходимо внести некоторые изменения, чтобы это работало. В связи с этим я собираюсь объяснить, что это за изменения, поэтому эта настройка продолжает работать для вас.
В исходном примере я упомянул, что нам нужно расширить класс
MimeTypeAwareKeyGeneratorмы использовали этот класс специально, потому что нам нужно обрабатывать разные типы контента. Однако в новой версии плагина в этом классе больше не существует, теперь у нас есть класс с именем
WebContentKeyGenerator, который расширяет
DefaultKeyGenerator .
WebContentKeyGenerator является многоцелевой реализацией интерфейса KeyGenerator. Различные цели генератора ключей управляются с помощью нескольких логических свойств, все из которых по умолчанию имеют значение false. Это следующие свойства: [1]
- ajax : при значении true ключи будут отличаться в зависимости от наличия или отсутствия заголовка запроса X-Requested-With, поэтому запросы AJAX будут кэшироваться отдельно от обычных запросов. Это полезно, когда у вас есть действие, которое отображает другой контент при запросе через AJAX.
- contentType : если истинные ключи будут отличаться в зависимости от запрошенного формата контента, как определено мета-свойством format в HttpServletRequest. Это полезно, когда вы используете согласование содержимого в запросе, чтобы ответы в разных форматах кэшировались отдельно.
- requestMethod : если истинные ключи будут отличаться в зависимости от метода HTTP запроса. Это полезно для некоторых контроллеров RESTful (хотя, если разные методы запроса отображаются на разные действия, вам не нужно использовать этот механизм). Запросы GET и HEAD считаются одинаковыми для целей генерации ключей.
Так что наш новый класс генератора ключей должен выглядеть так:
public class MimeTypeAndAuthenticationAwareKeyGenerator extends WebContentKeyGenerator { @Override protected void generateKeyInternal(CacheKeyBuilder builder, ContentCacheParameters context) { super.generateKeyInternal(builder, context) def springSecurityService = ApplicationHolder.application.mainContext.getBean('springSecurityService') if (springSecurityService?.isLoggedIn()) { builder << "authUserId=${springSecurityService.principal.getId()}".toString() } } }
Как вы можете видеть, код все еще очень похож, но помимо расширения другого класса, сигнатура
метода generateKeyInternal также изменилась, вместо получения
объекта FilterContext в качестве второго параметра вам необходимо получить
объект ContentCacheParameters .
Чтобы настроить плагин для использования нашего класса, мы использовали конфигурацию Config.groovy, чтобы сообщить
SpringcacheFilter, какой генератор ключей использовать. Однако, это должно быть сделано по- другому, у вас есть два варианта:
1. Установка генератор ключей действием: Вы можете указать свой генератор ключей для конкретного действия, добавив
KeyGenerator элемент в
@Cacheableаннотация, указывающая имя bean-компонента Spring, который реализует
интерфейс KeyGenerator , что-то вроде:
@Cacheable(cache = "albumControllerCache", keyGenerator = "mySpecialKeyGenerator") def doSomething = { // … }
2. Переопределение генератора ключей по умолчанию: Вы также можете переопределить экземпляр генератора ключей по умолчанию в файле resources.groovy, который называется
springcacheDefaultKeyGenerator . Вы можете сделать что-то вроде:
springcacheDefaultKeyGenerator(MimeTypeAndAuthenticationAwareKeyGenerator) { ajax = true contentType = true }
Как вы можете видеть, у нас теперь есть разные варианты, которые позволяют нам лучше контролировать, как кэширование управляется для различных действий, что дает нам большую гибкость.
Из
http://maricel-tech.blogspot.com/2011/06/grails-spring-security-with-spring.html
[1] Взято из документации
Spring Cache Plug в документации .