Groovy Categories for temporary mixins

In my previous post I showed how you could add the Apache StringUtils capability into the standard String class in BootStrap.groovy for the entire application to use.

But what if for some reason you do not have access to BootStrap.groovy or adding this kind of mixin for everyone is a little egregious.

This is where Groovy Categories come in very handy. A Groovy 'Category' can be added to any class at runtime by using the 'use' Groovy keyword.

Below is a simple unit test which shows how this is done very easly.

Lines 2-6 show the typical Java usage( with a little Groovy thrown in) using StringUtils.

Lines 9 - 13 so the how the 'use' keyword can be used to temporarily mixin the StringUtils capabilities to a String.

1:    void testUseCategory() {  
2:     String testString = "break.this.string.up.into.words"  
3:     println "Test StringUtils.split"  
4:     StringUtils.split(testString, ".").each {  
5:      println it  
6:     }  
7:    
8:     println "Test use(StringUtils)"  
9:     use(StringUtils) {  
10:      testString.split(".").each {  
11:       println it  
12:      }  
13:     }  
14:    }  
15:    

This example shows how to take a third party library and mix it in, but you can also do this for your own utility classes. You could create a utility class that operates on your class, and then 'use' that utility class to mix those methods in as though they exist on your class. This helps to keep your class focused on the business problem and makes the class much easier to read.

Just another example of some really cool Groovy capability.

I don't always code - but when I do, I prefer Groovy.

Adding StringUtils to the String Class in Groovy/Grails

This one has been blogged about before - but I thought it was just such an easy way to add very useful functionality to the String class that I thought I would call it out.

I had the need to use the Apache StringUtils methods so often in my application that I started to wish that the methods were just native to the String class. Adding this kind of capability is called mixins in Groovy.

To check if a string is null, empty or whitespace, with the Apache package you have to write:

If( StringUtils.isBlank( myStringToCheck) ) {
// then is blank
}

what I wanted to do was:

if( myStringToCheck.isBlank() ) {
// then is blank
}

I just thought this was easier to read and easier to write.

This is actually incredibly easy to do in Groovy/Grails.

The way I went about do this was to add the following line of code to the Bootstrap.groovy file:

// add apache commons lang StringUtils methods to the String class
String.metaClass.mixin StringUtils

add the commons-lang jar file to the lib directory and that is it.

Now for any String I can use any of the methods in the StringUtils package as though they were native methods to the String class.

Nice!

Grails: Dynamically adding a save method to Domain objects that show errors

I was writing some integration tests and I noticed that one of my asserts was failing on a save. It was not clear to me why, so I started to add some diagnostic printing of errors. Then I thought - what happens if another domain object has a problem saving? Am I going to have to do this kind of error check all of the time? Ugh..

Using what I have already blogged about in terms of adding metaprogramming for Services, and a quick google search: See this link where I got most of the inspiration.

What I did was add the following method to Bootstrap.groovy.

  def addDebugSaveToDomainObjects() {
    grailsApplication.domainClasses.each {
      it.metaClass.debugSave =  {
        def obj = delegate.save()
        if( obj == null ) {
          println "Error saving " + delegate.getClass().name
          delegate.errors.allErrors.each {
            println it
          }
        }
        return obj
      }
    }
  }

The above code will add a new method to all Domain objects call debugSave. If there is a problem while saving the domain object this new method will print all of the errors. These errors can be seen in the junit reports.

I did it this way because I really only want these methods when I am testing and I did not want to clutter the domain API with this debug code.

In the bootstrap, I look at the environment and based on the environment name I will call the above closure ( or not as the case may be ).

Next in my integration test, I can execute code like the following:

def myDomain = new Domain(....)
assertNotNull myDomain.debugSave()

If the assert fails, then the Junit reports will tell me so and the output will tell me why.

I hope you found this information useful.

Grails: Intercepting Service class methods - part 3

Well - I have a couple of updates to my previous post:

1) Grails 1.2.2 is out and it does look like the Spring DSL for AOP definitions is fixed.
2) using the Spring xml definition in part 2 performed very poorly. I am not sure why but if I changed the pointcut definition to:

pointcut="execution(* com.redpointtech.flex..*Service..*(..))"

it performed MUCH better

Given that the DSL is fixed and I needed it to perform better I have changed the AOP definition again to the following in the resources.groovy file.

 beans = {  
  xmlns aop:"http://www.springframework.org/schema/aop"  
   securityAspect(SecurityAspect)  
   aop {  
    config("proxy-target-class":true) {  
     aspect(id:'theSecurityAspectDef', ref:'securityAspect') {  
      around method: "invoke", pointcut:"execution(* com.redpointtech.flex..*Service..*(..))"  
     }  
    }  
   }  
 }  

I think this concludes my saga to get Flex services intercepted. I hope this helps you out.

Grails: Intercepting Service class methods - part 2

As a continuation from my earlier post about intercepting Grails Service methods - as it turns out that approach will not work when using flex-remoting. If you want to intercept your services that you expose as Flex services you have to use Spring AOP. Because of a bug: http://jira.codehaus.org/browse/GRAILS-5932 you will have to use the XML version of AOP definition.

To do that you have to create a resources.xml file in grails-app/conf/spring directory and it would look like the following:

 <?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:aop="http://www.springframework.org/schema/aop"  
     xsi:schemaLocation="  
 http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd  
 http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">  
   <!--  
     we are defining the AOP beans in the xml file because of this bug which will  
     not be fixed until 1.2.2 and we are using 1.2.1  
     http://jira.codehaus.org/browse/GRAILS-5932  
     aspect are called twice because of the above bug. See  
     http://n4.nabble.com/Advice-called-2-or-more-times-for-aspect-with-execution-pointcut-Bug-td1588831.html  
     toward the bottom Graeme says that 1.2.2 will have the fixes, and 1.3 M1 already does have the  
     fix. For now we have to live with the interceptor called twice.  
   -->  
   <bean id="myAroundAspect" class="com.redpointtech.aop.MyAroundAspect" />  
   <aop:config proxy-target-class="true">  
     <aop:aspect id="theAspect" ref="myAroundAspect">  
       <aop:around method="invoke" pointcut="target(com.redpointtech.aop.AOPMarkerInterface)" />  
     </aop:aspect>  
   </aop:config>  
 </beans>  

This assumes that you want to intercept any class that implements the AOPMarkerInterface.

The Aspect looks like the following:

 class MyAroundAspect {  
  public Object invoke(ProceedingJoinPoint joinPoint) throws Throwable {  
   Object returnVal = null  
   println "MyAroundAspect called...."  
   returnVal = joinPoint.proceed()  
   return returnVal  
  }  
 }  

A couple of take aways:
1) do not try to do what I suggested in my previous blog post. That will NOT work for Flex services
2) do not use resources.groovy and the Spring DSL - there is a bug in the 1.2.x version that prevents that from working. This is suppose to be fixed in the 1.2.2 release ( not yet released) and the 1.3 M1 ( available now )
3) do use resources.xml and define your Aspect the old fashion way - the old ways work just great.

I hope this saves you some time.

Grails: Intercepting Service class methods

It took me a little while to fully understand how to add some kind of interceptor to a Grails Service class and I wanted to add a blog post incase others have a similar question. After doing some research, and piecing together information from various sites I ended up with the information here. I hope it is helpful to you.

What problem am I trying to solve?
Adding interceptors to Controllers is really easy and I wanted to add some interceptors to my Service classes in a similar fashion. But it appears that you cannot do this for Service classes - just Controller classes. If I am wrong, please someone show me how best to do this.

Why am I trying to do this?
I use Flex in many of my application implementations and I use BlazeDS/AMF in many of the cases. I needed to add a security check on every exposed Flex service.

How did I do this?
In my service class I added a custom property that I called 'secureService'. But as you will see you can use anything.

 class TeslaService {  
   boolean transactional = true  
  // secureService is a custom property that is looked for in the BootStrap.groovy file and if  
  // found in a ServiceClass, then it modifies the invokeMethod to add some code before and  
  // after the call.  
   boolean secureService = true  
   def serviceMethod() {  
    println 'Tesla Service Method called'  
   }  
 }  

Next I updated my BootStrap.groovy file and for each ServiceClass, checked for the 'secureService' property being set to true. If it was, I then used the MetaClass InvokeMethod and assigned a new closure that could add a security check.

The updated bootstrap file looked like the following:

 class BootStrap {  
    def grailsApplication  
    def init = { servletContext ->  
    grailsApplication.serviceClasses.each {  
     def isSecured = it.getPropertyValue('secureService')  
     if( isSecured ) {  
      // example of how to 'intercept' service classes.  
      it.metaClass.invokeMethod = { name, args ->  
       println '''SECURE before $name'''  
       def res = delegate.metaClass.getMetaMethod(name,args).invoke( delegate, args)  
       println '''SECURE after $name. res=$res'''  
       res  
      }  
     }  
    }  
    }  
    def destroy = {  
    }  
 }   

To test this I created an Integration test. This test looked like the following:

 class TeslaServiceIntegrationTests extends GrailsUnitTestCase {  
  def teslaService  
   protected void setUp() {  
     super.setUp()  
   }  
   protected void tearDown() {  
     super.tearDown()  
   }  
   void testServiceMethod() {  
    teslaService.serviceMethod()  
   }  
 }  

The output of this was the following:
SECURE before serviceMethod
Tesla Service Method called
SECURE after serviceMethod. res=null

Some of the links that I used are below as the information from these posts might also be helpful to you.

http://www.pubbs.net/grails/201001/9868/
http://mrhaki.blogspot.com/2010/01/grails-goodness-access-grails.html
http://www.grails.org/doc/latest/api/org/codehaus/groovy/grails/commons/ClassPropertyFetcher.html

FlexBuilder 3 and FlexUnit4 RC1

This will be a quick post on how to setup FlexBuilder project to use FlexUnit4. This post will be more prescriptive with just the steps without a lot of explanation. The FlexUnit site has good documentation.

1) Setup a Flex Project as you normally would.
2) Download the FlexUnit4 from this link.
3) Unzip and copy all of the swc files to your projects libs directory. There should be 4 swc files.
4) create a package/folder under the src directory called flexUnitTests. It could be called anything.
5) Create a test Suite class. This is just a POAO ( plain old actionscript object ). I called mine FlexUnit4Suite and it looked like the following:

1:  package flexUnitTests  
2:  {  
3:      import org.flexunit.runners.Suite;  
4:      [Suite]  
5:      [RunWith("org.flexunit.runners.Suite")]   
6:      public class FlexUnit4Suite  
7:      {          
8:          public var testCase1:MyTestCase;  
9:      }  
10:  }  

Lines 4 and 5 are the most interesting. Use the Suite and RunsWith metadata tags. Line 8 is a reference to your TestCase class. As you add more TestCase classes, just add a new variable here. You dont have to instantiate it, or anything - just declare it.

6) Create your TestCase class, which again is a POAO. Mine looked like the following:

1:  package flexUnitTests  
2:  {  
3:      import flexunit.framework.Assert;  
4:      public class MyTestCase  
5:      {  
6:          public function MyTestCase()  
7:          {  
8:          }  
9:          [BeforeClass]  
10:          public static function runBeforeClass():void {  
11:              trace("runBeforeClass");  
12:          }  
13:          [AfterClass]  
14:          public static function runAfterClass():void {  
15:              trace("runAfterClass");  
16:          }  
17:          [Before]  
18:      public function runBeforeEveryTest():void   
19:      {  
20:        trace("runBeforeEveryTest");  
21:      }  
22:      [After]  
23:      public function runAfterEveryTest():void   
24:      {  
25:          trace("runAfterEveryTest");  
26:      }  
27:      [Test]   
28:      public function testTrue():void  
29:      {  
30:          trace("checkMethod");  
31:          Assert.assertTrue( true );  
32:      }  
33:          [Ignore("Not Ready to Run")]  
34:      [Test]  
35:      public function testNotReady():void   
36:      {  
37:        Assert.assertFalse( true );  
38:      }          
39:      }  
40:  }  

7) Create a new Application for the test runner. You dont have to create a new application, but I assume you already have an Application class that really runs your application. I created another Application called FlexUnitTestRunner. It looked like the following:

1:  <?xml version="1.0" encoding="utf-8"?>  
2:  <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"  
3:      xmlns:flexunitrunning="http://www.adobe.com/2009/flexUnitUIRunner"  
4:      minWidth="1024" minHeight="768" creationComplete="onCreationComplete()">  
5:      <mx:Script>  
6:          <![CDATA[  
7:              import flexUnitTests.FlexUnit4Suite;  
8:              import org.flexunit.listeners.UIListener;  
9:              import org.flexunit.runner.FlexUnitCore;  
10:              private var flexUnitCore:FlexUnitCore;  
11:              private function onCreationComplete():void {  
12:                  flexUnitCore = new FlexUnitCore();  
13:                  flexUnitCore.addListener(new UIListener( testRunner));  
14:                  flexUnitCore.run(FlexUnit4Suite);  
15:              }  
16:          ]]>  
17:      </mx:Script>  
18:      <flexunitrunning:TestRunnerBase id="testRunner" width="100%" height="100%" />  
19:  </mx:Application>  

Run the FlexUnitTestRunner application and my console output looked like:

1:  runBeforeClass  
2:  runBeforeEveryTest  
3:  checkMethod  
4:  runAfterEveryTest  
5:  runAfterClass  

and a browser window popped up with the results of my test case.

Thats it in a nutshell how to get a Flex Builder 3, sdk 3.5, FlexUnit4 up and running quickly.