Today I had a look at using the excellent groovy scripting language to create a dynamic solution for determining the keys to flush in our distributed caching setup. Since determining which keys to flush when an object is updated/created/deleted is tied to quite a complex set of rules I figured that the capability of dynamically changing those rules would be a really useful feature.

The setup
I simplified the setup for demonstration. Basically, all the work is done inside an object implementing the CacheFlushingStrategy interface.

JAVA:
  1. public interface CacheFlushingStrategy {
  2.     boolean handleObject(Object obj);
  3. }

The basic implementation of the interface uses a CacheFlushDecider to determine which keys to flush based on the changed object, which we'll implement in groovy:

JAVA:
  1. public interface CacheFlushDecider {
  2.     String[] determinKeysToFlush(Object obj);
  3. }

The groovy (using the Java syntax highlighter, haven't got one for groovy) implementation might look like this:

JAVA:
  1. package com.maasfrensch.groovy;
  2.  
  3. public class CacheFlushDeciderImpl implements CacheFlushDecider {
  4.     String[] determinKeysToFlush(Object obj) {
  5.         if(obj =~ /flush/){
  6.             return ["key1","key2","key3"]
  7.         }
  8.        
  9.         return null
  10.     }
  11. }

The spring configuration:

XML:
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3.     xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx"
  4.     xmlns:lang="http://www.springframework.org/schema/lang"
  5.     xsi:schemaLocation="
  6.        http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.0.xsd
  7.        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
  8.        http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
  9.        http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">
  10.  
  11.  
  12.     <lang:groovy id="groovyCacheFlushDecider" script-source="classpath:CacheFlushDecider.groovy" refresh-check-delay="30000"/>
  13.  
  14.     <bean id="cacheFlushingStrategy" class="com.maasfrensch.groovy.DefaultCacheFlushingStrategyImpl">
  15.         <property name="cacheFlushDecider" ref="groovyCacheFlushDecider" />
  16.     </bean>
  17. </beans>

Notice the 'refresh-check-delay' which makes spring reload the source file every 30 seconds!

Now, if you would call the CacheFlushingStrategy with a string containing the word "flush" the groovy script would return a string array containing "key1", "key2" and "key3".

So far so good... all unittests succeed!

Unexpected problems
After adding the above to the main project I ran into a couple of really nasty problems:

  • The post processor for script files (ScriptFactoryPostProcessor) doesn't run before injection of the groovy based bean into the strategy... this worked perfectly in my smaller example. I manager to 'solve' this problem by looking up the groovyCacheFlushDecider manually from the applicationContext when needed.
  • Transaction management is configured by using AOP. I'd never expected this to be a problem when using springs' dynamic scripting features... well... I was wrong! The AOP stuff in Spring 2.0 is not compatible with scripting support, which means I can not use scripting in a transactional environment... which rules out all services in our project.... which makes the scripting extension basically useless! And this thread indicates that I'm not the only one with the problem. Bummer!


    --update--
    The Jira issue related to this problem was closed, a fix should be present in Spring 2.0.3; we'll see!
    --update 2--
    I tried to isolate the problem, and discovered that I CAN use AOP in combination with scripting... so it must be something specific to the way the transaction advisor works.

Although I was initially really pleased with the scripting support in Spring I'm getting a bit frustrated by it now; wasn't scripting supposed to make stuff easier!?

I've removed the scripting support from the project for now, I'll keep you posted if I find a solution to the problems...


0 Responses to “Spring and scripting languages… don’t go together?”

  1. No Comments

Leave a Reply





About

Welcome to the weblog of Peter Maas. Here you'll find various posts related to stuff I like (like my kids and espresso) and stuff I do (like developing software).

JavaOne 2008 Pictures

_MG_8015 IMG_4606.JPG Community One Keynote high voltage wires IMG_4708.JPG boottocht Sjoerd achter de computer koe heart tarte tatin of red unions abandonned_factory trap (II) IMG_4588 sjoerd op klimrek konijn Sjoerd op zonnig bospad IMG_4572 IMG_4613.JPG Greenland alcatraz
View more photos >

Categories



Meld u aan voor PayPal en begin direct met het accepteren van creditcardbetalingen.