My #Cacheable with Spring and ehcache doesn't work, no datas are put on the cache.
When the application calls the cacheable method getFolProfile, the database is always call rather than the cache.
Can you, please, say me what is wrong in my code.
My root-context.xml:
<cache:annotation-driven proxy-target-class="true"/>
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:configLocation="classpath:/cache/ehcache.xml" />
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager" p:cacheManager-ref="ehcache"/>
My Service :
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
#Service
public class FolManager {
#Autowired
FolDao folDao;
#Cacheable(value = "oneCache", key = "#email")
public FolProfileForm getFolProfile(String email) {
return folDao.retrieveByLogin(email);
}
}
My ehcache.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">
<diskStore path="c:/tmp" />
<defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="120"
timeToLiveSeconds="120" overflowToDisk="true" diskSpoolBufferSizeMB="30" maxElementsOnDisk="10000000"
diskPersistent="false" diskExpiryThreadIntervalSeconds="120" memoryStoreEvictionPolicy="LRU" />
<cache name="oneCache" maxElementsInMemory="100000" maxElementsOnDisk="10000000" eternal="true" diskPersistent="true"
overflowToDisk="true" diskSpoolBufferSizeMB="20" memoryStoreEvictionPolicy="LFU" />
</ehcache>
Thanks for your help
Michel
It looks like you're defining caching in the service layer. At http://docs.spring.io/spring/docs/current/spring-framework-reference/html/cache.html, it is specifically noted as follows:
Note
<cache:annotation-driven/> only looks for #Cacheable/#CacheEvict on
beans in the same application context it is defined in. This means
that, if you put <cache:annotation-driven/> in a WebApplicationContext
for a DispatcherServlet, it only checks for #Cacheable/#CacheEvict
beans in your controllers, and not your services. See Section 16.2,
“The DispatcherServlet” for more information.
Add this
<cache:annotation-driven cache-manager="cacheManager" />
You have to tell Spring where cache-manager is.
When proxy-target-class attribute is set to true, class-based proxies are created. CGLIB will be used to create the proxy for a given target object. Make sur that you have CGLIB in your dependencies.
If you have the choice, prefer JDK dynamic proxies by setting proxy-target-class attribute to false and by implementing at least one interface on your class.
Please check your ehCache logs for exceptions like the following:
java.io.NotSerializableException: com.googlecode.ehcache.annotations.RefreshableCacheEntry
You use disk persistent cache (diskPersistent=true), so you have to check that your FolProfileForm object is Serializable.
From the ehCache documentation:
Only data that is Serializable can be placed in the DiskStore. Writes to and from the disk use ObjectInputStream and the Java serialization mechanism. Any non-serializable data overflowing to the disk store is removed and a NotSerializableException is thrown.
It could be the case that your data aren't placed to your cache (filesystem), so it tries to get it from the method invocation again and again.
You can use memory store cache where you can save even not serializable data.
Related
I found some code in my project.By seeing that i am confused how it scanning the package.we are not mentioning aspect package com.abc.b any where.I have few question
Why aop:aspectj-autoproxy is commentout in xml file?
why is used ?
How com.abc.b package is scanned by spring or there is no need of it or It has link from 'factory-method="aspectOf"'
serviceContext.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:cxf="http://cxf.apache.org/core"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd" default-lazy-init="true">
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
<!-- <aop:aspectj-autoproxy /> -->
<!-- Enable message logging using the CXF logging feature -->
<cxf:bus>
<!-- <cxf:features>
<cxf:logging/>
</cxf:features> -->
<cxf:inFaultInterceptors>
<bean class="com.flipswap.interceptor.cxf.SafeLoggingInFaultInterceptor"/>
</cxf:inFaultInterceptors>
</cxf:bus>
<context:component-scan base-package="com.abc.service.impl,">
<context:exclude-filter type="annotation" expression="org.aspectj.lang.annotation.Aspect"/>
</context:component-scan>
<bean id="eSSyncAspect" class="com.abc.b.ES" factory-method="aspectOf"/>
.
.
.
ES.java
package com.abc.b;
#Aspect
public class ES{
// some code
}
Unless you specify a custom instantiation model, aspects are by default singletons. That means - in case your code is properly woven -, that you can access the singleton instance of the aspect with AspectName.aspectOf().
In order for your classes to be woven by the AspectJ weaver, you need to either use compile-time/build-time weaving or load-time weaving.
In your spring configuration you are telling Spring to configure your aspect as a spring bean by telling how to access the singleton instance (through the static 'factory' method aspectOf). Spring will do the usual configuration (autowiring and any configured post-processors) on the singleton aspect instance.
aop:aspectj-autoproxy is commented out in your configuration because that would conflict with native aspectj support, as it would enable Spring AOP's dynamic proxy based AOP solution, which is very limited compared to native aspectj, and has a different mechanism to configure aspect beans than the one used in your configuration, namely through the static factory method AspectName.aspectOf().
In most cases, AspectJ aspects are singletons, with one instance per class loader. This single instance is responsible for advising multiple object instances.
A Spring IoC container cannot instantiate an aspect, as aspects don't have callable constructors. But it can obtain a reference to an aspect using the static aspectOf() method that AspectJ defines for all aspects, and it can inject dependencies into that aspect.
7.2.1.1. Example
Consider a security aspect, which depends on a security manager. This aspects applies to all changes in the value of the balance instance variable in the Account class. (We couldn't do this in the same way using Spring AOP.)
The AspectJ code for the aspect (one of the Spring/AspectJ samples), is shown below. Note that the dependency on the SecurityManager interface is expressed in a JavaBean property:
public aspect BalanceChangeSecurityAspect {
private SecurityManager securityManager;
public void setSecurityManager(SecurityManager securityManager) {
this.securityManager = securityManager;
}
private pointcut balanceChanged() :
set(int Account.balance);
before() : balanceChanged() {
this.securityManager.checkAuthorizedToModify();
}
We configure this aspect in the same way as an ordinary class. Note that the way in which we set the property reference is identical. Note that we must use the factory-method attribute to specify that we want the aspect "created" using the aspectOf() static method. In fact, this is locating, rather than, creating, the aspect, but the Spring container doesn't care:
<bean id="securityAspect"
class="org.springframework.samples.aspectj.bank.BalanceChangeSecurityAspect"
factory-method="aspectOf">
<property name="securityManager" ref="securityManager"/>
</bean>We don't need to do anything in Spring configuration to target this aspect. It contains the pointcut information in AspectJ code that controls where it applies. Thus it can apply even to objects not managed by the Spring IoC container.
I am trying to setup a bootstrapcacheloader which will query the database and populate the cache. Here I am using ehcache integrated with spring. But the problem is that I am not able to get the dependencies wired into my cacheloader implementation. The #Autowired,#Resource,#Configurable none of them seem to work. Quite obviously the cacheloader instantiation is not done by Spring container , but is there a way I can inject a spring created cacheloader instance into the cachemanager and bootstrap it?
My implementation details below.
ehcache.xml
<cache name="MyCache"
maxElementsInMemory="100000"
eternal="false"
overflowToDisk="false"
timeToLiveSeconds="500">
<!-- <pinning store="localMemory"/> -->
<bootstrapCacheLoaderFactory class="net.tristargroup.claims.helper.ClaimsCacheLoaderFactory" properties="bootstrapAsynchronously=true"/>
<cacheEventListenerFactory class="net.tristargroup.claims.helper.TristarCacheEventListenerFactory" listenFor="all"/>
</cache>
Spring Context xml
<cache:annotation-driven/>
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager">
<property name="cacheManager"><ref local="ehcache"/></property>
</bean>
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" depends-on="cacheLoader">
<property name="configLocation" value="classpath:ehcache.xml"/>
</bean>
Cache loader class
#Configurable
public class ClaimsCacheLoaderFactory extends BootstrapCacheLoaderFactory{
#Resource
CacheManager cacheManager;
.
.
.
#Override
public BootstrapCacheLoader createBootstrapCacheLoader(Properties arg0) {
System.out.println("Create cache loader method . Cache manager is ->"+cacheManager);
BootstrapCacheLoader cacheLoader = new ClaimsCacheLoader();
return cacheLoader;
}
The cacheManager instance is always null here even if I specify it as an Autowired attribute.
The problem is present even in the cache event listeners.
Someone please help me on this.
If the cacheManager is null, Tthat means you haven't made the bean available to your package. Add a #ComponentScan("yourpackage") in the same place you defined your bean and add #Component where you want to use your cacheManager.
This is old, but i hope it helps someone else.
For WebApplicationContext, should I put #Transactional annotations in the controller or in services? The Spring docs have me a bit confused.
Here is my web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>Alpha v0.02</display-name>
<servlet>
<servlet-name>spring</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>*.json</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
Here is my application-context.xml defining a spring dispatcher servlet:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc.xsd">
<context:annotation-config />
<mvc:annotation-driven />
<tx:annotation-driven />
<context:component-scan base-package="com.visitrend" />
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix" value="/WEB-INF/jsp/"/>
<property name="suffix" value=".jsp"/>
</bean>
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass" value="org.postgresql.Driver" />
<property name="jdbcUrl" value="jdbc:postgresql://localhost:5432/postgres" />
<property name="user" value="someuser" />
<property name="password" value="somepasswd" />
</bean>
<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="configLocation" value="classpath:test.hibernate.cfg.xml" />
</bean>
<bean id="transactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">
<property name="dataSource" ref="dataSource" />
<property name="sessionFactory" ref="sessionFactory" />
</bean>
</beans>
Here's a service interface:
public interface LayerService {
public void createLayer(Integer layerListID, Layer layer);
}
Here's a service implementation:
#Service
public class LayerServiceImpl implements LayerService {
#Autowired
public LayerDAO layerDAO;
#Transactional
#Override
public void createLayer(Integer layerListID, Layer layer) {
layerDAO.createLayer(layerListID, layer);
}
}
And here's my controller:
#Controller
public class MainController {
#Autowired
private LayerService layerService;
#RequestMapping(value = "/addLayer.json", method = RequestMethod.POST)
public #ResponseBody
LayerListSetGroup addLayer(#RequestBody JSONLayerFactory request) {
layerService.createLayer(request.getListId(), request.buildLayer());
return layerService.readLayerListSetGroup(llsgID);
}
}
The Spring documentation has me a bit confused. It seems to indicate that using a WebApplicationContext means only controllers will be investigated for #Transactional annotations and not services. Meanwhile I see tons of recommendations to make services transactional and not controllers. I'm thinking that using <context:component-scan base-package="com..." /> in our spring-servlet.xml above so that it includes the services packages means the services are part of the context, and therefore will be "investigated" for transactional annotations. Is this accurate?
Here's the Spring documentation blurb that got me confused:
#EnableTransactionManagement and only looks
for #Transactional on beans in the same application context they are
defined in. This means that, if you put annotation driven
configuration in a WebApplicationContext for a DispatcherServlet, it
only checks for #Transactional beans in your controllers, and not your
services.
Further, is there any performance implications or "badness" if I define a controller method as transactional, and it calls a transactional method in a another class? My hunch is no, based on the documentation, but would love validation on that.
There is no requirement for whether the #Transactional annotation should go on a Controller or on a Service, but typically it would go on a Service that would perform the logic for one request that logically should be performed within one ACID transaction.
In a typical Spring MVC application, you would have, minimally, two contexts: the application context and the servlet context. A context is a sort of configuration. The application context holds the configuration that is relevant for your entire application, whereas the servlet context holds configuration relevant only to your servlets. As such, the servlet context is a child of the application context and can reference any entity in the application context. The reverse is not true.
In your quote,
#EnableTransactionManagement and only looks for #Transactional on beans in the same application context they are defined in. This means that, if you put annotation driven configuration in a WebApplicationContext for a DispatcherServlet, it only checks for #Transactional beans in your controllers, and not your services.
#EnableTransactionManagement looks for #Transactional in beans in packages declared in the #ComponentScan annotation but only in the context (#Configuration) they are defined in. So If you have a WebApplicationContext for your DispatcherServlet (this is a servlet context), then #EnableTransactionManagement will look for #Transactional in classes you told it to component scan in that context (#Configuration class).
#Configuration
#EnableTransactionManagement
#ComponentScan(basePackages = "my.servlet.package")
public class ServletContextConfiguration {
// this will only find #Transactional annotations on classes in my.servlet.package package
}
Since your #Service classes are part of the Application context, if you want to make those transactional, then you need to annotate your #Configuration class for the Application Context with #EnableTransactionManagement.
#Configuration
#EnableTransactionManagement
#ComponentScan(basePackages = "my.package.services")
public class ApplicationContextConfiguration {
// now this will scan your my.package.services package for #Transactional
}
Use your Application Context configuration with a ContextLoaderListener and your Servlet Context configuration when instantiating your DispatcherServlet. (See the javadoc for a full java based config, instead of xml, if you aren't doing it already.)
Addendum: #EnableTransactionManagement has the same behavior as <tx:annotation-driven /> in a java configuration. Check here for using ContextLoaderListener with XML.
The Service is the best place for putting transactional demarcations. The service should hold the detail-level use case behavior for a user interaction, meaning stuff that would logically go together in a transaction. Also that way a separation is maintained between web application glue code and business logic.
There are a lot of CRUD applications that don't have any significant business logic, for them having a service layer that just passes stuff through between the controllers and data access objects is not useful. In those cases you could get away with putting the transaction annotation on the data access objects.
Putting the transactional annotation on the controller can cause problems, see [the Spring MVC documentation][1], 17.3.2:
A common pitfall when working with annotated controller classes
happens when applying functionality that requires creating a proxy for
the controller object (e.g. #Transactional methods). Usually you will
introduce an interface for the controller in order to use JDK dynamic
proxies. To make this work you must move the #RequestMapping
annotations, as well as any other type and method-level annotations
(e.g. #ModelAttribute, #InitBinder) to the interface as well as the
mapping mechanism can only "see" the interface exposed by the proxy.
Alternatively, you could activate proxy-target-class="true" in the
configuration for the functionality applied to the controller (in our
transaction scenario in ). Doing so indicates
that CGLIB-based subclass proxies should be used instead of
interface-based JDK proxies. For more information on various proxying
mechanisms see Section 9.6, “Proxying mechanisms”.
The transaction propagation behaviors that you set up on the attributes decide what happens when a transactional method calls another transactional method. You can configure it so that the method called uses the same transaction, or so that it always uses a new transaction.
By having multiple calls to your service in the example code you're defeating the transactional purpose of the service. The different calls to your service will execute in different transactions if you put the transactional annotations on the service.
Sometimes it is very convenient to have #Transactional controller methods, especially when performing trivial operations using Hibernate. To enable this using XML configuration, add this to your dispatch-servlet.xml:
<beans ...
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="...
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-3.2.xsd">
<tx:annotation-driven transaction-manager="transactionManager"
proxy-target-class="true" />
..
</beans>
The purpose of proxy-target-class is to use the CGLIB proxies which are required for AOP on controllers to work. If you don't add this, you'll get an error when starting up. Also, if you have any final methods in your controllers, note that they cannot be proxied (in particular, made transactional), and you will also get a warning from CGLIB for each of these methods, when starting up.
Im new to embedded databases but I got it running at least. What confuses me is that my data is not saved between runs. I mean wouldn't that be nice for testing? I don't wanna add data to my database every time i run the application
So I searched for a way to do this and I found that I shall configure a hibernate connection URL which I tried like this
props.put("hibernate.connection.url", "jdbc:h2:~/test");
in my HibernateConfiguration.java. Without success though, no errors but also nothing saved, and I did not find that test file that should be created from that URL. (Running windows and checked my user folder)
I also saw that its possible to do like this
<jdbc:embedded-database id="dataSource" type="H2">
<jdbc:script location="classpath:db-schema.sql"/>
<jdbc:script location="classpath:db-test-data.sql"/>
</jdbc:embedded-database>
And execute the scripts every time i run the application, but the thing is that I want hibernate to handle all the creating of tables etc.
How is this normally done?
I searched for some hours now but haven't still got it.
Ps. if it's needed i'll post all my configs.
Edit:
Updated my question to contain focus on one question and included my configs.
HibernateConfiguration.java
package com.courseinfo.project;
import java.util.Properties;
import javax.sql.DataSource;
import org.hibernate.dialect.H2Dialect;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.orm.hibernate3.HibernateTransactionManager;
import org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean;
import com.courseinfo.project.model.Course;
#Configuration
public class HibernateConfiguration {
#Value("#{dataSource}")
private DataSource dataSource;
#Bean
public AnnotationSessionFactoryBean sessionFactoryBean() {
Properties props = new Properties();
props.put("hibernate.dialect", H2Dialect.class.getName());
props.put("hibernate.format_sql", "true");
props.put("hibernate.connection.url", "jdbc:h2:~/test");
AnnotationSessionFactoryBean bean = new AnnotationSessionFactoryBean();
bean.setAnnotatedClasses(new Class[]{Course.class});
bean.setHibernateProperties(props);
bean.setDataSource(this.dataSource);
bean.setSchemaUpdate(true);
return bean;
}
#Bean
public HibernateTransactionManager transactionManager() {
return new HibernateTransactionManager( sessionFactoryBean().getObject() );
}
}
servlet-context.xml where i only added the embedded database tag.
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/mvc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:jdbc="http://www.springframework.org/schema/jdbc"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/jdbc
http://www.springframework.org/schema/jdbc/spring-jdbc-3.0.xsd"
default-lazy-init="true">
<!-- DispatcherServlet Context: defines this servlet's request-processing infrastructure -->
<!-- Enables the Spring MVC #Controller programming model -->
<annotation-driven />
<!-- Handles HTTP GET requests for /resources/** by efficiently serving up static resources in the ${webappRoot}/resources directory -->
<resources mapping="/resources/**" location="/resources/" />
<!-- Resolves views selected for rendering by #Controllers to .jsp resources in the /WEB-INF/views directory -->
<beans:bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<beans:property name="prefix" value="/WEB-INF/views/" />
<beans:property name="suffix" value=".jsp" />
</beans:bean>
<context:component-scan base-package="com.courseinfo.project" />
<jdbc:embedded-database id="dataSource" type="H2"/>
</beans:beans>
There of course also a pom where i got all dependencies but i don't think that is necessary.
I'm creating a object (Course.java) and saving that to the db, that's fine and i can load it again. But when I change my code and the application is reloaded the object doesn't exist anymore.
Edit2: I'm adding data like this.
Binding a session factory.
#Autowired
private SessionFactory sessionFactory;
Adding a my Course object to the database like this.
Course course = new Course();
course.setCourseId("IDA512");
Session s = sessionFactory.openSession();
s.saveOrUpdate(course);
s.flush();
s.clear();
Course course2 = (Course) s.get(Course.class, "IDA511");
s.close();
This works fine and i can get that course.
However, when I run the application next time there is no course with id IDA511 and i getting a null pointer exception. Does this mean that the course is only saved in the session maybe? hum
Since you are running your application on Windows, perhaps the home directory is not found using the tilde '~' operator.
Try giving your hibernate.connection.url property an absolute path eg. "C:\test" and check in that folder when you run the application to see if H2 creates a file for you.
For saving h2 in user directory as a file you can use
jdbc:h2:file:~/rmdb;AUTO_SERVER=TRUE;
and if you application not running, you can connect to it for example from intellij IDEA db util.
I have upgraded my application to Spring 3.1 and all the jars have been adequately updated. But when I try to use #Cacheable for a method in one of my controllers, URL mapping for all the methods of that controller breaks. On checking the log files I found that the URL mapping for all the methods of that controller were never detected. I am pretty sure that my cache configurations are fine.
Can anyone give me some clue as what I might be doing wrong.
ehcache.xml
<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
<defaultCache
eternal="false"
maxElementsInMemory="2"
overflowToDisk="false"
diskPersistent="false"
timeToLiveSeconds="300"
memoryStoreEvictionPolicy="LRU" />
<cache name="Backlog"
eternal="false"
maxElementsInMemory="2"
overflowToDisk="false"
diskPersistent="false"
timeToLiveSeconds="300"
memoryStoreEvictionPolicy="LRU" />
</ehcache>
configuration:
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager">
<property name="cacheManager">
<ref bean="ehcache" />
</property>
</bean>
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:configLocation="/WEB-INF/spring-configuration/ehcache.xml" />
code snippet:
#RequestMapping("/*/backlog")
#Cacheable(value = "Backlog")
public ModelAndView getBackLog(){
//sth here
}
Thanks for the help.
Whilst #mana has explained how to fix this, this is why adding #Cacheable breaks your code. A recent blog post explains this in more detail and is well worth a read.
By default Spring creates JDK dynamic proxies to achieve the caching behaviour, this requires that the class being proxied implements an interface which declares all the methods you wish to expose on your #Cacheable class. It is worth noting that you don't have to implement any interfaces if you configure Spring to use CGLIB based proxies.
You haven't supplied any specific errors but often you get a method not found exception in this scenario. Spring tries to invoke the getBackLog() method on the proxy and there isn't one.
You shouldn't cache the controller method itself but the resource hungry method that will be called to create the backlog. Have a look at this similar question. What #Cachable does is to create a key value map for your function parameters and the related return value. In your case this would be a ModelAndView object.
If you really need server side web page caching maybe use this Apache Cache Module.
you should be injecting your service class into the controller and caching the methods on the service class