organic thoughts

I have been playing with Grails for a couple months now. It made me realize the power of (G)Rails approach, mainly "... get things done ... " I have used ASP Dot Net, at least 3 Java Web Frameworks, ColdFusion (not to mention Perl), I must say Grails is by far the most enjoyable.

Why all the buzz about Grails? Well, after you understand Grails and its paradigm, In about , hmmm, 7 minutes you can have a simple, fully-functional, web application. Grails' intuitive MVC mechanism and data access objects do most of the tedious, mind-numbing boiler plate infrastructural crap you usually have to do in other Java frameworks. You concentrate on what you know "... your business logic ..."

Grails (http://grails.codehaus.org/) is based on Groovy, Hibernate, Spring and have a well-defined Plug-In architecture. Now, you are probably thinking "... I don't want to learn these technologies ...." The cool thing is, you don't have to! You never see Spring nor Hibernate (unless you want to) Grails does an excellent job of shielding its users from the low-level infrastructural crap. O, yeah, hmmm, grails generates a WAR file that you can drop on any web container. Nothing special is needed!

So, I say this length intro to Grails to get to this: if you are a consultant, own a small operation, or the guy looking to develop the next social site, Grails maybe for you. As a startup, you know the name of the game is to get things done... Well, Grails lets you get things done... and you can actually get things done fast and the right way (did I mention that you get all the benefits of a full JEE environment without the fuss).

After a few hours of development, my next project is so far along that it feels unfair... yes... it feels unfair. It feels as if I should have more code to write... or more design decisions to make, or more academic bs that I should be concerning myself with (pattern this pattern that)... Instead, I actually have a product, something I can play with, make changes to, and derive motivation from.

Grails is all about agility... Grails bring dynamics to not only your code, but also the way you develop by giving you the ability to change make changes in mid-development with minimal impact to your level of efforts. Give it a try! I have!

So, I have been getting some feedbacks regarding Broadway after I first announced it. So, now it's time to delve into how you can use Groovy, Spring, and Broadway to create monitors. Using these technologies along with the Broadway API, you can build monitors that evaluate a given expression (default is Groovy) and execute a specified action when that expression returns the desired value (true or false). In this write up, I will show how to use Groovy, Spring, and Broadway to observe two directories and keep them synchronize. This is a trivial example, however it shows how Broadway can be integrated with Spring and Groovy to build powerful monitors (see Google Doc).

Directory Synchronizer [Google Doc]
Broadway was designed as component-based API and therefore it plays really well with the Spring component container. As the name implies, we will setup Broadway to monitor two directories (one primary and a secondary). The monitor will keep the secondary directory synchronized with the primary.

How Does It Work?
A monitor component will observe two directories directory for size differences. When the sizes of the two directories differ, files from the primary are copied to the secondary automatically. This can be easily accomplished using Broadway and Spring. The only required piece of code is the logic for the Action component. The action will be executed when the monitor detects the condition (in this case, directory sizes differ). As we will see, the logic for the Action can be captured in Groovy Beans (POGO's) wired in within Spring.

NOTE: this is by no mean meant to be a robust directory synchronizer, you are welcome to explore ways to make this more robust (i.e caching, thread safety, two-way synchronization, etc).

An Observed Resource
To make it easier to observe the directories, we will create a component that represents the directory structure being observed. This class provides a facade to the a file system and expose specific states to be observed. This sort of domain-specific observed components are not required. However, they can expose richer set of data to be observed by your monitors. NOTE: this observed directory class can be integrated using Groovy as well.


// Java code for ObservedDirectory
public class ObservedDirectory {
private String root;

public String getRoot() {
return root;
}

public void setDirectoryName(String root) {
this.root = root;
}
public String getDirectoryName(){
return root;
}

public boolean isEmpty(){
long size = org.apache.commons.io.FileUtils.sizeOfDirectory(new File(getDirectoryName()));
return (size > 0) ? false : true;
}

public long getDirectorySize(){
return FileUtils.sizeOfDirectory(new File(getDirectoryName()));
}

}

Using Spring's Dynamic Language Support
Spring's Dynamic Language support feature was introduced in starting with version 2.0. where you can wire a Groovy (JRuby or BeanShell) beans into a Spring context as if they are regular Java POJO's. This implies that you can inject values into your Groovy bean and wire with other beans in Spring context. If you want to learn more about Spring's Dyanamin Language Support, go to Spring Dyanamic Language Support online documentation.

Spring must be configured properly to use the dynamic language support. You must have the proper XML schema declarations or your bean will not be mounted properly in the Spring context.

<?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:lang="http://www.springframework.org/schema/lang" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.0.xsd"> ... </beans>

[See the full Spring Config File ]

Now, we are ready to wire the remainder for the Broadway components to create the directory synchronizer.

Wiring Broadway Components
Since Broadway components follow the JavaBean notation, it's easy to wire them together in Spring. To build the directory synchronizer with Broadway, we will wire the Observed Directory component, the Monitor component, and an Action component.
Wire Observed Directory
In the Spring configuration file, we have two observed directory components wired. The primary directory is ./dir1 and the secondary directory is ./dir2. When the size of observed directory one differ from that observed directory 2, the Action component will execute its script to syncrhonize the two directories.

<!-- ====================== Observed Resources ======================= -->
<bean id="firstDir" class="org.broadway.demo.spring.ObservedDirectory"> <property name="directoryName" value="./dir1" /> </bean> <bean id="secondDir" class="org.broadway.demo.spring.ObservedDirectory"> <property name="directoryName" value="./dir2" /> </bean>

Wiring the Monitor
The Monitor component observes state changes that is expressed by the "monitorExpression" property below. Here, we can see how we can use Groovy as an expression language to define when to take action based on the observed condition.

<!-- ======================= Monitor Setup ========================== -->
<bean id="monitor" class="org.broadway.monitor.BeanMonitor"> <property name="monitorExpression"> <value><![CDATA[context.resources.firstDir.directorySize != context.resources.secondDir.directorySize]]></value> </property> <property name="action" ref="action"/> <property name="resourceCollector"> <bean class="org.broadway.monitor.MappedResourceCollector"> <property name="resources"> <map> <entry key="firstDir" value-ref="firstDir" /> <entry key="secondDir" value-ref="secondDir" /> </map> </property> </bean> </property> </bean>
The monitor sets up three main properties 1) The monitoring expression using Groovy as an expression language 2)A reference to the action component (see below) 3) the collection of the observed resources (stored in a map).

Wiring the Action
The Action component is wired into Spring using Spring <lang:groovy> tag. This tag facilitates the integration of Groovy objects into the Spring context and provides several other settings (such as refresh, etc). Here, we are using the tag to point to script file located on the class path.

<lang:groovy id="action" script-source="classpath:scripts/SyncAction.groovy"/>


The Groovy Action Class
The Groovy Action class implements the Action interface (from Broadway API) directly to carry out the logic for the synchronizer. If you don't care about the Spring dependency, this is a better option then using the ScritpedAction component provided by Broadway (see below). However, you need to do some tedious class casting to get to the values in the context object. Here is what the Groovy Action class looks like:

class SyncAction implements Action{
public Object execute(Context ctx){
HashMap resources = (HashMap)ctx.getValue(MonitorConstants.MonitorKeys.RESOURCE_COLLECTION);

String dirPath1 = resources["firstDir"].directoryName;
String dirPath2 = resources["secondDir"].directoryName;

File dir1 = new File(dirPath1);
dir1.eachFile {origFile ->
String origFileName = origFile.name;

File destFile = new File(dirPath2+ File.separator + origFileName);

if(!destFile.exists() || (destFile.lastModified() <>
print "Synching file File $origFile.name ...\n";
def fis = origFile.newInputStream();
new FileOutputStream(destFile).withStream {fos ->
fos <<>
}
}
}

}
}

An Alternative to Groovy Action Class
If you do not want to use Spring's dynamic language support, you can still use Groovy to execute the action. Broadway provides a component called ScriptedAction that lets you specify a script file on the classpath or the system file path. Using this option, you can specify the script for your action in a simpler way.

To wire the ScriptedAction do:

<bean id="action" class="org.broadway.monitor.ScriptedAction"> <property name="scriptFileLocation" value="scripts/synchronizeDir.groovy" /> </bean>

Here, the component points to a Groovy script file located on the classpath. The Groovy script that gets executed by the ScriptedAction component is the following:

def dirPath1 = context.resources.firstDir.directoryName;
def dirPath2 = context.resources.secondDir.directoryName;

print "***** Synchronizing Directories [Mirror dir2 to Dir1] *****\n";

def File dir1 = new File(dirPath1);
dir1.eachFile {origFile ->
def origFileName = origFile.name;

def destFile = new File(dirPath2+ File.separator + origFileName);

if(!destFile.exists() || (destFile.lastModified() <>
print "Synching file File $origFile.name ...\n";
def fis = origFile.newInputStream();
new FileOutputStream(destFile).withStream {fos ->
fos <<>
}
}
}

Conclusion
We've seen how easy it is to use Groovy, Spring, and Broadway to wire together monitors. This example shows how to create a directory synchronizer with little effort. I encourage you to take a look at Broadway and let me know what you think.

More Info
Google Doc - http://docs.google.com/Doc?id=df3qdpw5_50hs7pn3fv
Broadway - http://code.google.com/p/broadway-monitor/
Download Broadway - http://broadway-monitor.googlecode.com/files/broadway-0.5.zip
Download Tutorial - http://broadway-monitor.googlecode.com/files/broadway-tutorial.zip

# posted by vmatters : 10:20 PM