## 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
Posted in Java | | 6 Comments

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

Posted in .Net, Builds, Deployments | | 17 Comments

## A Groovy temperature conversion with Categories

I have been getting more interested with the capabilities of the Groovy language since I have used it more and more as part of my daily work on a Grails web application. I have also been having some interesting conversations with one of my co-workers about the possibilities provided by Groovy’s MOP (Meta Object Protocol) for creating new ways of expressing meaning in the contextual space of a given problem area using DSLs (Domain Specific Languages). I have seen a few examples of augmenting existing Java classes with new functionality by using Categories wrapped around the existing classes, but have mainly seen these related to distances and conversion of units of measure within that domain. I thought back to one of the first programs I wrote (can’t remember the language, maybe it was C) for doing temperature conversion between degrees Fahrenheit and Celsius. So, I thought I would give an example of using Groovy Categories to add new functionality to existing Java classes.

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

Posted in DSL, Groovy, MOP | | 5 Comments

## Implementing a Grails required interstitial form page

Having shared functionality/pages across software modules in web application development seems to be a common occurrence (at least within the projects on which I am working) and is a problem that can be handled in a number of ways. Currently, I happen to be implementing two different user modules in a Grails 2.0.x application that ended up needing such shared functionality, so I thought I would share my solution. I am going to describe how I initially developed the modules, and how I solved the problem of having a required common interstitial form page that is shared between the two or more page flows.

## 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'
}
}
}
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.

Posted in Grails, Groovy | | 3 Comments

## Grails 2.0 mockFor() Gotcha

Update: When I was researching another Grails issue, I found out that what I encountered below looks to be fixed in Grails 2.0.1. I have yet to verify the fix, but if you also encounter this issue I urge you to try Grails 2.0.1 to see if it resolves the problem.

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.

Posted in Grails, Groovy | | 4 Comments

## Web service clients – where Grails lost its mojo

I am working on a Grails 2.0.x application that needs to consume some web services. Simple enough, I have written many clients in the past, using Axis and Spring-WS in Java, and WCF in .Net. Almost everything I have done so far was easy with Grails and Groovy, so I set out to create a client in Grails.

First off, I found GroovyWS and discovered the ease in which one can create clients with this tool. All was well when running Grails locally, but when the application deployed to our dev integration server (Tomcat 6, Java 6), it was throwing some exceptions about not finding the JAXB types for the specified class name. Apparently, the JAXB implementation on the dev integration was creating classes of different names than the implementation running on my local machine, from the same WSDL. I started debugging but quickly found myself in dependency hell, so I stepped back and tried a different client.

I had used Spring-WS before on a Spring 2.5 Java project and knew how it worked, so I gave it a shot. Even with this implementation, I was getting errors and again finding myself in dependency hell. There was still one more client I had used in the past, so I thought I would give it a try. Running wsdl2java against Axis 1.4 resulted in a client where classes actually would not compile. I attribute this to the complexity of the service itself and Axis’ inability to correctly parse out the types correctly. In any case, no dice on Axis 1.4.

Then I remembered JAX-WS. It is the most up-to-date web service tool supported by Java. After some issues with wsimport failing to generate a client at all (the WSDL has not WS-I BP 1.1 compliant and was later fixed by the service developer), I was able to successfully generate the client. I integrated it with my code, fired up Grails, invoked the service and bam!:

 runtime modeler error: SEI rsastationinventorymgmtcontract.StationInventoryMgmtPT has method __execute annotated as BARE but it has more than one parameter bound to body. This is invalid. Please annotate the method with annotation: @SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.WRAPPED) 

What?! So JAX-WS doesn’t know how to correctly generate a client from a WSDL? I was doubtful and wanted to prove it worked. I created a simple Java application containing the source files for the generated client and a single Java class to test the service. I fired up the 1.6 JVM and ran the class, and lo and behold, the client invoked the service successfully. Then I thought, ‘Oh no, more dependency issues?!’ Then I thought of something. What if I ‘forced’ the JAX-WS implementation used at runtime? Surely that would help, right? I added the following to the Grails BuildConfig.groovy:

grails.project.dependency.resolution = {
...
dependencies {
...
runtime('com.sun.xml.ws:jaxws-rt:2.1.4')
}
}


I built the application and fired up Grails, and was able to invoke the service successfully.

All in all, I have been happy with my development experience in Grails, but dealing with web service clients left me wanting more from the framework in this area. Maybe it is just my unfamiliarity with the framework, but this solution was not obvious to me and left me scratching my head for a while.

Posted in Grails, Groovy, Java, Web Services | | 13 Comments

## A Groovy way to mask data

I was working on some code where I needed to mask data, and the application was being written in Groovy. I came up with this (what I think is a) neat trick to do it, using regular expressions and lambda expressions/closures.

package example

class Model implements Serializable {
...
String value
...