# The Agile Mindset

I was thinking back on an interaction I had with one of my co-workers last week, and how that made me realize that I have personally had a shift with how I identify myself at work.

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?

# Issue with Tomcat deployment after Grails upgrade 2.0.1 -> 2.2.1

I have been in the process of upgrading all of our existing Grails applications from version 2.0.1 to version 2.2.1. On one particular project I upgraded earlier today, everything worked fine until I attempted to deploy the application to our dev. integration environment. At that point, Tomcat throw the following error when attempting to deploy:

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 # Issue with inner classes in Grails 2.2.0 I was working on a controller in a Grails 2.2.0 project, and it was a Groovy class structured something like this: 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

I have been utilizing JAX-WS to generate web service clients in my current Grails project. It is the best I have found so far in consuming SOAP-based web services within a Grails project. I do have one beef with the library though: annotation overload! I am not a huge fan of the overuse of annotations that has happened over the last few years. JAX-WS seems to want to take this to a new level. For the most part the annotations do seem to stay out of the way, except for one scenario which we have in many of our XSD schemas: <xsd:any>.

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!

# Using GrailsApplication in UrlMappings.groovy

As of the current version of Grails we are using (2.0.1), the grailsApplication bean is not available for use in the UrlMappings class. However, the UrlMappingsHolderFactoryBean implements GrailsApplicationAware, so we can call getGrailsApplication() to do things such as base or mappings conditional on the configuration, like as follows:

class UrlMappings {

static excludes = [...]

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


# Convert a 32-bit JIRA install to 64-bit

Along with being a software developer on our project, I have also become the unofficial tools administrator. We utilize many of the Atlassian tools, among them being JIRA. When JIRA was installed, it was put an a Windows Server 2008 R2 server, but was installed with the JIRA Standalone 32-bit installer. Due to the Windows memory addressing space when processes are running 32-bit, we could only allocate ~1GB of heap space to the JVM. Any more and the JVM would fail to start. Any less and the process would throw a java.lang.OutOf Memory error before it even started fully. Even at the magical 1GB heap size, we would only run stable for 0.5-1.0 day before we would blow the heap.

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

# MSDeploy and when it just stops working

On my current project, we have a Bamboo continuous integration server that deploys an ASP.net application packaged with MSBuild to our dev integration IIS server. This deployment happens via MSDeploy using the following command in the MSBuild script:

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