Попробовав все предложения от @Adeel и @Matthias Schmidt, я заметил, что у меня все еще была та же проблема. Сценарий не добавлял class="active"
или class='active'
вместо этого, он добавлял class
, но когда вы изменили его на другое, он добавил. Поэтому я переопределил класс active
на mynewactive
, и он согласился добавить class="mynewactive"
Предположим, вы пишете следующий класс с @CachePut
,
public class FooBean implements Foo{
@CachePut
public String doSomething(){
}
}
. Spring back scene создаст прокси-сервер AOP, который обернет ваш класс так, что он сможет применять некоторые кеширующие магические коды до или после вызова фактического @CachePut
метод. Вы можете думать, что прокси-сервер AOP выглядит следующим образом:
public class FooBeanProxy implements Foo{
private FooBean fooBean;
public String doSomething(){
//Maybe there are some caching magic codes here....
fooBean.doSomething()
//Maybe there are other caching magic codes here........
}
}
Если я переместу этот метод в какой-нибудь другой файл реализации сервиса и вызову этого метода будет работать кэширование.
blockquote>Предположим, вы делаете следующее для вызова метода
@CachePut
:@Component public class App { //FooBeanProxy actually injected HERE @Autowired private Foo foo; public void startDoing(){ foo.doSomething(); } }
То, что Spring вводит для вас, это
FooBeanProxy
, но не ваш FooBean. Итак, когда вы вызываете этот метод@CachePut
, магические коды кэширования будут работать так же, как вы вызываетеFooBeanProxy
Скажем, я вызываю метод в том же классе обслуживания, который имеет аннотацию @CachePut в Это. Это не кэшируется.
blockquote>Это означает, что это само-вызов. Вы вызываете эту ссылку, которая является вашим
FooBean
экземпляром, но уже не темFooBeanProxy
. Таким образом, эта магия кэширования никогда не будет выполнена, и, следовательно, результат не будет кэширован.На самом деле то, о чем я говорю выше, уже упоминалось в документах . Если вы все еще хотите, чтобы действие
@CachePut
действовало в случае самовозбуждения, вы можете использовать ужасное и безобразное решениеAopContext.currentProxy()
, упомянутое в документах , или использоватьAspectJ
.