organic thoughts

Official Groovy/Grails Support in NetBeans 6.5

2008-06-30T13:22:00.002-04:00

Judging from the list of features that will be included in NetBeans 6.5, Groovy and Grails will be officially supported by the NB team. From the wiki text, Groovy and Grails will be first-class citizen in NB65 with features that will include:
- Editor support (code completion, color highlights, etc)
- Two-way Java / Groovy class integration
- Seamless Grail project support (support for all Grails artifacts and commands)
- Jetty integration for development-time deployment/testing.

It remains to be seen if NB65 Groovy support will be as comprehensive as IntelliJ which currently has the most extensive support for Groovy / Grails development.

For more, go to:
http://wiki.netbeans.org/NewAndNoteWorthyMilestone1NB65#section-NewAndNoteWorthyMilestone1NB65-Groovy

JavaOne 2008 - Last Day Notables

2008-05-09T18:19:00.002-04:00

The last day of JavaOne 2008 was heralded by the final General Session where Sun showcased several cool projects. Here are a few you maybe interested in. Some are useful others just plain cool:

1. VisualVM - This is a great (and seems to be indispensable) tool to do VM runtime monitoring and profiling. It runs outside of the an IDE and lets you look deep into the VM and your runninig application at runtime. The profiler is the same that is found in NetBeans and provides a hierarchical navigation and snapshot of all activities of a running application. Check it out at https://visualvm.dev.java.net/.

2. NetBeans 6.1 JavaScript Support - if you do a lot of JavaScript, then the NetBeans is for you. In the demo shown on stage, Netbeans manages to make JavaScript development as well-supported as regular Java. The IDE provides Javadoc-like support, code completion, data structure navigation, on-the-fly documentation, even code hints, etc, etc. While other IDE such as Intellij has had support for JavaScript for a while, this is the first glimpse of it on the NetBeans platform.

3. LiveScribe (http://livescribe.com) - this is not a developer tool, but rather a pen-base computing platform based on the Java Micro Edition. It records pen stroke and voice as you write. Describing it here does not do it justice, but the one demo that caught my attention was a translating demo where the presenter wrote words in one language and the pen automatically translates it into different language...

4. Sentilla, Pervasive Computing Device: Sentilla sells small computing devices meant to be used in sensor networks. Pervasive computing is the notion that everything around us will (some day) have a microchip. Companies such as sells a platform to build and deploy these devices everywhere.

5. JFugue, Music Processing Software - this open source software lets you programmatically build music players in Java. It uses a simple text base language to describe music timing, rythm, notes, sound bank, etc. With the JFugue API, you can create music in several ways including direct notation and pattern inference.

Integrating Spring and JBoss SAR Components

2008-05-08T21:22:00.001-04:00

Integrating Spring and JBoss SAR Components
Last time I wrote about JBoss, it was a discussion on how to create a JBoss service component (SAR). However, in many cases, a SAR component has to be integrated with other component-based technologies. In this article, I will discuss how to accomplish this by integrating the JBoss with the Spring component model and how to expose Spring components to receive management services from within JBoss JMX Console.

Integration
The architecture and implementation of the JBoss service component system differ vastly from the Spring Framework's component model. JBoss (version 4.x and below) implements its internal kernel, for its component container, completely on the Java Management Extension API. As such, when you build a JBoss components, you automatically inherits all the management facilities exposed by JMX. The Spring container, on the other hand, is designed to be a lightweight and portable container and has the ability to host POJO's as components. Therefore, Spring has become the container of choice for many system designers because of its simplicity and portability to be hosted in any environment.

As you can see, integrating Spring in another container requires some sort of adapter that controls how and when the Spring context is created and destroyed. As we will see later in this document, this can be easily accomplished using a few API calls.

Motivation
Why would I want to integrate Spring and JBoss you ask? Well, there is an application domain that is not suited to be implemented as web-based apps. Inevitably, at some point in your career, you will need to implement headless services that expose functionalities without a GUI. These type of services are temporally durable and operate without any human intervention. When creating these types of GUI-less services, you may decide to use the Spring container as your core operating environment for POJO components. Since Spring exposes a uniform abstraction layer for the Enterprise Java API's, it makes sense to code around Spring so that your implementation is portable to any environment that can host enterprise services (JBoss container, ServiceMix, Mule, EJB's, etc). Then, your Spring components can leverage services offered by that enterprise environment (database, timers, messaging, adapters, management, etc).

Integration Points
The portability and programmability of the Spring container makes it an attractive platform for developers to create POJO component-driven apps. For web-based apps, Spring provides ready-made adapters to easily integrate your Spring context within the servlet container. However, for non-web system, Spring does not readily provide specific hooks for integration (this is a good thing, it keeps things simple). On the other hand, the Spring API exposes a simple API that makes programming the integration, of Spring in your environment, a seamless effort.

The picture above shows how Spring integration with the JBoss Application Server can be easily achieved. You create a JBoss service component that serves as an adapter to the Spring container. As the JBoss service object receives lifecycle events from the application server, event-handling logic can be inserted in the adapter to control the creation and management of the Spring context. Once booted and running, the Spring container takes over and mounts its internal POJO components and registers them with the available MBean Server for management.

The Spring Directory Scanner
Extending on the example presented in the previous blog on JBoss components, this example demonstrates how to create a Spring-based directory scanner that gets hosted within the JBoss application container. The previous example, all of the logic of the scanner was implemented directly into the JBoss service component. While there's nothing wrong with that approach, it tightly couples your code with JBoss and make it far less portable. In this version of the scanner, the logic is encapsulated in POJO's hosted within a Spring context.

A JBoss service component serves as a Spring adapter and manages the creation and destruction of the Spring context from within the JBoss container. The spring context is booted up by the JBoss service component through life cycle event hooks from the server. Upon initialization, Spring mounts its POJO's and exposes the Directory Scanner component for runtime management and control through JMX. Using the JConsole or JBoss' Jmx-Console, these components can be managed at runtime locally or remotely.

The Code
The code itself is simple and self explanatory. The JBoss service component responds to JBoss application server's life cycle events. These events are used to manage the creation and management of the Spring context. The Directory Scanner Spring component is driven by a Timer Task object mounted in Spring. Every time the timer expires, it executes the scan() method on the Directory Scanner instance.

The JBoss Service Spring Adapter
The JBoss service component is a a plain Java class with life cycle methods named create, destroy, start, stop. It implements a management interface which exposes these methods for JMX control. The component deployer will automatically execute methods create() then start() upon instantiation of the service component.

 public interface JBossSpringAdapterMBean {
            void create();
            void destroy();
            long getErrorCount();
            long getSpringComponentCount();
            String[] getSpringComponents();
            String getSpringConfigPath();
            boolean isSpringLoaded();
            boolean isStarted();
            void setSpringConfigPath(String path);
            void start() throws Exception;
            void stop();
        }

Besides the life cycle methods, there are other management methods that are added for convenience. For instance, there's a method that returns the error count or one that returns the list components loaded in the spring context.

During the deployment of the JBoss Spring adapter (implemented as JBoss service component), the create(), destroy(), and start() methods of the adapter will be invoked by the JBoss service archive deployer. This provides an opportunity to instantiate and manage the Spring context at key points during the lifetime of the adapter.

Booting Spring
The create() method is called after all the setters are injected with values from the JBoss service descriptor.

public class JBossSpringAdapter implements JBossSpringAdapterMBean {
     private ClassPathXmlApplicationContext spring; 
 
 ...   
 
     public void create(){
              log.info("**** CYCLE: CREATE ****");
              if(!created){
                  try{
                      spring = new ClassPathXmlApplicationContext(springConfigPath);
                      spring.registerShutdownHook();
                      created  = true;
                  }catch(Exception ex){
                      errorCount++;
                      created=false;
                      log.error("Unable to start Spring Context", ex);
                  }
              }
          }
 
      ...

The create() method is used to instantiate the Spring context. In the code snippet, the path to the Spring context is injected during deployment from the deployment descriptor using the setSpringConfigPath() method. The registerShutdownHook() method registers Spring to listens to VM shutdown signal so the context can properly deactivate all of its registered components.

Shutting Down the Context
On the other hand, when your JBoss adapter class receives a shutdown signal (say, the server is shutting down for instance), you wan to have your Spring context gracefully go down as well. By providing a destroy() method, the JBoss deployer invoke that method when the server sends out a shutdown signal.

    public void destroy() {
            log.info("**** CYCLE: DESTROY ****");
            if(created){
                try{
                    stop();
                    if(spring.isActive()){
                        spring.close();
                      &nbsp; spring.destroy();
                        spring = null;
                    }
                    created = false;
                }catch(Throwable ex){
                    log.error(" Failed to destroy component. ", ex);
                }
            }
        }

Controlling the Spring Context
Another desirable aspect of the adapter is the ability to control the Spring context with a start / stop functionality. While it is not a necessary, it affords a runtime convenience where the Spring context can be controlled and managed from a JMX console.

...
      public void start() throws Exception {
          log.info("**** CYCLE: START ****");
          if(!started){
              try{
                  if(!spring.isActive()){
                      spring.refresh();
                      spring.start();
                  }
                  started = true;
                  log.info("**** Spring context started OK.****");
              }catch(Throwable ex){
                  errorCount++;
                  started = false;
                  log.error("**** Failed to start Spring context:", ex);
              }
          }
      }
 
  ...
 
      public void stop() {
          log.info("**** CYCLE: STOP ****");
          if(started){
              try{
                  spring.close();
                  started = false;
              log.info("**** Spring context stopped OK.****");
              }catch(Throwable ex){
                  errorCount++;
                  started = false;
                  log.error("**** Failed to stop Spring context:", ex);
              }
          }
      }
 
  ...

The JBoss Service Component Descriptor
The last part of creating the JBoss Spring Adapter, is to create a JBoss Service Descriptor file (jboss-service.xml). Using this file, you can inject runtime values, and point to a descriptive xmbean descriptor file that is used to export your service archive component as an JMX MBean.

<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="integration.jboss.JBossSpringAdapter"
name="demo.integration:name=JBossSpringAdapter,type=Adapter"
xmbean-dd="META-INF/spring-adapter-xmbean.xml">
<attribute name="SpringConfigPath">/META-INF/spring.xml</attribute>
</mbean>
</server>

For details about creating a JBoss service component and how to format jboss-service.xml and the Xmbean descriptor file, visit the JBoss 4 User Guide.

Deploying the JBoss Spring Service Adapter
Without going into the implementation of the Spring Directory Scanner component, let's see what happens when the JBoss service archive is deployed. We expect the JBoss SAR deployer to recognize our JBoss Spring Adapter component as a valid JBoss service archive component and deploy it. Once deployed, we can validate the deployment through the log and through the JMX Console.

JBoss SAR Starting

During deployment, we see the JBossSpringAdapter service component being deployed by the application server. We can also see that the Spring context is being instantiated.

JBoss JMX Console shows the JBoss service component JMX management interface.

The JMX operations for the Spring service adapter are shown above. Notice that you can start and stop the spring container at runtime. That gives you the ability to conrol the lifescyle of your Spring container at runtime without redployment of the application . This maybe useful if you want to make a configuration change in production without redeployment of the entire application.

The Directory Scanner Spring Component
The scanner is a simple Java object which uses the standard java.io.File package to get filtered list of files in a given directory. You will notice that there are some annotations around the class. These are Spring-specific annotations used to expose the Directory Scanner class as a managed JMX MBean (this is not covered in this writeup). I also introduce an interface called Controllable for good form (not necessary).

The Controllable Interface

 public interface Controllable {
     public void start();
     public void stop();
 }

This interface shows control points that can be implemented in the Directory Scanner. This is not necessary, but added for completion.

The Directory Scanner Class
The class that implements the logic for scanning the directory is divided into three distinct sections

The properties (getter/setters) for the component
The life cycle control methods
The scanning method which is invoked to do a sweep of a a directory

@ManagedResource(description="Directory Scanner Component.",
 objectName="demo.integration:name=DirectoryScanner,type=SpringComponent")
 public class DirectoryScanner implements Controllable{
 
 ...
     
     @ManagedAttribute(description="Comma separated list ....")
     public String getExtensionList() {
         return (fileFilter != null) ? fileFilter.toString() : null;
     }
     
     @ManagedAttribute
     public void setExtensionList(String extensionList) {
         fileFilter = new FileListFilter(extensionList);
     }
 
     @ManagedAttribute(description="The directory location to scan.")
     public String getLocation() {
         return (location != null) ? location.getPath() : null;
     }
 
     @ManagedAttribute
     public void setLocation(String location) {
         this.location = new File(location);
     }
 
 ...
 
     @ManagedOperation(description="Lifecycle to start component.")
     public void start() {
         started = true;
         log.info("**** Directory Scanner Compoennt started OK.");
     }
 
     @ManagedOperation(description="Lifecycle to stop component.")
     public void stop() {
         started = false;
         log.info("**** Directory Scanner Compoennt stopped OK.");
     }
 
 ...
 
     public void scan() throws RuntimeException {
         if (started) {
             if (location != null && location.isDirectory()) {
                 File[] list = location.listFiles(fileFilter);
                 log.info("Scanned files with extensions [ " + fileFilter.toString() + "]" +
                         " from [" + location.getAbsolutePath() + "]");
             } else {
                 log.warn("Unable to scan location  Make sure it's valid.");
             }
         }
     }
 
 }

As you can see, this is a simple class. The thing to notice is the Spring-specific annotations that decorate the class. They are used to export and describe the class as a JMX MBean server. It's beyond the scope of this write up to go into the details of how to do this in Spring. However the next section shows the Spring file that describes and wire it all together.

The Spring Configuration File
The configuration of this component is simple and straight forward.

    <bean id="scanner" class="component.spring.DirectoryScanner" init-method="start" destroy-method="stop">
         <property name="location" value="../../"/>
         <property name="extensionList" value="*"/>
     </bean>

Above, we see the DirectoryScanner being configured to scan two directory up from where the application is invoked. Also, we set the list of files to scan.

    <bean id="timerFactory"
           class="org.springframework.scheduling.timer.TimerFactoryBean">
         <property name="scheduledTimerTasks">
             <list>
                 <ref bean="scheduledTimerTask" />
             </list>
         </property>
     </bean>
     
     <bean id="scheduledTimerTask"
           class="org.springframework.scheduling.timer.ScheduledTimerTask">
         <property name="period" value="3000" />
         <property name="timerTask" ref="timer" />
     </bean>
     
     <bean id="timer"
           class="org.springframework.scheduling.timer.MethodInvokingTimerTaskFactoryBean">
         <property name="targetObject" ref="scanner" />
         <property name="targetMethod" value="scan" />
     </bean>

The stuff above is boiler plate for setting up timer services from Spring. Here we are declaratively setting the timer to invoke the scan() method on the DirectoryScanner POJO wired above.

    <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
         <property name="assembler" ref="assembler"/>
         <property name="namingStrategy" ref="namingStrategy"/>
         <property name="autodetect" value="true"/>
         <property name="registrationBehaviorName" value="REGISTRATION_REPLACE_EXISTING"/>
     </bean>
     <bean id="jmxAttributeSource"
           class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource"/>
 
     <!-- will create management interface using annotation metadata -->
     <bean id="assembler"
           class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
         <property name="attributeSource" ref="jmxAttributeSource"/>
     </bean>
 
     <!-- will pick up the ObjectName from the annotation -->
     <bean id="namingStrategy"
           class="org.springframework.jmx.export.naming.MetadataNamingStrategy">
         <property name="attributeSource" ref="jmxAttributeSource"/>
     </bean>

Finally, the code snippet above sets up the POJO to be exported as an MBean into the running MBeanServer. This configuration relies on the annotation embedded in the class to derive the meta data used to describe the class inside the MBeanServer.

Download Source
You can download the application sample application to get the code source.

Observations

Think in Component - component-based development is incredibly easy to get into and understand. It facilitates the separation of concerns and promotes forces you into better coding practices (testing, loose coupling, re-usability, etc).
JBoss Service Component Evolving - Starting with version 4.x, JBoss components can now be annoted (instead of using the descriptor file) to describe its meta characteristics for JMX. Starting with version 5, JBoss will switch to OSGi as the executable unit for its components.
Exception Management - When deploying components into a container (such as JBoss app server), great care must be taken to handle exceptions properly. In JBoss (version 4.x), when a component throws an unhandled exception, that component is immediately disabled and shutdown. You must catch all exceptions and handle them properly. In DirectoryScanner, for instance, if the scan() method throws an exception during a scanning request, the entire component is deactivated.
(OSGi) Components Are Here to Stay - All major containers including JBoss AS, SpringSource App Platform, IBM WebSphere, Glassfish, and JOnAs support OSGi bundles as their coarse component model.

Refereces

Source for Directory Scanner - http://vladimirvivien.com.s3.amazonaws.com/jBoss-spring-integration.zip
JBoss Server Microkernel - http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch2.chapter.html
Spring Documentation - http://static.springframework.org/spring/docs/2.5.x/reference/index.html
Spring JMX Documentation - http://static.springframework.org/spring/docs/2.5.x/reference/jmx.html
OSGi - http://en.wikipedia.org/wiki/OSGi
OSGi and Spring - http://www.infoq.com/interviews/osgi-adrian-colyer

JavaOne - OSGi Is Huge Here!

2008-05-08T12:11:00.003-04:00

If you doubted that OSGi can achieve mass appeal, the list of sessions at J1 proves contrary. Most major tool vendors has either implemented it or have plans to support OSGi bundles:

OSGi has been in IBM's arsenal for while now (Eclipse, Websphere, etc)
SpringSource's new Spring Application Platform uses OSGi has its
Glassfish Version 3 will be OSGi-bundle compatible
JBoss 5's kernel will load its component as OSGi
JSR 277, the Java Module system, slated for JDK7, can load OSGi bundles

From small embedded devices, to desktop, to the large application server, OSGi seems to be the component model that the industry is adopting. It will be interesting to see how the corporate developer integrates OSGi in their development rituals.

JavaOne 2008 - Sun, Lifestyle Company?

2008-05-07T10:08:00.004-04:00

On day one of the JavaOne, the theme is clear: JavaFx (http://javafx.com/) is here to stay. The FX story is coalescing into a platform clearly targeting digital lifestyle experiences. It is clear that tremendous of resources are being devoted to bring the FX story together as technology stack with support for rich that stretches from mobile devices, desktop, to the backend.

The Tools
- Continued JavaFX support from NetBeans
- Photoshop/Illustrator plug-in's to export art work as JavaFx artifacts directly

The Features
- JDK 6 update 10 (jdk 6u10) - setting the path for the desktop features envisioned by Sun
- Applets - Sun is going back to the Applets as a way to augment browsing experiences.
- Audio/Video - under the FX unbrella Sun is offereing an HD qualility a/v codec for Java
- FX is slated to target devices such as cellphones and other mobile stacks with a consistent user experience from device to desktop.
- Project Hydrazyne: another Sun initiative to let users easily create rich content and experiences dritributed in a Sun hosted cloud.

I would like to see this effort successeed, for anything elese, just to have competition in the content technology market place. Adobe leads that sector, Microsoft is making inroad with Silverlight, now Sun wants to give Java developer a way into the rich content user exeperience.

You just have to read the blogs around the net to find doubters about this strategy laid out by Sun. However, I think if the company remains on message, provide the tools, continue to share the vision, there will be new convert. Lets see what happens!

Introducing Groovy JMX Builder

2008-04-09T06:41:00.002-04:00

After I attended the Groovy/Grails Experience in February this year, I realize that the Groovy builder pattern can be used to façade many other API's (not just swing). So, I decide to create, yet another builder, for the JMX API and here it is!

http://code.google.com/p/groovy-jmx-builder/

Features

Ability to expose any class instance for management for both Java and Groovy classes.
No need to implement a specific management interface.
Shield developer from complexity of JMX API
Use familiar Groovy builder pattern
Exposes attribute, constructors, operations, parameters

Suppose you have a class called Greeter (on your class path) that prints out greeting to a specified person in a specified language, so the class may look like this

public class Greeter {
private String name;
private String language = "en";

// ...

public String getName() {
    return name;
}
public void setName(String name) {
    this.name = name;
}

// ...

public String greet(){
    String greet = (String) (langs.containsKey(getLanguage()) ?
        langs.get(getLanguage()) : langs.get("en"));
    return greet + " " + getName();
}

 String greet(String person){
    return  langs.get(language) + " " + person
}
}

You can use Groovy Jmx Builder to expose an instance of that class for management as an MBean.

def greeter = new Greeter()
JmxBuilder jmx = new JmxBuilder()
def server = jmx.export(svr){
 bean(greeter){
     name("greeterDemo:service=greeting")
     desc("This service prints a greeting on console")
     attribute(name:"name", desc:"name of person to greet", writable:true)
     attribute(name:"language", desc:"the language to use", editable:true)
     operation(name:"greet", desc:"Sends greeting to user")
     operation(name:"greet", desc:"Send greeting to user"){
         parameter(type:"java.lang.String", name:"Person", desc:"The person to send greeting to")
     }
 }

 bean(object:greeter, name:"greeterDemo:service=greeting2")
}

You use the JmxBuilder() class to capture meta data about your class instance that will be made available at runtime for management.

In JConsole, the generated MBean may look like this

Feedbacks
I am interested in feedbacks for this project. So, download it and give it a try. I will be adding more features to it in the future.

Using Groovy's FactoryBuilderSupport to Build Internal DSL

2008-03-04T19:02:00.001-05:00

Using Groovy's FactoryBuilderSupport to Build Internal DSL

Couple of weeks ago at the Groovy/Grails Experience conf, Groovy's meta programming was a big theme there. Since then, I blogged about using Groovy's built-in Meta Object Protocol (MOP) mechanism to create a simple XML builder. Then I got curious about other builders such as Swing and SwingX. Talking to James Williams (SwingXBuilder creator), I found out that Groovy's FactoryBuilderSupport interface is designed specifically to allow developers create builder-style DSL. While the FactoryBuilderSupport provides a rich interface to create your own DSL, examples are hard to come by. Thankfully, James had just created another builder called Java3DBuilder which uses the FactoryBuilder interface and a good starting point. This shows a small example on using the FactoryBuilderSupport.

The FactoryBuilderSupport along with Groovy's Factory interface offer a structured approach to constructing internal DSL's. Unlike tapping directly into MOP to manage your DSL nodes, the factory approach requires you to explicitly register by name each node with the FactoryBuilder. The Factory interface exposes event callbacks to intercept different phases of node traversal by the FactoryBuilder which lets manage state and behavior of your DSL. Here is how Groovy's website describes the Factory interface and its methods:

A quick note about newInstanceMethod() - when the factory builder creates a new instance of your node, it will pass in these params: an instance of the factory builder, the name of the node being processed, an argument value (if used as the form node(arg) ), and optionally a map if the node is used as node(key:value...).

Saying Hello, the DSL Way
So, using the information above (and some some sleuthing on my part), I was able to figure out how to use the FactoryBuilderSupport class to build a simple DSL to display a greeting message. So, the first thing is to specify how the language will look and feel. Since we are using the builder pattern, our DSL will have the familiar construct we have seen in other builders:

builder.using(a given language) {
greet(person1)
greet(person2)
greet(person4)
...
greet(personN)
}

A call to builder.build() will print out the greeting in the proper language.

The Code
First, let us look at the backing structure that will support our DSL. It consists of a Person object and GroupGreeter class. The latter actually stores the persons we want to greet and apply the logic to build the greeting string.

The greetings can be in several languages including English, French, German, Spanish, Italian, and Portuguese. The greetings map (line 9)stores the greeting text as well as the conjunction to use when we are greeting more than one person.

Disclaimer: I am not a language geek. This translation is straight from Google Language Tools . So, I am not responsible for greetings that are colloquially incorrect or used in the wrong context!

On to the Builder
The next code snippet shows the FactoryBuilderSupport and the factories that it manages. Each node in your DSL is implemented by a factory instance. In our example, the nodes are are using and greet. Node using is registered with GroupGreetingNode and greet is registered with class GreetingNode.

GroupGreetingNode represents the parent node. It sets up a GroupGreeter object (see previous section) with the language passed in as its argument and returns the newly created GroupGreeter object. The GreetingNode is a child node of the GroupGreetingNode. When the "greet" node is encountered, the builder calls newInstance() on GreetingNode and a new instance of the Person object with the name as an argument and returns the newly created person back to the builder. The builder will eventually call setParent() on the GreetingNode. At that point, the person object that was created in is added to the parentNode (which is an instance of GroupGreeter). That's it!

Running the Code
The following shows two usage of the Greeting DSL

The code above produces

Hallo, Jon, David und Ella
Salut Mireille

Observations

The semantic for your DSL requires an appropriately fitting backing API and data structure
Model your backing data structure close to your DSL. It makes implementation of the builder simpler.
If you can't change the backing API, try model your DSL syntax and semantic close to your API.
FactoryBuilderSupport and Factory simply facilitates the traversal of the DSL nodes. They should not be used to implement the backing data structure.
How you process the nodes is subjective and depends on how your backing data model is structured.
Process data at the intended node level. So, a child node should process all of its data not pass it to the parent.

Conclusion
There's no doubt that Groovy makes developing DSL easy. As we have seen the combination of the FactoryBuilderSupport class and the Factory interface provides a structured approach to creating DSL that conforms to the builder pattern. In this write up I demonstrated how to create a simple DSL to print out greeting on the screen. The same techniques used here are used to create more complex DSL such as Java3DBuilder.

References
0. Download Groovy source code - http://vladimirvivien.com.s3.amazonaws.com/GreetingBuilderDemo.groovy
1. Dynamic Groovy - http://groovy.codehaus.org/Dynamic+Groovy
2. Groovy FactoryBuilderSupport - http://groovy.codehaus.org/FactoryBuilderSupport
3. Jame William's Java3DBuilder - http://www.jameswilliams.be/blog/entry/60

Hope you enjoyed it!

Creating a Simple Builder with Groovy's methodMissing()

2008-02-25T18:16:00.001-05:00

Creating a Simple Builder with Groovy's methodMissing()

One of the main theme here at Groovy/Grails Experience is Meta Programming: the ability to use Groovy to dynamically modify the behavior of the language at runtime. During one of Graeme Rocher's session, he did a live demo on how to build a simple Xml builder and Vankat Subramaniam demo'ed the creation of a simple DSL using Groovy. These sessions showed the simplicity and power of Meta programming in Groovy. So, rather than go on and praise the merits of Groovy and make this an all fluff write up (and get crap for it from my buddy James Williams ), I will show a concrete example below.

A Simple Xml Builder in Groovy
This simple xml builder is able to handle most xml tag constructs including:

<tag/>
<tag atrrib="val"/>
<tag>String content</tag>
<tag attrib="val">content</tag>
<tag attrib="val"><tag>... tag[n] ...</tag></tag>

Sorry, there is no namespace support of the form <namespace:tag/>

So, here is a sample usage of the SimpleXmlBuilder class to build XML nodes:

The code snippet above will generate this HTML code:

<html xmlns="htt://namespace" ><header><title>Hello</title></header><body><p>Hello World Sample</p><span id="greet" style="font-family:sans-serif" >Hello World!!</span></body></html>

The Code
Disclaimer: this was put together in less an hour while sitting in a session at the G2 Experience. I am sure it can be done in a more elegant way. The code simply evaluates each of the syntatic possiblities (discussed above) and take appropritae action. So, with that out of the way, here is the code for simple xml builder:

Click to download the Groovy source code.

MOP - methodMissing()
If you are new to Groovy then you may not understand what's going on. Groovy's meta object protocol (MOP) lets developers expand the syntactical constraints of the core language at runtime. This capability makes Groovy the perfect platform to create Domain Specific Language (DSL) where you develop small language with a concise syntax to address a given domain (software dev, business, etc). The methodMissing() method is one of the hooks exposed by Groovy's MOP mechanism that intercepts all calls to undefined methods on a given object. By overriding methodMissing(), you can implement behaviors of methods that are not statically defined on the class.

When Groovy's MOP intercepts an method call, it invokes methodMissing(String methodName, args) with two parameters: the name of the missing method that was invoked and an array representing the method's parameters. So, for instance, when Groovy intercepts xml.title("Hello"), the first parameter of methodMissing() has a value of "title" and args.length = 1 where arg[0] = "Hello".

When the syntax is as follows, xml.header {...}, methodMissing's method name has a value of "header". Here, however, args[0] is a closure. A closure is an executable (callable) code block that can be treated as a variable. As such, we must tell Groovy that we want to execute that code block. However, before we blindly call the closure, we reassign the closure's target to be the SimpleXmlBuilder class (args[0].delegate = this line 11 and 49). Therefore, the next method dispatch request on the closure will be handled by the SimpleXmlBuilder.

Finally, when the syntax of our builder takes the form of xml.html(xmlns:"http;//somenamespace"){ ... }, Groovy's MOP invokes methodMissing where the method name is "html" as expected. In this case, however, argument array has two memebers: the first one is a map and the second member is another closure. Knowing this, we can handle tags with both attributes and function as a container tag as shown above (starting with line 37).

Conclusion

This sample code above demonstrates how Groovy's MOP mechanism can let developers change and extend the language's syntactical behavior to build functional DSL that fit specific needs. Here, in about 30 lines of code, we created a simple XML builder which is able to output well-formed xml document. This is a simple example and shows just a small glimpse of the capabilities of Groovy's meta programming. I hope this inspires you to continue to explore Groovy and come up with your own use for MOP.

References
0. Download Groovy source file - http://vmatters.googlepages.com/SimpleBuilderDemo.groovy
1. Dynamic Groovy - http://groovy.codehaus.org/Dynamic+Groovy
2. Using methodMissing and propertyMissing - http://groovy.codehaus.org/Using+methodMissing+and+propertyMissing
3. Meta Programming with Groovy Part 1 - http://groovy.dzone.com/articles/metaprogramming-groovy-i
4. Meta Programming with Groovy Part 2 - http://groovy.dzone.com/articles/metaprogramming-groovy-ii-expa
5. Google Doc version of this write up - http://docs.google.com/Doc?id=df3qdpw5_53chtkh89r

Integrating Groovy Classes in Spring

2008-02-05T11:12:00.000-05:00

Spring Meets Groovy!

[View in Google Doc: http://docs.google.com/Doc?id=df3qdpw5_51fqxz7cft ]

If you don't use Spring or care to know about it, then this write up is not for you. I will look at how your Java-based Spring component can made Groovier!! Again, as a pre-requisite, you must already be using Spring (2.0 or better) and have a working knowledge of Groovy.

Why Groovy and Spring?
After more than ten years of Java, we can all agree that one language does not fit all. We (collective Java community) have been banging square pegs into round holes (with patterns, anti-patterns, best practices, frameworks as lubricant). With the advent of dynamic languages such Groovy and Ruby in the enterprise, we are realizing that it is time to start building polyglot systems. Poly-who, you ask?? A system that is made up of one or more languages. Each language addresses a specific domain (i.e. structural, configuration, business, ui, etc) so that your pegs fit where they should. We are already do this today when we write our views in JSP's, controllers in Java, retrieve data using SQL, and configure our apps using XML.

Groovy in Spring Example
Wiring Groovy beans in Spring is easy and require little deviation from what you already know. You can create your beans following these steps

1. Create a Java Interface
Currently, Groovy beans in Spring must implement an Java-defined interface so that Spring can get type information about your Groovy beans. So, let's create a Payment interface:

package demo.vladimirvivien;

import java.util.HashMap;

public interface Payment {
void pay(HashMap info);
}

2. Implement in Groovy
Create a Groovy class that implements the interface. Place your Groovy file somewhere on the classpath. In this example, the file is placed in groovy/CreditCardPayment.groovy. Your Groovy class has access to any classes on the classpath as well, so you can reference other Java classes or other Groovy classes. The class has two properties (mechantId and serviceUrl) which can be injected at runtime by Spring (see below).

import demo.vladimirvivien.Payment
import java.lang.Util.*
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

class CreditCardPayment implements Payment {
static Log log = LogFactory.getLog(Payment.class)

String merchantId;
String serviceUrl;

void pay(HashMap info) {
log.info("Processing Payment...")

println "---------------------------"
println "Merchant ID:t${merchantId}"
println "Service URL:t${serviceUrl}"
println "Payer:nt${info.PAYER_NAME}nt${info.PAYER_ADDR}ntCard:${info.PAYER_CCNUM} Exp:${info.PAYER_CCEXP}"

// process payment here
}
}

3. Wire in Spring
The first thing to notice is the XML schema declaration. It makes reference to the XML lang namespace and the lang XSD. This allows you to use the specially provided <lang:groovy/> tag. The tag lets you wire in Groovy beans and inject property values into them. Here, we are injecting mechantId and serviceURL with values just as we do regular Java POJO's.

<?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.5.xsd
http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.5.xsd">

<lang:groovy id="payManager" script-source="classpath:groovy/CreditCardPayment.groovy">
<lang:property name="merchantId" value="ID343432-4434-34" />
<lang:property name="serviceUrl" value="http://paymentservice/processor.do" />
</lang:groovy>

</beans>

Run the Example
Here, we have a Java class that runs the example. However, you can imagine this setup working in other context such as a web application, a standalone process, or any other context where Spring can live. Note in the code that once the Groovy bean is retrieved from the Spring context, it is used as a regular Java class.

package demo.vladimirvivien;

import java.util.HashMap;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Main {
public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext("META-INF/spring-context.xml");

// pull an instance of the Groovy Payment bean
Payment payment = (Payment) ctx.getBean("payManager");
HashMap<String,String> info = new HashMap<String,String>();
info.put("PAYER_NAME", "John Foo");
info.put("PAYER_ADDR", "12345 Main Street, USA");
info.put("PAYER_CCNUM", "1234564343343");
info.put("PAYER_CCEXP", "0910");

// call the implemented mehod pay()
payment.pay(info);
}
}

You should see the followings on the screen:

So What?
You may be saying "Why should I care? I can do the same thing in Java!" You would be correct. This is not meant to supplant Java but rather complement it. Integrating a dynamic language such as Groovy into your enterprise development gives you a new level of flexibility and configurability that was not there before (or at least requires additional steps to work smoothly). You can use this approach in several scenarios
- Configuration: Use Groovy beans to capture configuration rules for your system or for your business logic including page flow, process flow, etc.
- Business Rules: some business logic tend to change. You can use Groovy to
- Handle Event: Use Groovy to react to system or application events (i.e. if inventory falls below a level, send email. This works well in conjunction with JMX)
- Validation: validation rules is another context susceptible to changes. Capturing your validation in Groovy lets you adjust to your business needs.
- Expose Edge Services: these are the services that expose functionalities at the boundaries of your system (i.e. MVC controllers, web services, REST services, etc). See project Grails .

Conclusion
We looked at how Groovy can be integrated in your application using Spring. Groovy is a natural choice for Polyglot programming on the Java VM given its flexibility and growing popularity. This write up shows a small instance how Groovy can be integrated into your system using the Spring Framework. Groovy can be injected in your enterprise stack to handle the more fluid context where logic tends to be updated to keep up with business requirements.

References
0. Google Doc for write up - http://docs.google.com/Doc?id=df3qdpw5_51fqxz7cft
1. Spring Dynamic Language Support - http://static.springframework.org/spring/docs/2.5.x/reference/dynamic-language.html
2. Ola Bimi - Language Exploration (blog) - http://ola-bini.blogspot.com/2008/01/language-explorations.html
3. Neal Ford - Polygot Programming (blog) - http://memeagora.blogspot.com/2008/01/polyglot-programming-parallels-perched.html
3. Grok - Polyglot Programming (blog) - http://www.grok-programming.com/2007/11/25/polyglot-programming-is-it-just-too-much-to-ask/

Grails Is Changing My Entrepreneurial Ambitions

2008-01-20T09:36:00.000-05:00

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!

Groovy + Spring + Broadway = { -> Resource Monitoring }

2008-01-10T22:20:00.000-05:00

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.


<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.


<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

Introducing Project Broadway Monitor

2007-12-31T03:45:00.000-05:00

I have been working on this on and off for the past 3 years. As with free-time projects, it started out as something completely different and progressively turned into what it is today. If you find the project interesting, send some feedbacks! So, here it is:

Project Broadway is an extensible and customizable monitoring API. Broadway lets developers easily create monitor components to observe pre-defined conditions and specify how to react when these conditions are encountered.

At its core, Broadway lets you separate the monitoring concerns from the observed resources. It has a flexible design, which allows it to work in any context where JavaBean-style getter property values can be read either directly through in-VM method invocation or through some detached mechanism (i.e. proxy, reflection, rmi, jmx, web service, etc). Broadway's simplified design offers two major high level components a Monitor and an Action. The Monitor components lets you specify resources to monitor and express some rules to monitor using a scripting language (Groovy is the default). The Action component specifies the action to execute when a specified condition is realized. Action can be pure Java classes or they can be written in scripting languages such as Groovy or JavaScript, etc.

Broadway Offers

Ability to monitor both in-VM and distributed resources.
API with rich level of programmability through a monitor DSL.
Leverages existing frameworks including JavaBean, JMX, Java scripting, Apache BSF, etc.
Support expressive monitoring rules using scripting language (default is Groovy)
Create compound expression to monitor multiple resources which can be in different context.
Architecture allows plug-in of different scripting engine supported Apache BSF (default is Groovy).
Scripted action component to execute script files to react to monitor expressions.

For more details, visit http://code.google.com/p/broadway-monitor/