#

Tuesday, July 19, 2011

Spring 3.1 & EhCache Integration

Context: How to integrate EhCache via Spring 3.1 (At the time of Writing Spring ver:3.1.0.M2)


1. Setup your library dependencies correctly

PSEUDO CONFIG : Maven config for reference and not to be copied as is :
  
    3.1.0.M2
  
  
  
 
 
  spring-maven-release
  Spring Maven Release Repository
  http://maven.springframework.org/release
 
 
  spring-maven-milestone
  Spring Maven Milestone Repository
  http://maven.springframework.org/milestone
 

      ehcache-repo
      EhCache Repository
   https://oss.sonatype.org/content/repositories/sourceforge-releases
      
          false
      
      
         true
      
     
 
    
...

    
      
    

    
      net.sf.ehcache 
      ehcache-core
      2.4.3
    


NOTE: An important point to note is that many a time an Old Spring Library or worse, a conflicting EhCache Library (from say a Hibernate) dependency will give errors. The errors will looks like "Spring <init> method failures". To avoid this, please do a mvn dependency:tree on your modules and do any <exclusions> to other versions of EhCache.


2. Define You interface (Method Caching) : We are effectively ensuring all method operations are cached to cache publishContent. Furthermore, the identifier key is based on the URI.getLocation(). The cache can be applied on the interface or an Impl. You can write a default implementation for your interface and wire it via Spring (@Component)



For brevity, we will skip details of Method Caching. There are several articles on it. Note the use of SpEL. Can be also used for doing conditional caching. For example, in the sample interface below we are interested in caching only Content that is PUBLISHED.
/**
 * An adapter to extract the content from a specified location. Piped with {@link ContentLocationResolver} this
 * can locate and extract content from any Data Source.
 * 
 * @author Arjun Dhar
 *
 */
public interface ContentExtractor { 
 /**
  * Get Content. PUBLISHED Content is cached
  * 
  * @see {@link Cacheable}
  */
 @Cacheable(key="#location.path", 
      condition="(#location!=null and #context!=null and " +
          "T(com.neurosys.pms.content.domain.Status).PUBLISH == #context.status)" , value="publishContent") {
 public String getContent(URI location, EditableContentContext context);
}


Important Note:
From http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/cache.html In proxy mode (which is the default), only external method calls coming in through the proxy are intercepted. This means that self-invocation, in effect, a method within the target object calling another method of the target object, will not lead to an actual caching at runtime even if the invoked method is marked with @Cacheable - considering using the aspectj mode in this case.


3. Define Spring Binding/Config for EhCache

  xmlns:p="http://www.springframework.org/schema/p"
  xmlns:cache="http://www.springframework.org/schema/cache"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd">

    

  
         p:config-location="classpath:com/neurosys/pms/modules/content/ehcache.xml"
      p:shared="false"
      >
     
      
     

  


4. Define the Caching configs in ehcache.xml
             xsi:noNamespaceSchemaLocation="ehcache.xsd"
             updateCheck="false" monitoring="autodetect"
             dynamicConfig="true">

  
  
  
    
  
                                
  


5. Sanity Unit test to ensure all the bindings etc are correctly setup
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={
  "classpath:*applicationContext.xml" //Assumes the Spring config is in or imported via your applicationContent.xml
 }) 
public class ContentLocateFetchTest {
 @Autowired
 private ContentExtractor contentExtractor;
 
 @Test
 public void testCache() {
  //No context status, hence it will fetch the data twice. One for each call.
  //If you put a Debug Statement in contentExtractor.getContent(), you will see it called twice for google.com
  contentExtractor.getContent(new URI("http://google.com"), null);
  contentExtractor.getContent(new URI("http://google.com"), null);
  
  EditableContentContext cntx = new EditableContentContext() {
   @Override public Authorization getAuthorization() {return null;}
   @Override public Status getStatus() {return Status.PUBLISH;}   
  };
  
  //If you put a Debug Statement in contentExtractor.getContent(), you will see it called only once for yahoo.com
  //since it detects that the context has a Status=PUBLISH and caches it.
  contentExtractor.getContent(new URI("http://yahoo.com"), cntx);
  contentExtractor.getContent(new URI("http://yahoo.com"), cntx);  
 }
}


You may also want to programatically refer to the cache to refresh or clear it etc:
 @Autowired
 @Qualifier("cacheManageName")
 private EhCacheCacheManager cacheManager; .... 
...
Cache cache = cacheManager.getCache("cahceName");
    cache.clear();
..In the above the cache name is that is supplied in <cache name="chacheName"...

- Arjun Dhar
My Company NeuroSys

Sunday, January 30, 2011

Setter Chaining : Where it breaks

This is a section dedicated to keeping notes about the places where setter chaining breaks and how to work around (people welcome to contribute):

1. org.springframework.beans.BeanUtils.copyProperties(...); fails to set fields that do not support conventional bean setter methods.

Tuesday, January 11, 2011

Setter Chaining & generics

Although the concept of setter chaining is not new, thanks to a few good men I've picked the habit. However when using Inheritance, the setter of the base class returns type of "base class". This can disrupt the "coolness" of using chaining.

For the rest I'll let the code talk about the issue & a possible solution in more detail:


package com.arjun.misc;

/**
* "Setter chaining". The issue is that it returns the object of the
* type of the class in which the setter is.
* For Inheritance concepts this means if A<--B; then B.a()
* will return A not B (exclude overriding).
* This hardly helps chaining. Using generics to solve the problem
*
* @author Arjun Dhar | www.neurosys.biz
* */

public class GenericChainingSetters {
private static class A<T extends A> {
T setA(String something) {
return (T)this;
}
}

private static class B<T extends B> extends A<T> {
T setB(String something) {
return (T)this;
}
}

private static class C<T extends C> extends B<T> {
T setC(String something) {
return (T)this;
}
}

public static void main(String[] args) {
//WORKS
B<B> b = new B();
b.setA("abc").setB("abc again?!");

//WORKS
C<C> c = new C();
c.setA("abc").setB("abc again?!").setC("Hurray!");
}
}

Only thing is that as with Generics (erasure),
one cant (can but should not logically) do something stupid like:
B<C> b = new B();


Thoughts & suggestions welcome

thanks
-Arjun

Click here to see better way using Java 8