This co-worker is relatively new to the company, only having been here for a few weeks, and I hadn’t had opportunity to introduce myself. The other piece of background here is to know that only part of our organization has operated under an Agile framework; the rest is still using a “traditional” system. We had the usual exchange of names. But when they asked me who I worked for, my first response is what made me have the epiphany. I didn’t say my manager’s name, I didn’t say “development” or even the project I am working on. I said “the Honey Badgers”, which is the name we have given to our Scrum team that started together back in 02/2012.

If asked that question before 02/2012, I can almost guarantee you I would have said “development” or “I’m a developer” or something to that effect. This is the change in mindset I am referring to. If you are like me, you will no longer find yourself identifying solely with your “silo” department; you will identify with the team you have been a part of and built a relationship with over the course of time. This is to take nothing away from my fellow developers or my respect for them. I actually think it is a good thing for the team and the organization when you start to identify yourself this way. It shows that you have invested yourself in your team and have dedicated yourself to the success of what your team produces.

What do you think? If you haven transitioned towards an Agile team from some other sort of management, have you also have this same shift in your mindset?

java.lang.NoClassDefFoundError: org/apache/tomcat/PeriodicEventListener

After some research, I looked again and realized that indeed the upgrade script had left the Tomcat plug-in installed via application.properties instead of placing a reference into BuildConfig.groovy, which is the recommended approach. (It also re-installed Hibernate, which we don’t use on this particular application. The upgrade script ALWAYS installs Hibernate!). Here is the correct BuuildConfig.groovy entry:

plugins {
   // other plug-ins
   build ":tomcat:$grailsVersion"
   // ...
}

Once the deployment had failed via the Tomcat Manager, the application was no longer listed but it still resided on the filesystem, and later deployments could not overwrite the files. Here are the steps I had to take to resolve the deployment issue:

1. Deleted the WAR and context directories off of the filesystem
2. Restarted Tomcat
3. Verified the application was no longer in filesystem and no longer listed in Tomcat manager
4. Checked the application into source control with the correct plug-in reference, which triggered CI build and deploy to dev. integration
5. Smoke test

package mypackage;

class MyController {
  // controller methods/closures/etc.
  // uses MyControllerCommand in a POST
}

class MyControllerCommand {
  // properties/methods/constraints/etc.
}

I have used this pattern previously in Grails 1.3.7 and Grails 2.0.1, however when I invoked the closure which used the command object, I got the following error:

errors.GrailsExceptionResolver ERROR VerifyError occurred when processing request: [POST] /MyApp/myController/myMethod
(class: mypackage/MyController$MyControllerCommand, method: jsonHeader signature: (Ljava/lang/Object;)V) Incompatible object argument for function call. Stacktrace follows: ...


After some head scratching and then remembering something my colleague said, I moved the command object out to it’s own Groovy file and the problem went away. After some more searching, I found this error in Grails related to using an anonymous inner class in a controller.

But how is this related to the code above? That’s not an inner class, right? Ah, but it is. Remember how I said this was a Groovy class that housed the controller? When there are multiple class definitions in a single Groovy file, groovyc creates the equivalent of Java inner classes. You can verify this by checking the target directory after compiling your Grails project. In this instance, you would find:
target/classes/mypackage/MyController$MyControllerCommand.class

For example, you have defined a complex type where one of the elements is defined to be <xsd:any>, so that different XML documents can be inserted at that element. The problem is that JAX-WS wants to know all of the possible types at compile-time via annotations! If you don’t provide the run-time classe during compile-time, you will end up with a message liek this when you attempt to marshall the XML:


class example.package.MyType nor any of its super class is known to this context


This breaks all of the abstraction and defining the implementation at run-time. I have not found a simple way to get around this and still add classes to the JAXBContext like I used to be able to do. We have been able to work with it for the most part, but if anyone know of an easy way to add classes to the JAX-WS JAXBContext at run-time, feel free to let me know!

class UrlMappings {
	
	static excludes = [...]

	static mappings = {
		if(getGrailsApplication().config.doA) {
			"/**" (view: '/a')
		} else {
			"/**" (view: '/b')
		}
	}
}

I contacted Atlassian support about getting our install running as a 64-bit process on a 64-bit JVM and their response was “Create a new database schema, install the 64-bit JIRA standalone pointing at that new schema and then migrate your data from the old schema to the new schema. No, not happening. I did some digging and figured out how to get the 32-bit install to run as a 64-bit process. Once I did this, the process started as a 64-bit Windows process and I was able to allocate more memory to the heap.

1. Put a 64-bit JVM on the system, if it does not already have one.
2. Change the Tomcat process properties to point to the 64-bit JVM.
3. Rename tomcat.exe to tomcat.exe.x86
4. Rename tomcat.exe.x64 to tomcat.exe

"C:\Program Files\IIS\Microsoft Web Deploy\msdeploy.exe" -source:package='path\to\the.zip' -dest:auto,wmsvc='https://iisserver:8172/msdeploy.axd?Site=MySite',userName='*****',password='*****',includeAcls='False' -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:path\to\the.SetParameters.xml -allowUntrusted

Everything is good with the command and deployments to iisserver were happening many times a day for a few months. Then the other day, the dev integration deployment job started failing with the following error:

Error: (build date) An error occurred when the request was processed on the remote computer.

Error: Unable to perform the operation. Please contact your server administrator to check authorization and delegation settings.


Nice error! Very informative. So I go ahead and check all the usual things: did a code change break something (no); did the user account represented by userName in the command get locked (no), or did its password expire (no); was the wmsvc agent running on the server (yes); were any Windows updates installed on the server (yes, on the same day the deployment started breaking); were there any changes to the Window or IIS server configuration (no)

With these checks done, the only one that seemed possible was one of the Windows updates might have done it. So I backed out the updates. But that didn’t fix the issue. Hmm, alright. After quite a bit of effort and time expended by myself and our systems administrators, I finally dug up this StackOverflow issue that sounded similar. The answer is what caught me:

…Turns out that when you install web deploy it sets up two local accounts WDeployConfigWriter and WDeployAdmin. These passwords on these accounts are set to expire…

Ah ha! Wait, what?! In addition to the domain service account I use on the command line, there are 2 more local accounts required by the tool? That I didn’t know were there? And they had passwords set to expire after 90 days? Really? Awesome. In any case, after “fixing” those two accounts on the dev integration server, they deployments started working as they had before.

The problem

So let’s assume that you are tasked with writing a temperature conversion application. This converter should be able to convert temperatures given in either degrees Fahrenheit or Celsius and give the result in degrees Fahrenheit. Sounds easy enough, you can model things within the class(es) exactly how you need to solve the problem. But wait! There is another stipulation. You are told that there is already an existing class in some existing archaic Java library that was written ten years ago, and you have you use this class within your code. You think, alright, even if the class is wretched, I can write some new Java code and extend the existing class to offer the new functionality. Presenting the Java class you are required to use:

AncientTemperature.java

package com.asoftwareguy.temperature;

/**
 * This is an "old" existing Java class representing temperature.
 * It assumes the unit of measure is degrees Fahrenheit.
 *
 */
public final class AncientTemperature {
	// in degrees Fahrenheit
	private int temp;

	public AncientTemperature(int temp) {
		this.temp = temp;
	}

	public String toString() {
		return new StringBuilder().append("The current temperature is " + temp + " degrees F.").toString();
	}
}

The class is declared final! So the creator of this class, a decade or so ago, found it in their infinite wisdom that their representation of temperature was perfect and no one would ever need to add any more functionality. Awesome! :/

The solution

You could obviously also create new functionality by creating a decorator class and using composition to delegate calls when necessary out to the existing class, but you are using Groovy, so why would you do that! Here the requirements stated above are as follows:

1. We need to be able to give the temperature inputs in either degress Fahrenheit or Celsius.
2. We need to be able to give the resulting temperature in degrees Fahrenheit.
3. We have to use the existing AncientTemperature.java class.

Requirement #3 is de facto by mandate, so let’s ignore that one. After looking at what we have to work with, it seems that we have requirement #2 already met by the functionality of the existing class. The toString() method spits out the temperature in degrees Fahrenheit:

package com.asoftwareguy.temperature;

public final class AncientTemperature {

	// other methods

	public String toString() {
		return new StringBuilder().append("The current temperature is " + temp + " degrees F.").toString();
	}
}

Let’s look at how we can meet requirement #1 using Categories. Categories in Groovy are somewhat similar to the concept of static extension methods in C# with one key difference: In C#, you can only add new methods to the class which you are extending; you cannot override methods that already exist in the class. In Groovy, you can add new methods as well as override existing methods in the class you are extending! This a powerful feature and one that I will use in this example. Let’s take a look at our Category:

TemperatureConversion.groovy

package com.asoftwareguy.temperature

class TemperatureConversion {

	static AncientTemperature getFahrenheit(String fahrenheit) {
		new AncientTemperature(fahrenheit as int)
	}

	static AncientTemperature getCelsius(String celsius) {
		BigDecimal fahrenheit = (celsius.toInteger() *  (9/5) + 32)
		fahrenheit = fahrenheit.setScale(0, BigDecimal.ROUND_DOWN)
		new AncientTemperature(fahrenheit.toString() as int)
	}

	static AncientTemperature getFahrenheit(Integer fareheit) {
		new AncientTemperature(fareheit)
	}

	static AncientTemperature getCelsius(Integer celsius) {
		BigDecimal fahrenheit = (celsius *  (9/5) + 32)
		fahrenheit = fahrenheit.setScale(0, BigDecimal.ROUND_DOWN)
		new AncientTemperature(fahrenheit.toString() as int)
	}
}

If you have done any kind of temperature conversion before, the code above should look familiar. It uses the standard formulas for converting temperature between degrees Fahrenheit and Celsius, and vice-verse. With this code in place, it allows you to write code like the following, using a ‘use’ block in Groovy:

TemperatureTest.groovy

package com.asoftwareguy.temperature

use(TemperatureConversion) {
	assert  "100".fahrenheit.toString() == 'The current temperature is 100 degrees F.'
	println "100".fahrenheit

	assert 	"50".fahrenheit.toString() == 'The current temperature is 50 degrees F.'
	println "50".fahrenheit

	assert 	"32".fahrenheit.toString() == 'The current temperature is 32 degrees F.'
	println "32".fahrenheit

	assert 	"100".celsius.toString() == 'The current temperature is 212 degrees F.'
	println "100".celsius

	assert 	100.fahrenheit.toString() == 'The current temperature is 100 degrees F.'
	println 100.fahrenheit

	assert 	50.fahrenheit.toString() == 'The current temperature is 50 degrees F.'
	println 50.fahrenheit

	assert 	32.fahrenheit.toString() == 'The current temperature is 32 degrees F.'
	println 32.fahrenheit

	assert 	100.celsius.toString() == 'The current temperature is 212 degrees F.'
	println 100.celsius
}

All of the methods defined in TemperatureConversion.groovy only add new functionality to the AncientTemperature.java class. The ‘use’ block is key to this working, as it provides that any types declared within the block expose the methods of the Category. I had mentioned earlier that in Groovy, you can also override existing methods and I also said I would give an example. So here is the version of the Category with overriding methods:

TemperatureConversion.groovy

package com.asoftwareguy.temperature

class TemperatureConversion {

	// other methods

	static AncientTemperature plus(AncientTemperature first, AncientTemperature second) {
		int tempFirst = first.temp
		int tempSecond = second.temp;
		int newTemp = tempFirst + tempSecond
		return new AncientTemperature(newTemp)
	}

	static AncientTemperature minus(AncientTemperature first, AncientTemperature second) {
		int tempFirst = first.temp
		int tempSecond = second.temp;
		int newTemp = tempFirst - tempSecond
		return new AncientTemperature(newTemp)
	}
}

As you can see above, we have actually overrode the ability to add and subtract objects of AncientTemperature with each other. We can do this even though we do not have this ability in Java because by default, Groovy adds the plus and minus (along with many other methods) to all objects. So now we can write code like this:

package com.asoftwareguy.temperature

use(TemperatureConversion) {
	// other methods

	assert (100.fahrenheit + 50.fahrenheit).toString() == 'The current temperature is 150 degrees F.'
	println 100.fahrenheit + 50.fahrenheit

	assert (100.fahrenheit + 0.celsius).toString() == 'The current temperature is 132 degrees F.'
	println 100.fahrenheit + 0.celsius

	assert (100.fahrenheit - 0.celsius).toString() == 'The current temperature is 68 degrees F.'
	println 100.fahrenheit - 0.celsius
}

Groovy Categories are a powerful tool in providing new functionality to existing types at run-time and for creating DSLs that can describe your problem space. Hopefully this has provided you with a good example of using Groovy Categories to add such functionality.

All of the source code for this post can be found in this Gist.

The first module

The page flow within the first module is as described in Figure 1 below:

Figure 1

When developing the module, both web page forms represented by the 2nd and 3rd steps in the flow were implemented within the same controller class (following the practice of Agile development of implementing what you need right now, and refactoring when circumstances require you to do so). Everything good so far, this is all standard web application development. Story complete, so let’s look at the second module.

The second module

The page flow within the second module is as described in Figure 2 below:

Figure 2

Note that the 2nd step in both Figure 1 and Figure 2 both note that some user input is required before the actual function can commence. As it turns out, the user input required is identical, meaning the exact same form data is captured from the user. This is depicted in Figure 3:

Figure 3

In “traditional” (read: lazy) web development, I might just copy all of the logic for displaying the form and capturing the input from the Option1 controller(s) within Module A into the Option 2 controller(s) within Module B. But I figured it could be implemented so much more cleanly without the need for any code duplication. The solution I decided upon was to implement the logic for determining the need to direct the user to the interstitial page within a Grails Filter.

The solution

Let’s take a look at the Filter class that determines whether the user is required to be directed to the interstitial page.

RequiredAttributeFilters.groovy

class RequiredAttributeFilters {
  def filters = {
    attributeRequiredforOptionA(controller: 'optionA', action: 'index') {
      before = {
        if(session.someAttribute == null) {
          // attribute not set, redirect user to collect data
          def targetUri = request.forwardURI.replace(request.contextPath, '')
          session.requiredAttributesFilterRedirectUri = targetUri
          redirect controller: 'requiredUserInput', action: 'index'
        }
      }
    }
    attributeRequiredforOptionB(controller: 'optionB', action: 'index') {
      before = {
	if(session.someAttribute == null) {
          // attribute not set, redirect user to collect data
          def targetUri = request.forwardURI.replace(request.contextPath, '')
          session.requiredAttributesFilterRedirectUri = targetUri
          redirect controller: 'requiredUserInput', action: 'index'
        }
      }
    }
    removeSomeAttribute(controller: 'user', action: 'menu') {
      before = {
        // user exited current function, remove required attribute
        session.someAttribute = null
      }
    }
  }
}

This is just a standard Grails filter class that intercepts requests to “/option1/index” and “/option2/index” and redirects the user to “/requiredUserInput/index” if the value of session.someAttribute is null. Before redirection, it stores the value of the URL that user initially requested in the session. It also removes the attribute from session if the user exits current function (in my case, goes back to their menu). Now that we have the filter is place, let’s look at the controller that captures the required user input.

RequiredUserInputController.groovy

class RequiredUserInputController {
  def index = {
    // do stuff
    // render view
    render view: 'index'
  }
  def captureData = { 
    // check form errors etc.
    def someAttribute = null;
    // get the data and set the attribute in session
    session.someAttribute = someAttribute
    redirect uri: session.requiredAttributesFilterRedirectUri
  }
}

The above controller has two methods: the standard “index” method for rendering the form and the “captureData” method, which is called upon form submission. The latter performs any required form processing, and in addition, sets the value of session.someAttribute to the correct current value. It then redirects to the URL that was set in session by the filter that redirected here in the first place. The filter is called again, but session.someAttribute has a value so filter processing is skipped. I won’t detail the GSP code for the form page, but it contains a simple form whose action attribute points to the “captureData” URL.

That’s all there is to it. If in the future additional page flows need to same data in order to proceed, those controllers/actions/URIs just need to be added to the Filter class so that the interception occurs.

I am working on a Grails 2.0.x project and am quite enjoying some of the new features that are part of the current Grails release. The new test mixins that are part of Grails 2.0.x are awesome and really simplify the creation of your unit test classes. But I ran across a “gotcha” when using the test mixins.

I was writing a unit test class for a Grails controller, and was using the default template that gets created via:

grails create-controller com.asoftwareguy.example.Example

One of the helper methods exposed by the GrailsUnitTestMixin is the mockFor() method, which is a simplified way of creating a new Groovy mock. I though this to be much cleaner than needing to instantiate a new MockFor() every time I needed a mock proxy for an interface. However, I ran into an issue where the proxy instances created by the mockFor() method of the mixin are not cleaned up between test case runs. Let me give an example of what was failing.

ExampleController.groovy

package com.asoftwareguy.example

class ExampleController {

  def exampleService

  def index() {
    def something = exampleService.doSomething()
    render (view: 'index', model: [something: something])
  }
}

ExampleService.groovy

package com.asoftwareguy.example

interface ExampleService {
  List doSomething();
}

ExampleControllerTests.groovy

package com.asoftwareguy.example

@TestFor(ExampleController)
class ExampleControllerTests {

  void testDoSomething_first_time() {
    def mockService = mockFor(ExampleService) //use the mixin
    mockService.demand.doSomething() { ->
      return true
    }
    controller.exampleService = mockService.createMock()
    controller.index()
    // assertions
  }

  void testListStations_second_time() {
    def mockService = mockFor(ExampleService) //use the mixin
    mockService.demand.doSomething() { ->
      return true
    }
    controller.exampleService = mockService.createMock()
    controller.index()
    // assertions
  }
}

With the above code in place, the first test case would always pass, but the second test case would fail with the following error:

| Failure:  testListStations_second_time(com.asoftwareguy.example.ExampleControllerTests)
|  junit.framework.AssertionFailedError: No more calls to 'doSomething' expected at this point. End of demands.
at grails.test.MockClosureProxy.doBeforeCall(MockClosureProxy.java:66)
at grails.test.AbstractClosureProxy.call(AbstractClosureProxy.java:74)
at com.asoftwareguy.example.ExampleController.index(ExampleController.groovy:xx)
at com.asoftwareguy.example.ExampleControllerTests.testListStations_second_time(ExampleControllerTests.groovy:xx)
| Completed 2 unit tests, 1 failed

After some troubleshooting and debugging the issue, I have concluded that there is a bug in the version of Grails I running (2.0.0) and hopefully it is fixed in the next release. As a workaround, I have reverted to instantiating new MockFor() instances within each test case.