Friday, December 28, 2007

Justify using Groovy

How does one justify using Groovy on a project? To me it's no different than including any other dependency in my project and in the end it has the same result but with a lot more benefits. There are a lot of skeptics out there, specifically among my team members, and I just can't imagine why they wouldn't want to use Groovy in their every day development. I guess in this instance "knowledge is a curse." It's kind of difficult to explain why I believe in what Groovy is doing, but I will at least give it a try.

First, the biggest initial hurdle people can't get over is they think to start writing Groovy they have to stop writing Java. That couldn't be further from the truth. Groovy was never meant to replace Java. I have used Groovy to write unit tests for my Java code and I have written Groovy code that has used Java code and vic versa. My experience has shown that Groovy and Java just work seamlessly together, especially when using the maven-groovy-plugin and the IntelliJ Idea JetGroovy plugin (for more information see More Groovy Goodies by Joe Kueser).

Secondly, to me the biggest benefit of Groovy, with no cost to the developer, is the hundreds of extra methods added to existing Java classes (see the Groovy JDK). Just by including a new dependency, I have at my disposal hundreds of new time saving methods that I can start using immediately. For example, there are approximately 50 new methods added to java.lang.String (not sure I will ever use all of them but you get the picture). Now lets say for example you were using some open source project like JFreeChart. And you were using version 1.0.8, and 2.0 was out and it included hundreds of new methods. How long would it take you to change the version in your maven2 pom? To me this is not much different than using Groovy to "extend" Java.

Finally, I want to give a quick example of what the end result of a Groovy class is since Groovy is just complied into Java bytecode. Since I have repeatedly stated that Groovy is no different than including a new dependency in your project let me prove it.

Borrowing an example from my previous post, lets say my Groovy class looks something like this:

class GroovyFileTest {
def void test() {
def file = "/workspace/sandbox/grvyfile/src/test.txt"
println new File(file).text()

My next step would be to use the Groovy Complier (groovyc) to compile my Groovy source into Java bytecode (or just use the maven-groovy-plugin). That would produce GroovyFileTest.class. Using a Java decompiler, such as Jad, here is the outcome:
public void test()
Class class1 = GroovyFileTest.class;
Class class2 = groovy.lang.MetaClass.class;
Object file = "/workspace/sandbox/grvyfile/src/test.txt";
(GroovyObject)ScriptBytecodeAdapter.castToType(this, groovy.lang.GroovyObject.class),
"println", new Object[] {
((Object) (new Object[] {file}))), "text")});

For the sake of clarity I am not including all the other information that was decompiled (well.... because it's rather long). But to summarize, my two line Groovy script is convereted to 214 lines of decompiled Java code. Initially you might think that boosts well for Groovy and really shows the benefits of Groovy, but there is a lot of Groovy going on behind the scenes.

From my perspective this is the only current argument a Groovy skeptic can make: "well look at all that extra junk they are throwing in. Isn't that going to hurt performance?". And at the end it just might. I think it's obvious that Groovy bytecode probably won't run as fast as Java bytecode, but for me the benefits out way that disadvantage.

I by no means intended this to be an exhaustive list of Groovy benefits (for that I would recommend reading the excellent but lengthy article by Guillaume Laforge on the recent Groovy 1.5 features) . I just wanted to prove that the end result is no different. Hopefully people will respond with questions and criticisms and I can respond intelligently.

To me Groovy is sort of the legal steroids of programming. Those that use it have an unfair advantage, enabling them to deliver software quicker then their competitors and co-workers.

Tuesday, December 25, 2007

A bit of history. Americans original motivation

I absolutely love history. In fact outside of programming and basketball it has to be my favorite hobby (and yes programming to me is a hobby since I enjoy it so much). For Christmas my wife gave me the Illustrated Edition of "1776" by David McCullough. I enjoyed the original very much and am looking forward to reading it again along with the 140 images and 37 replicated source documents.

Learning new things I think is why I enjoy history so much. For example, in his new book, Author McCullough starts by including an image of what it regarded as our countries first flag: The Grand Union. Also fascinating was the quote by Alison Huber, "Independence from Britain was not as yet what Americans were fighting for, but rather what they felt their rights as freeborn Englishmen." It's real easy to forget something like this and just naturally think our fore fathers started fighting for independence immediately. Instead they were just fighting for the same rights their brothers had back in England.

Stayed tuned as I plan on posting as I read more of the book; or just hit the space bar in Google Reader if you don't care.

Wednesday, December 5, 2007

Google Readers Discover

As if I didn't have enough RSS feeds to read, Google Reader went ahead and recently added a neat little feature called Discover (or Top Recommendations). This new feature provides a short list of new feeds generated by comparing my interests with the feeds of users similar to me. In fact, according to the Help Center, it takes into account my current subscriptions as well as information from my Web History including location. It's actually pretty fascinating and I discovered several interesting feeds that I then subscribed to easily.

If you are already using Google Reader take a look at your list. If not, then consider using or switching to Google Reader; it's discovertastic!

Thursday, November 29, 2007

Using Groovy to work with Files

One of the best applications of Groovy I have come across so far is working with Files. Using Groovy to read data from a file can not get any easier. If you are a Groovy skeptic this is the post for you. Using the maven-groovy-plugin, which allows you to mix Java and Groovy code seamlessly, you no longer have any more excuses (go here for a maven-groovy-plugin how-to).

Recently I was writing unit tests in Groovy for my Java code and I needed to read in the contents of a file for comparison. In Java this would look something like this:


public class FileTest {
public static void main(String[] args) {
try {
String file = "/workspace/sandbox/grvyfile/src/test.txt";
String line = "";
StringBuilder sb = new StringBuilder();
BufferedReader br = new BufferedReader(new FileReader(file));
while ((line = br.readLine()) !=null) {
System.out.println("sb.toString() = " + sb.toString());
} catch (FileNotFoundException e) {
System.out.println("e = " + e);
} catch (IOException e) {
System.out.println("e = " + e);

If you are still doing this STOP RIGHT NOW! This boiler plate code took me about 5 minutes to write. Since it's not something I do super frequently I don't commit this syntax to memory, and therefore almost always have to reference the API to remember to use things like

Would you like to see the Groovy equivalent? Make sure you don't blink; you might miss it.
def file = "/workspace/sandbox/grvyfile/src/test.txt"
println new File(file).text

That is all folks. In fact if you want to test this real quick, use the groovy command line like the following:
>cd /workspace/sandbox/grvyfile/src
>groovy -e "println new File('test.txt').text"

For those new to Groovy, .text is essentially shorthand for calling the .getText() method on the File object. The method getText() is one of the dozens of new methods added to the JDK (see the GDK for more).

Read my comments in this post (Java: Laugh or Cry, Your Choice...) by Kit Plummer for another good application of Groovy. Here I use the List GDK methods minus() and unique() to decrease the lines of code from ~27 to ~2.

Wednesday, November 28, 2007

Impressive Grails Plugin Architecture

I just finished watching the video of Graeme Rocher explain the Grails Plugin Architecture while at the Grails Exchange in London recently (Graeme Rocher on the Grails Plugin Architecture). I got to say, while long at 53 minutes, it was well worth the time and was pretty impressive.

Some things I didn't realize was all the default core functionality in grails is plugin based; everything in grails is based on plugins. For example: spring, hibernate, internalionalization, domains, controllers, tab libraries, etc are all plugins.

On top of that it is really easy to create your own plugin (watch the video above or go here. Here are some of the things you can do with plugins that make them so powerful:

  • Add new methods, constructors, properties to any class at runtime
  • Perform runtime Spring configuration instead of depending on some static spring XML file that you wish you could change at runtime
  • Modify the web.xml on the fly
  • Add new controllers, domains, tag libraries, etc
Here are just a few plugins that already exist:
  • XFire - exposes a grails service as a SOAP service
  • Searchable - integrates compass and lucene search
  • Remoting - exposes a grails service over RMI, HTTP, or burlap
  • GWT - integrates grails with Google Web Toolkit
  • Acegi/JSecurity - adds security support for grails
  • JMS - exposes grails services as Message Driven Beans
  • Wicket/JSF/Tapestry - bring in different view frameworks
  • Dbmigrate - support sql migration
  • Static resources - helps offload the delivery of static resources to another web server
  • Jasper Reports - create jasper reports in grails
Go here for a complete list:

Wednesday, November 21, 2007

Best Groovy quote ever

I think this pretty much sums up Groovy:

"Groovy is executable psuedo-code"
Scott Davis


Friday, November 16, 2007

Javadoc equivalent for Grails (a necessity)

Oh yeah! Graeme Rocher and Marc Palmer have done an excellent job creating the Reference Documentation for the Grails Framework for version 1.0-RC1 (check it out This will be familiar to anyone that has referenced Java's API javadocs like I have for so many years.

This is an absolute necessity for Grails development IMO due to it's dynamicity (I think I just made that up). Outside of checking out the source, yuck, how else would you know which options are available? This is another piece of the puzzle before the official release of Grails 1.0.

Here is what the reference documentation covers:

  • Grails Commands - detailed usage information for the grails commands like generate-all, test-app, etc.
  • Constraints - explains all the current constraints available to Domains like blank, maxSize, etc.
  • Controllers - shows all the information available for controllers
  • Domain Classes - shows all methods available to consumers of domain classes like save, validate, find*, etc.
  • Plugins - information available for plugins
  • Services - explains things like scope and transactional
  • Servlet API - typicaly servlet stuff like request and response
  • Tag Libraries - information available for tag libraries
  • Tags - tags you can use in your GSP and I am sure, but not certain, in your JSPs.

Thursday, November 15, 2007

How to remote into Windows from Linux

You can easily use rdesktop to remote into a Windows machine from Linux. I am using Ubuntu 7.10 and rdesktop works fast and its easy. The default resolution is really small so here is my command to start it up specifying a different resolution.

rdesktop -g 1024x800 server

You can also specify the -f option for full screen mode, but beware it's not easy getting out of rdesktop full mode. Use CRTL+ALT+ENT to exit full screen mode.

Monday, November 5, 2007

New Amazon S3 plugin for Grails

Today, Catina Consulting announced the release of an open source Amazon S3 (Simple Storage Service) plugin for Grails with the following goals:

  • Host and manage file assets on Amazon S3 for storage and performance advantages
  • Provide easy mechanisms to reference S3-hosted assets in Grails applications
  • Make most efficient and cost-effective use of S3 hosting resources
Their first version appears to be rather useful with some excellent capabilities coming in the future. This first version focuses on managing user uploaded static content. Planned features include supporting different media types, custom bucket schemas, security integration, support for both REST and SOAP (currently only uses REST), and reporting on S3 usage.

Installation and configuration seem rather simple so it should be rather easy for Grails users to start immediately using this plugin.

What I think is the most interesting was their ability to reuse the JetS3t Toolkit which is written in Java. This just goes to show how groovy can really be the glue between Java and how developers can reuse all that existing Java code.

Go here to learn more about Amazon S3, which is an online storage web service providing unlimited storage through a simple web service interface (REST or SOAP). S3 aims to provide scalability, high availability, and low latency at cheap costs. It accomplishes this by using the same scalable storage infrastructure that uses to run its own global e-commerce network.

For example, Smugmug, a popular photo sharing web site, is using it to store and host pictures. For a simple cost analysis view this post by Jeremey Zawodny who contemplates using S3 to replace his backup server.

And finally, I can't leave the Rails community out of this either so here is an article on using the rails AWS::S3 library (this plugin is more feature complete than the grails plugin).

Wednesday, October 31, 2007

Using Groovy to easily avoid nasty NullPointerException

Groovy supports a pretty neat syntactic sugar operator to easily avoid the ugly NullPointerException: the question mark '?'.

Writing this in Java

if (name != null && param1 != null && param1.getUser() != null && name.equals(param1.getUser().getName()))
is now replaced by the much more readable Groovy
if (name && param1 && (name == param1.user?.name))
Amazing how a single character can improve readability that much and avoid potential NPEs. Also if you are curious about my use of == rather than the Java required .equals() see my post on More Groovy Sugar.

Most importantly I have inserted a hidden clue in this post and the first to solve the mystery will receive a free pop of their choice not to exceed 0.77 cents. The winner will be the first commenter with the correct answer.

Sunday, October 28, 2007

Using maven with Grails

By default Grails comes with an Ant build file to control your web application. For some of us this seems like a step backwards in technology (although apparently not for Graeme Rocher the Grails mastermind). Even though Grails doesn't support maven 1 or 2, you can get support for dependency resolution via Ivy (see Using Ivy for Dependency Resolution). Another option available is called Maven Tools for Grails (MTG). It sounds pretty promising and an improvement over Ivy, but their most recent release (v0.2) appears to work only with Grails 0.5.6 and 0.6; the current release of Grails is 1.0-RC1.

Grails vs Rails comparison

While following some of the Grails and Rails tutorials (Grails: The Definitive Guide to Grails. RoR: Creating a weblog in 15 minutes) I noticed a big difference on how they approach development. Consequently, I started a thread (Dynamic Domain classes) on the Grails user mailing list to confirm. What I found, thanks to Tim Pidgen, was that Grails is intentionally domain-centric (ie model-centric) whereas Rails is more database-centric. What's the difference? With Grails you modify the domain classes (models) and the database is updated automatically. So properties are explicitly defined in the Grails domain classes; no database modification. Conversely, with Rails you create your "empty" model class and after you modify the database (add new fields to a table) you can just refresh the page; no need to add variables to your models.

Not sure either one is right or wrong; just wanted to point out the differences because it is a pretty significant difference.

No more J2EE webapps

I got my start in my programming career over 7 years ago developing web applications as part of the intranet group for a Fortune 500 company. The group was switching from developing in Haht (I believe back then it was some type of vbscript) to Java (JSPs and Servlets). I joined the group at the moment they switched to Weblogic 5.1, JDK 1.3, and Oracle 8i (I think). It was a fast paced environment as we cranked out one internal application after another. Of course back then I wasn't the best web developer, but by the time I left I felt pretty confident in being able to hold my own (but humble at the same time).

One thing that always stayed the same throughout creating each one of those applications was the ability to rapidly develop them. What do I mean by rapidly develop? To me this means making a change and being able to switch to my browser and verify that change and repeating that hundreds of times a day.

That is how things were when I moved on 5 years later: (change + save + refresh) x 100s. Now it has been around 2 years since I have developed a real web application and for some reason that process has disappeared. For some reason my fellow J2EE developers have come to accept the process of rebuilding and hot deploying or even restarting the application server FOR EVERY CHANGE! Thousands or even millions of minutes are lost everyday by J2EE developers out there producing software like this. And to that I say, not good enough.

Maybe I am missing something; if so please enlighten me by commenting to this post. Take the JBoss Application Server (AS) 4.2.1 for example. I have tried finding better ways to deploy a WAR (exploded or bundled) on JBoss with no luck. The best I can come up with is increasing the JVMs PermSpace for better hot deployment (article), but I am still left with having to rebuild the WAR and copying it over. And sooner or later I have to restart the server. What a waste.

At one time there use to be a really slick maven 1 tomcat plugin made by that supported the ability to tell tomcat where your webapp was, preventing you from having to rebuild and redeploy. It was a huge time saver, but unfortunately this plugin is no longer supported (see here). If you are curious you can still get this plugin here thanks to Google Cache. The documentation has also been copied here.

Where does that leave me? Any language that lets me develop at a fast rate. Even if I lose tons of reusable components. I would imagine the time I save not rebuilding/redeploying more than makes up for reusable components and other goodies J2EE offers. In fact that has been the main reason for my personal quest to learn Grails and Rails. To me these languages offer the ability to deliver faster and cheaper and I believe this article supports that. If I had to start a new web project I would definitely look long and hard at either Grails or Rails.

Thursday, October 25, 2007

Effectively using Groovy Console in Grails App

Each chapter in The Definitive Guide to Grails continues to impress me. Currently I am on Chapter 4 which discusses The Application Domain. In this chapter the author uses the Groovy console within the grails app to test the domains to get some quick feedback. I got to say this ability is awesome! Not only could you do some quick testing, but I am sure it would be great for debugging purposes as well. Now obviously we want to keep testing in the console at a minimum and continue writing those unit tests, but that isn't until chapter 6. So until then here is how you can use the console in your grails app.

1) Already created a grails app: grails create-app bookmarks
2) Created at least one domain: grails create-domain-class Bookmark
3) Added some properties to the Bookmark domain (URL url)

Now cd into the bookmarks directory and run grails console. This will compile your domain class and make it available to the console. Then execute the following (CRTL + R):

def bookmark = new Bookmark(url: new URL(""))
println 'Bookmark url is ' + bookmark.url
You should see the following output:
Bookmark url is

Wednesday, October 24, 2007

Grails Tip: Enable SQL Logging

Here is a great tip while developing a Grails application to enable SQL logging (I would only recommend this in development mode).
In your grails project add the loggingSql = true property to the development closure and that is it. This was using Grails 1.0-RC1.

development {
dataSource {
dbCreate = "create-drop" // one of 'create', 'create-drop','update'
url = "jdbc:hsqldb:mem:devDB"
loggingSql = true

Then after starting your app (grails run-app) the SQL will be displayed. I was actually surprised for some reason when the list action was doing a specific select statement like "select title, author from book" rather than "select * from book".

Hotswap ability with JavaRebel

Here is a good article on using JavaRebel to reload your webapp changes without a hotdeploy like Rails and Grails do.

A Groovy switch/case example

Below is an example of Groovy's switch/case feature taken from The Definitive Guide to Grails by Graeme Rocher. I am not a regular user of Java's switch/case feature, but if it had been this way perhaps I might have.

switch (x) {
case 'James':
println "yes it is me"
case 18..65:
println "ok you are old"
case ~/Gw?+e/:
println "your name starts with G and ends in e!"
case Date:
println 'got a Date instance'
case ['John', 'Ringo', 'Paul', 'George']:
println "Got one of the Beatles"
println "Don't know"

More Groovy Sugar

Joe Kueser has some excellent posts on Groovy features (What Makes Groovy...So Groovy and More Groovy Goodies) and I would like to attempt to build on them. He has been nice enough to let me borrow The Definitive Guide to Grails, which so far has been an excellent resource for Groovy and Grails (probably one of the best technical books I have read in awhile).

Expando Objects
Joe does a nice job of explaining this handy new class. Here is another example taken from the Grails book by Rocher:

fred = new Expando()

fred.firstName = "Fred"
fred.lastName = "Smith"

fred.age = 40
fred.happyBirthday = {

assert fred.age == 41

You can easily play around with this code with groovy's console (/GROOVY_HOME/bin/groovyConsole). As you can see Expando allows you to define an object, its properties, and its methods at run time. Keep in mind that a method is defined by setting a closure to a property that can be later called like a regular method. One immediate use I can see for Expando is in unit tests.

Groovy's == operator
This is very important for existing Java developers. Groovy's == operator is different than Java's in that it does not evaluate object identity, rather it delegates to the object's equals method. To accomplish object comparison, Groovy introduces a new is method:

The Groovy Truth
Term used by Rocher in the Grails book and coined by Dierk Koenig, that explains the Groovy concept of what is true and what is not. Here is an example of what can be passed to if statements in Groovy and will evaluate to false:

  • A null reference
  • An empty or null string
  • The number zero
  • A regex Matcher that doesn't match
This makes those nasty Java if statements much cleaner.

if (str != null && str.length() != 0 )

now becomes

if (str)

More Mt. Dew sugar to come.

Tuesday, October 23, 2007

Enabling remote access to JBoss 4.2

Today I had an issue remotely accessing my JBoss instance running on another machine. Unknowingly, JBoss 4.2 binds specifically to by default (see below for me details). Thankfully they had a simple solution; just append -b to your startup script to bind to all interfaces. So to start JBoss on linux when I know I want to access it remotely I do:

./jboss/bin/ -b

ReadMe.html content on this subject:
"JBossAS now binds its services to localhost ( *by default*, instead of binding to all available interfaces ( This was primarily done for security reasons because of concerns of users going to production without having secured their servers properly. To enable remote access by binding JBoss services to a particular interface, simply run jboss with the -b option. To bind to all available interfaces and re-enable the legacy behavior use -b In any case, be aware you still need to secure you server properly."

Sunday, October 21, 2007

Great JetGroovy plugin feature for Idea+Grails

Just started using the JetGroovy plugin in Idea and I have to say initially it Rocks! Included is a screenshot of the plugin in Idea version 7 after I created a domain (aka model). Notice how there are nifty buttons for that domains Controller, Views, Domain Tests, and Controller Tests. I was constantly using this ability even in the 5 minutes it took me to create my Hello World grails app. Nice work guys.

Tip for using Grails in Idea

Recently I tried creating my first Grails application using the JetGroovy plugin available in Idea (version 7.0). However, I have Linux (Ubuntu 7.10) and you don't get those nice little icons to start Idea when you install it. Consequently when I tried to create a new Grails project I received the following error:

grails: JAVA_HOME is not defined correctly; can not execute: java

How in the world is that possible I thought to myself? What half decent java programmer doesn't have JAVA_HOME set? Oh but then I remembered my special start script responsible for starting Idea. Idea requires the variable JDK_HOME to be set, but Grails within Idea needs JAVA_HOME. Therefore, here is my new script I use to start Idea 7 which allows me to create new Grails projects. And don't forget Idea 7 on Linux requires JDK 1.6.

sh -c 'export JDK_HOME=/workspace/java/jdk1.6.0_03;export JAVA_HOME=/workspace/java/jdk1.5.0_12;/workspace/java/idea-7361/bin/'

Saturday, October 20, 2007

Performance tuning Java

Here is a centralized location for information on performance tuning the JVM:

Specifically, here is a great white paper on tuning ideas that include some great examples.

I have to admit I am rather new to this subject, but am really interested in learning more. From what I have read and also learned from my co-worker Travis Chase, the best and simplest improvement you can make is running your JVM with the -server option. Most likely your JDK came with the default -client set which starts up faster for development reasons, but should be switched to -server for better performance in production environments. However, before you start performance tuning be mindful of the Ergonomic settings which automatically set your defaults. For example for Window users (32-bit) the -client option is automatically set. Here is some more information on Ergonomics for Java 5.0.

Friday, October 19, 2007

Upgrading to latest Ubuntu Gutsy Gibbon (7.10)

Here is the information needed to upgrade Ubuntu from 7.04 to 7.10:

Friday, October 12, 2007

Linux generic start and stop scripts

If you are following my twitter account, you will notice that I recently switched to Ubuntu and will never look back. Sometimes I find myself having to create start and stop scripts for weblogic, glassfish, hudson, etc. All these scripts are generic enough that you just copy and paste and modify some names. But I don't do it frequently enough to have memorized the syntax. Therefore I want to document and explain start and stop scripts that are generic enough they can be used for almost anything.

Next you will see the exact start and stop scripts we use in our Continuous Integration environment to manage hudson.

Start Script -
nohup nice java -jar hudson-1.136.war --httpPort=8282 > ./hudson.out 2>&1 &

Stop Script -
kill `ps -ef | grep hudson-1.136.war | grep -v grep | awk '{ print $2 }'`

Start Script explained
nohup nice
I don't claim to be an advanced linux user, so don't expect a master's thesis on this one. Nohup on Wikipedia tells us that nohup "is a unix command that is used to run another command while suppressing the action of the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. It is most often used to run commands in the background and output that would normally go to the terminal goes to the file called nohup.out if it is not redirected". Nice allows you to run a program with a modified scheduling priority with -20 being most important and 20 being less important. I believe the default when using nice without a value is 0.

The '>' command
Takes the output from my java command and places it in the file ./hudson.out.

The '2>&1' command
2> is standard error and &1 is standard output. So combined it says take standard error and put it in standard output, which the previous command said take standard output and put it in ./hudson.out. So together these two commands put standard output and error in ./hudson.out.

The '&' command
When appending it at the end like it is, it means runs this process in the background.

Stop Script explained
Uses the Process Status (ps) command and grep to search for a process that includes the text 'hudson-1.136.war'. Then it uses awk to split out the output from ps to get the Process ID. Once the Process ID is found it passes it to the kill program to stop the daemon (pipes rock!). This method of using kill to stop a process is rather brute force and does have some flaws if you don't use unique text to search (multiple users running hundreds of programs). Most programs, say weblogic, for example should already have a stop script, so obviously prefer those over my example.

So what if you want the startup script to begin at boot time? Well, add a soft link pointing to your startup script (ln -s /home/jlorenzen/bin/ in /etc/init.d/. Then use the update-rc.d command to add it at boot time (update-rc.d softlink_name defaults).

Update: Do to this posts popularity, I created a github account and uploaded these scripts so they can be easily shared, referenced, and forked. See for more information.

Ubuntu JeOS (Just Enough Operating System)

Back in September, Ubuntu announced a new addition to the family called JeOS (Just Enough Operating System). Ubuntu JeOS (pronounced "Juice", no not the Barry Bonds Juice that can be denied as not knowing) , "is an efficient variant of the popular desktop and server operating system, configured specifically for virtual appliances". The article goes on to state, "JeOS Edition has been tuned to take advantage of key performance technologies of the latest virtualisation products from VMware".

Looks really interesting and actually comes at a good time as I have been playing around a lot with VMware, DSL (Damn Small Linux), and Ubuntu Server.

To read the entire announcement go here.

Tuesday, October 9, 2007

Compressing ginormous files

I know most of my fellow linux coworkers already know this trick but since I am fairly new to linux and I know others are I am going to show how one can compress ginormous (quote from the movie "Elf") files.

First run: tar -cf filename.tar /directory/*
Then for best compression run: gzip -9 filename.tar

The to uncompress the file run: tar -xzvf filename.tar.gz

Saturday, October 6, 2007

Comparing Open Source Web Service Stacks

Here is one of the best articles I have read comparing the various open source web service stacks. Previously I have always referenced this page, which is still an excellent source of information. The author interviews lead developers from each project: Apache Axis2, Apache CXF (previously known as XFire), Spring Web Services, JBoss WS, and Sun's Metro.

First my opinions. Axis1 was one of the first open source stacks available and Axis2 was suppose to be a complete overhaul. From other articles I have read the performance isn't that great and my first use of it wasn't a good experience. I have had really good luck with XFire and really like how it is just a jar that you can include in your WAR. Spring Web Services is really new (they just released version 1.0). I really like the spring products and wouldn't hesitate to try this one. Their documentation is really good and they emphasize a top-down approach (which is honestly the best way, but not the most fun). Not sure why anyone would use JBoss WS if it isn't portable to other containers. Based on their wiki they only state it works in JBoss. Sun's Metro is making a lot of headway and I would recommend it to anyone. It seems to be the most mature in implementing the newer WS-* specifications and boasts the ability to interoperate with .Net services.

Back to the article. Here are some highlights for those not wanting to read the entire article:

  1. CXF can support returning JSON
  2. Use SXC to improve JAXB performance.
  3. Axis2 is the only one supporting WSDL 2.0
  4. All except Spring-WS and JBossWS implement WS-Addressing and WS-Reliable Messaging
  5. Metro is the only stack with support for WS-AtomicTransaction and WS-Coordination, which are hooked up to J2EE/Java EE transactions.
  6. CXF supports REST via annotations similiar to JSR 311. Spring-WS doesn't support REST.

Friday, October 5, 2007

Grizzly Port unification

Looks like one of my anticipated features in Grizzly is finally here in their latest version 1.6.1: Port Unification. According to this javalobby article, port unification has been implemented and can now be used in glassfish v3. For OpenESB users this means consolidating the HTTP ports between glassfish v2 and the HTTP BC. What this also means is being able to accomplish the same thing in the RSS BC since we use grizzly to service the HTTP GET requests for feeds.

One of the nice benefits this adds to glassfish v3 is the ability to now consume only one port verses 2 or 3. Now phobos, comet, and jruby can run on the same port and grizzly can determine the correct Adapter.

To stay current with this RSS BC enhancement watch issue #8:

Tip to improving glassfish performance

Today I was reading an entry (Customizing Glassfish v2 with 23 unpublished properties) from the Gestalt Shared Feed about hidden properties in glassfish v2. One very interesting tip to improve performance for glassfish would be to set the enableSnoop to false. Basically setting this property to false stops grizzly from logging the requests/responses to the log file. See the rest of the article on how to actually set the property in glassfish.

Monday, October 1, 2007

Using the OpenESB J2SE version and netbeans

As I mentioned in JBI deployment options, OpenESB can run as a standard J2SE application. This is a nice option that has some advantages such as getting started quicker without the need of downloading the rather large (300+MB) OpenESB bundle that includes glassfish/openesb and netbeans. The JBISE version is only 4.3MB. For those of you not needing a J2EE container this might be a valid option.

The only other missing piece is the tooling support to create Composite Applications. This is included in Netbeans v6 which is a part of the large OpenESB bundle. But since you are not downloading that you need to ability to get netbeans v6. Here is the netbeans v6 nightly builds location:

Good luck and happy downloading.

Wednesday, September 26, 2007

Glassfish v3 and JavaEE 6

More than likely most haven't gotten the chance to use JavaEE 5.0 yet, but I think it's important to look ahead at what is coming down the road. I believe, container-wise, JavaEE 6 is going down an excellent path of easier development by making their container as small as possible (15k) and startup time super fast (less than 2 seconds). How did they achieve that? Modularity.

For some reason I just realized that the Reference Implementation (RI) for JavaEE 6.0 is Glassfish v3. Skim this presentation about the goals of JavaEE 6.0 (roughly about 15 quick slides). Also, here is a walk-through on how to use Glassfish v3 (install jruby container, web container, etc).

Just for the record, also keep in mind that JavaEE 5.0 is implemented by Glassfish v2.

Saturday, September 22, 2007

How to effectively use SNAPSHOT

Recently I showed how you can use the maven-release-plugin to create a release for your project. Now I would like to explain how to use maven to effectively use SNAPSHOT.

First what do I mean by SNAPSHOT? SNAPSHOT is a special version in maven that indicates the latest code; typically TRUNK or HEAD in your source control. With this version, maven will automatically grab the latest SNAPSHOT every time you build. On the other hand, when you are using 2.0, once maven has downloaded this artifact, it never tries to get a new 2.0.

Why should you use SNAPSHOT? You should use SNAPSHOT for rapidly moving code where bug fixes and enhancements are coming fast. Another reason is you should never require users of your project to checkout and build your code. EVER! I would venture to say that 50% of the open source projects I have had to checkout and build, have not initially built.

How to create a SNAPSHOT?
First you have to find a webserver to host the artifacts. I have typically used apache running on linux. I first create a folder under / called snapshots (owner:group equal to repoman:repoman) and then create a softlink (ln -s) under /var/www/html called snapshots (owner:group being root:root). So now you should have /var/www/html/snapshots --> /snapshots. For some examples of some public SNAPSHOT repositories check out Apache's and Codehaus.

Second you need to update your parent POM in order to properly use the maven-deploy-plugin. First make sure the version you are using includes -SNAPSHOT. For example something like 0.9.2-SNAPSHOT.

Third add the distributionManagement section to your parent POM to look something like this:

<name>Maven2 Snapshot Repository</name>
This will use scp to upload the artifacts to the url //host/snapshots. The element that needs to receive the most of your attention is <uniqueVersion>. This value can either be true or false. When it is false the artifacts created will not be unique and will look something like this each time: myproject-0.9.2-SNAPSHOT. Use this to reduce disk usage. When it is set to true a unique version is created everytime. For example myproject-0.9.2-20070922.011633-1.jar and then the next build that day would be myproject-0.9.2-20070922.011633-2.jar.

Finally, the last thing is to set the username and password of the repository in your $USER_HOME/.m2/settings.xml file. This will be used by scp for authentication. To do this add the following in your settings.xml file:
That is it. Now you are ready to run mvn deploy.

Wednesday, September 19, 2007

JBI Deployment Options

Recently, I have had multiple discussions with different individuals concerning possible JBI deployment options for their projects. Is Glassfish required? Do I need a JavaEE container? Do I need Netbeans? Is it packaged as a WAR? How big is the runtime footprint? If I am already using JBoss, how can I take advantage of JBI? Why is the OpenESB installer so large? Even with every project having its own specific needs, JBI has an array of potential solutions for each one. So if you are new to JBI or just curious how to use it, please contiue to read while I describe the various options.

First, I have fortunately had the pleasure of extensively using two of the most popular JBI containers currently available: Apache ServiceMix and Sun's OpenESB. The following is the landscape as I see it based off my experience.

Apache ServiceMix Options

  • Can run as a standard J2SE application. To use this version download the container from here:
  • Bundled as a WAR, making it deployable to your existing JavaEE container. The WAR is also available for download from the same address above.
Sun's OpenESB Options
  • Can run as a standard J2SE application. Although it's a little more untested than it's other options. Go here for a How-To Guide on where to download the container and run it.
  • Comes bundled in an All-In-One install that includes the latest Glassfish, OpenESB, and Netbeans 6.0 for tooling support. Go here to download this version. Before you flip out on the download size (300+MB), let me provide an explanation as to the size because this seems to be the version receiving the most attention by Sun; and it's actually the version my team uses. Along with the items mentioned above, this bundle also includes all the Sun components and the latest Community Partner components. I believe the main benefit to having an All-In-One install is previously we had to download each project individually and usually the different versions where incompatible (the BPEL tooling support in Netbeans didn't match the BPEL Service Engine capabilities downloaded with OpenESB). It's important to note that with this option Netbeans is only required to compose Composite Applications and not to run OpenESB. Finally, the Glassfish and OpenESB combo is a little deceiving in that it's not like starting two applications. OpenESB is basically exploded out in one of the Glassfish domains, much like a WAR would be. So when you start a Glassfish domain, it handles starting OpenESB.
  • There exists a WAR file for IBM Websphere located here and work has been done to integrate with JBoss (read here for more information).
Which one is right for you?

Most projects fall into two categories: one that already has a JavaEE container and ones that don't. If you already have a JavaEE container, then you can use the ServiceMix WAR or run the J2SE standalone version of OpenESB. If you don't have one, then obviously you can choose among all the options. If I was forced to give a personal recommendation, I would recommend when possible using the Glassfish/OpenESB package. This gives you complete capability of building Composite Applications consisting of Web Services running in Glassfish and orchestrating them using OpenESB and the BPEL Service Engine and then integrating with other protocols such as RSS, SIP, UDDI, and XMPP. And the tooling support in Netbeans is well worth it.

For further questions please visit the FAQ on or feel free to drop me a comment. You can also subscribe to my shared JBI RSS Feed.

Friday, September 14, 2007

How to create a release using the maven2 release plugin

If you haven't figured out how to simplify creating a release for your maven2 projects then you need to look into the maven-release-plugin. This powerful plugin helps shorten the time it takes when creating a release and we have used it extensively on our open source projects: RSS BC, SIP BC, UDDI BC, and the XMPP BC.

Kicking It Old School
Back when we were using maven1 we actually used a sed script to update the versions in the project.xml and files. Boy those where the days; how I don't miss them. However, I was still impressed with it so here you go. Create a script named swap:
cp $1 $1.backup
sed -e s/"$2"/"#3"/g $1 > temp
cat temp $1

Browse to your project and run:
find -name '' -exec ~/swap {} 1.1.0-SNAPSHOT 1.1.0 \;
find -name 'project.xml' -exec ~/swap {} 1.1.0-SNAPSHOT 1.1.0 \;

It was effective and did the job (in fact it's easier to use a perl script), but you still had to create the tag/branch and commit. Also with maven2 POMs you have other values that have to be updated like the <scm> information.

How to use the maven-release-plugin
First, you need to clean up your POMs. Here are three basic guidelines that will make your life easier when managing them:

  1. Avoid declaring groupIds and versions where it is not required. For example in child POMs, if the groupId and version are the same as the parent, you don't have to define your own groupId or version. By default it inherits from the parent.
  2. If you do have to declare versions, use the section of your parent POM. This helps define your downstream dependencies and prevents the child POMs from having to declare the versions that are shared among the project.
  3. Use properties to define other common versions.
For a real example, view the RSS BCs parent pom, and subsequent child poms: extensions, jar, and zip. Notice the use of properties and dependencyManagement in the super pom. Also note how the child POMs don't have to declare versions for inner project dependencies that are defined in the parent POM under dependencyManagement.

Now that you have your POMs cleaned up it's time to use the maven-release-plugin. It doesn't actually require these changes, but I am anal so sorry.

Make sure your parent POM has the <scm> section describing the projects source control location.

Get a clean copy of your project. The maven-release-plugin will not run if you have locally modified files; including IDE files or the target folder.

Run mvn release:prepare -DdryRun=true
This will walk you through a dry run and you can view the temporary POMs it creates to verify you did everything correctly.

Run mvn release:clean release:prepare -Dusername=johndoe -Dpassword=passwd
This will actually commit a tag with non-snapshot versions of your project and also increment all your versions to the next release. So for example, if your current version is 0.9.1-SNAPSHOT, it will commit a tag with 0.9.1 version, and update the trunk POMs with 0.9.2-SNAPSHOT. Of course when using the prepare goal you are prompted for the release numbers and next release numbers.

Run mvn release:perform
The perform goal basically runs deploy and site-deploy. This step is optional and I typically don't run it.

One gotcha is if your project has a SNAPSHOT dependency on an artifact outside your project, the release plugin doesn't handle that (or at least I haven't figured it out). The prompts seem to ask questions about what version they need to be, but never actually does anything with the information. Hopefully this will be fixed in future versions. In the mean time, use properties, and when running mvn release:prepare use the -D option to specify the version and then manually update the tag and trunk pom to reflect the real version. So something like mvn release:prepare -DdryRun=true -Dcommon.jbi.runtime.version=0.9.2.

Windows Users
The other issue you might have is if you are using Windows. Since I am using Linux the svn commands are already installed and I use them frequently. And since the release plugin uses the svn commands to do its work, you will need to install the svn client commands in order to it in DOS. To do that go here, go down to the Windows section, and click Win32 packages built against Apache 2.2. In there download and install the svn-1.4.6-setup.exe. After installing it, open up a new DOS window and run svn help.

For further tips and tricks read the Gestalt Developers Guidelines for creating a release using the maven-release-plugin.

Related Articles

Friday, August 24, 2007

Favorite svn commands

Recently I switched from Windows to Linux, or more specifically Ubuntu 7.0.4. With a couple of minor issues, everything is working great so far. One of the main reasons for changing was to be faster and better at what I do, and I think linux can help me achieve some that.
One common thing I feel makes linux developers faster is knowing commands and not requiring GUIs. GUIs take a long time to load and refresh compared to just opening a file in vi or vim. On windows I loved SmartSVN and would recommend it to anyone; in fact I have had to install it on linux until I have been converted. At the same time I have enjoyed learning the svn commands, which by the way are 100 times easier than cvs commands. Most cvs commands require options to be effective (cvs update -Pd). Not so with svn.

Here is a list of favorite svn commands I have come to love. Also included are recommendations from friends.

  1. svn help . For example svn help update
  2. svn status. List modified or uncommitted files
  3. svn update. Get the latest code and update your modified files
  4. svn commit filename -m "Commit Message". Commit the file. filename is optional
  5. svn diff. Do a diff on locally modified files.
  6. svn diff -r M:N. Performs a diff on the revisions M and N
  7. svn merge -r M:N. Revert back to a previous version
  8. svn log -v. Gives you a verbose log of everything that has happened
  9. svn st | grep "?" | awk '{print $2}' | xargs svn add. Handy command for those who go days without committing and need an easy way to commit uncommitted files.
  10. svn propedit svn:ignore. Tells subversion to ignore certain files or directories.
  11. svn revert filename. Takes the filename out of source control. Handy when commnd #9 adds files you didn't intend to add.
Also there are shortcuts to most of these subcommands. For example svn status is also svn stat or svn st. Just run svn help to get a list of shortcuts.

Finally, don't be disappointed if you are a windows developer. You can use svn in cygwin the same way.

Monday, August 20, 2007

Using the JBI JavaEE ServiceEngine

Update April 10th, 2008
An update has been provided on how to use the Java EE SE in the latest version of Netbeans. Please go here to read this update.

In order to familiarize myself with different JBI components I would like to walk through an example using the JBI JavaEE Service Engine written by Sun. So what is the JavaEE Service Engine? It's a highly useful JBI component providing a bridge between the web container (glassfish) and the JBI container (OpenESB), or more specifically the NMR (Normalized Message Router). It's useful because it allows EJBs and Servlets, packaged as web services, to communicate directly with JBI components and vic versa. Consequently, this increases performance since the request/response doesn't have to travel in and out of the HTTP BC and the glassfish Servlet container.

So if you are writing EJB 3.0 web services, you have alot to gain by using BPEL and JBI in general, and you need to look into using the JavaEE SE. The following is a simple example of how to use it.

If you haven't already, first start out by downloading the latest OpenESB installer which includes Netbeans 6.0. Then follow this video tutorial to create a Composite Application consisting of a BPEL process invoking an EJB web service (but not using the JavaEE SE yet). This will help us create our web service and get familiar with BPEL and Netbeans. If you prefer to skip this step I have uploaded the EJB Module, BPEL Module, and Composite Application for convenience. After completing this step your casa file should look like this (in netbeans, right click on the CompositeApplication and click Edit Application Configuration):

Notice there are no endpoints for the JavaEE SE. Here is the sequence of events when running the test included in the HelloBPELCompositeApp:
http client --> inbound HTTP BC --> BPEL SE --> outbound HTTP BC --> Glassfish Servlet Container --> invoke Hello web service --> response.

The next step is to actually utilize the JavaEE SE advantages. This only requires adding the EJB module as a JBI module to the HelloBPELCompositeApp. In JBI you can add multiple JBI Modules (Service Units) to Composite Applications (Service Assembly). In netbeans, right click on HelloBPELCompositeApp and click Add JBI Module. Select Hello, which is the EJB Module. If you expand the JBI Modules directory under HelloBPELCompositeApp, you should see Hello.jar and HelloBPEL.jar. Before we can redeploy we first must modify the casa file to remove the existing connection between the outbound HTTP endpoint and glassfish. Reopen the casa file (in netbeans, right click on the CompositeApplication and click Edit Application Configuration), and highlight the line going between the HelloRole_partnerRole Consumer to the HelloPort Provider. Your casa file should look like this now and this verifies that we are going through the JavaEE SE:

April 8th, 2008 Update
Since this post is pretty popular I have an update since this post doesn't work with the latest version OpenESB+Netbeans. Not only do you have to remove the line as described above, but you also need to remove the SOAP Port, otherwise you will receive an " Already bound: 8080". So in the image above highlight and delete the HelloPort.

Also in newer versions of Netbeans access to the CASA file is done by double clicking on the Service Assembly file under your Composite Application project.

Rebuild HelloBPELCompositeApp by right clicking and choosing Clean and Build. Then undeploy and deploy HelloBPELCompositeApp. Finally rerun the test and it should pass. Again we know the JavaEE SE is being used based off the casa file. The new sequence of events are:
http client --> inbound HTTP BC --> BPEL SE --> JavaEE SE --> invoke Hello web service --> response.

It should be obvious where the performance improvement is located. That is what makes the JavaEE SE so powerful. For convenenice, here is the final netbeans Composite Application project with the modified casa file.

If you are curious to know what netbeans was doing under the covers for us when creating the EJB Module Service Unit here is a quick explanation. In netbeans and File view you can expand the build directory under HelloBPELCompositeApp. Next expand the Hello.jar service unit. There you will see the jbi.xml and an empty sun-resources.xml. The jbi.xml file defines the endpoints the JavaEE SE must activate. These endpoints will be used by the BPEL SE consumer endpoint. Also interesting is it includes a binary of the Hello Service (Hello.class).

Wednesday, August 8, 2007

Setting up a simple maven2 project in less than 1 minute

Ever need to create a new maven2 project? Was your next step to copy and paste an existing maven2 project and rename all the directories, package folders, and oh yeah don't forget to remove those SCM (cvs/svn) hidden directories. That's not all, don't forget to update the pom's groupId, artifactId, and everything else under the POM sun.

Using the maven-archetype-plugin you can create simple projects in a matter of seconds. "Archetypes are a simple and useful way to bootstrap new development across your organization, and urge your developers to follow a similar project pattern. Archetypes are a template of a Maven project used to generate skeleton layout for projects of any desired type in a consistent way" (Maven: The Definitive Guide).

The default archetype is quickstart, and generates a simple Java project with some source and a unit test. Here is how you can use the quickstart archetype to create a maven2 project in seconds saving you from the copy/paste world:

mvn archetype:create -DgroupId=com.gestalt.jbi.rss.binding -DartifactId=rss-binding-installer

Thats it! Next you can run mvn clean install and you now have a simple Java project created.

If a simple J2SE project isn't what you need then check out these other 10 archetypes. Most notably are:

  1. maven-archetype-archetype - used to create a simple project that can be used to build other archetypes
  2. maven-archetype-j2ee-simple - build a simple j2ee project
  3. maven-archetype-mojo - in maven2, mojos comprise a maven plugin, so this archetype creates a project that gets you set to build your own maven plugin
Plus there are many many more available in the open source community. For example when working with Apache ServiceMix and maven2, use their maven archetypes to build Service Engines or Binding Components. They also have archetypes to help simplify creating Service Units/Service Assemblies for their various components. Sun also has support for archetypes to create components as well.

Most common WSDL stumbling block

When it comes to helping people debug WSDL issues, the #1 overlooked and misunderstood problem is usually whether to specify type or element as the attribute to the element. If you are creating web services and defining WSDLs you must understand this significant difference as it will effect the consumers of your services.

All my examples and information where referenced from the book Building Web Services with Java. I would highly recommend this book.

Simple WSDL
Let's first begin with snippets from a simple WSDL.

<definitions name="PriceCheck">
<xsd:element name="sku" type="xsd:string"/>
<xsd:complexType name="availabilityType"
<xsd:element ref="sku"/>
<xsd:element name="price" type="xsd:double"/>
<xsd:element name="quantityAvailable" type="xsd:integer"/>
<xsd:element name="StockAvailability" type="availabilityType"/>
<message name="PriceCheckRequest">
<part name="sku" element="sku"/>
<message name="PriceCheckResponse">
<part name="result" element="StockAvailability"/>
<operation name="checkPrice">
WSDL Parts
A part element is made up of two properties: the name of the part and the kind of the part. The name property is represented by the name attribute, which must be unique among all the part child elements of the message element. The kind property of the part is defined as either a type attribute (a simpleType or complextType from the XSD schema type system) or an element attribute (also defined by referring to an element defined in the XML schema). You can't use both an element attribute and a type attribute to define the same part.

The choice of using element or type when defining the part is very important. The most common mistake is using the type attribute and referencing an XSD element or using the element attribute and referencing an XSD simpleType or complexType.

Use of element
When you use the element attribute, you're specifying that the SOAP should be precisely that XML element. For example, the PriceCheckRequest example specifies that the XML element named sku must be used as the body of the messsage. Here is a snippet of what the SOAP would look like:

Note how the SOAP contains exactly the specified sku element. The element attribute should be used to define the type of the part when the Web service is meant to be document oriented (which is defined in the binding). Whenever the element attribute is used, its value must refer to another global XML element defined or imported in an XML schema.

This not only applies to requests but responses as well. For example, here is what the SOAP would look like for PriceCheckResponse:


Use of type
The PriceCheckRequest could have been built differently, using a part defined with the type attribute, like this:

<message name="PriceCheckRequest">
<part name="sku" type="xsd:string"/>

Here is an example of the SOAP using the RPC-style where checkPrice is the name of the operation defined in the WSDL:

<checkPrice xmlns:xsi="">
<sku xsi:type="xsd:string">123</sku>
That is the difference between defining your part as an element or type. The most common style to use is document oriented and therefore the parts must use elements. If you use type in your parts, you need to use the RPC style.

Unfortunately all this isn't well documented. However there is good news. In WSDL 2.0 message and part elements have been removed. Instead you would use the names of the XML element declarations directly in the operations input, output, and fault messages.

Test Driven Development ROI

Ever think about the true benefits of tests and the value they provide you and your company? This article basically challenges developers to consider the ROI (Return On Investment) of every test. It has had a big impact on my software development habits by making me examine the benefits vs. the costs of writing tests.

Here is one of his most interesting comments: "... the developer is concentrating on testing before "coding" - the primary function is hence the development of tests, leading to a situation of "test-oriented development. This is where the production of tests becomes the overriding concern and output of a team, with the development of required functionality being secondary. When this occurs, the design, quality, and scope of the tests all become greater than that of the system actually being created". I am a firm believer in unit tests, but I hope I never fall into that category. We have a saying here at work, "I can get you about 90% confidence, but it's going to cost a lot to get that other 10%".

Oh yeah, its now Test First Development.

Also here is a follow up article to the original link above: When TDD Goes Bad #2. In it the author explains Mock oriented development and the lack of integration tests.

Wednesday, August 1, 2007

My de facto standard on WSDL styles

Here is my de facto standard reference on WDSL styles; bookmark it! When I first started writing Web Services I never knew their were 2 styles and 2 uses, or even that there was a style. As I gradually learned more about WSDLs it was difficult to find a good explanation of the different combinations. This article, written by Russel Butek on IBM developerWorks, explains how you determine which combination of style and use to choose. He provides advantages and disadvantages of each and shows WSDL and SOAP messages for each combination.

Overall when creating a Web Service you have 4 style/use options:

  1. RPC/encoded
  2. RPC/literal
  3. Document/encoded
  4. Document/literal
Along with these four is a recently new pattern which is commonly called document/literal wrapped.

Please read this article if you are unfamiliar with the different styles and uses. In general the most common style used is document/literal wrapped with document/literal in second. Most newer SOAP Stacks actually don't support RPC anymore; for examlpe cxf (aka xfire) and axis2.

Monday, July 30, 2007

A "new" way of hardcoding

We are all familiar with hardcoding values when programming; mostly out of laziness or we are just not aware of potential solutions based on industries best practices and experience. There are infinite ways to hardcode values. Some are temporarily acceptable based on the cost it would take to change it. However, the majority of hardcoded values should be avoided as it makes your class less reusable, brittle, and the other 500 obvious bad reasons.

A few common examples to make my point:

URI uri = new URI("");
File file = new File("/home/jlorenzen/glassfish.log");

or my personal favorite pet-peeve:

<a href="">Downloads</a>

The problem with my first two examples, is that when defined in another class as say instance variables, everyone who uses that class is now forced to those specific values. Some typical solutions include putting values in a database, properties file, var args (main), or System Properties (-D). For my HTML <a> example, always use relative paths: <a href="../downloads/download.htm">Downloads</a>l. Keep in mind that when you use a String and it's not a constant, more than likely you are hardcoding some value.

Now for all you experienced Java programmers, you may not be aware that you are hardcoding values everytime you use the Java keyword "new". When instantiating a new class, you are basically forcing users of your class (most importantly your unit tests) to use that implementation. This is what makes the Factory Pattern so useful and common. But we don't need a factory everytime we need to create a new object. An alternative is practicing Dependency Injection (Inversion of Control). DI is a way to inject an object into a class, passing the control of creating a class to someone else. An easy way to explain DI is its similar to Java's terms IS-A and HAS-A, but instead I refer to it as GETS-A. For me the most important advantage of DI is it easily allows you to write unit tests using mocks objects. Some popular DI containers are Spring, Google Guice, and PicoContainer.

Here is a naive example of code you might write today:

public class MovieManager {
MovieFinder finder = new MovieFinder();

public Movie findMovie(String zip) {
return finder.get(zip);
Now anyone wanting to use MovieManager is forced to use the MovieFinder class. This makes unit testing this class difficult without using reflection (no thanks). The alternatives are using constructor or setter injection, or passing it as a variable into the findMovie method.

In summary, anytime you instantiate a new object, think about whether or not you want to limit users of your class to that implementation. DI has revolutionized my programming and if you practice it enough your code consequently gets cleaner and more usable.

Tuesday, July 24, 2007

How to capture logging output in unit tests

When writing unit tests for java, its extremely valuable to view the log statements produced by your unit tests and java code. The following is a brief introduction on how to configure maven1 and maven2 projects to capture logs.

The maven-test-plugin is used for running unit tests in maven1 projects. It is best to configure this plugin at a global level in your file located under your $USER_HOME.

First add the following to your $USER_HOME/ file:

log4j.configuration=file:/c:/Documents and Settings/jlorenzen/

Second add a file under your $USER_HOME directory. Mostly likely this will include a ConsoleAppender. By using a ConsoleAppender the maven-test-plugin will capture the logs and write them to the console. However its cleaner if you set the property maven.junit.usefile=true in your file. This will put all your logs in the .txt test report file.

Unfortunately things are a bit different for maven2 projects. You no longer use the maven-test-plugin but rather the maven-surefire-plugin. The following example will use java logging.

To get started open up your project's parent pom.xml and add the following for the maven-surefire-plugin.

Next you need to define the value for the variable ${logging.location}. You do this in your settings.xml file which is located under $USER_HOME/.m2. If you do not already have a settings.xml file you can get an empty one under your maven2 install in the directory $M2_HOME/conf. To define the value for ${logging.location} create a profile in your $USER_HOME/.m2/settings.xml file like the following:

Next you need to activate the profile by adding the following in your settings.xml:

Since the surefire plugin does not put log statements in the output file when using the redirectTestOutputToFile, viewing the log statements in the console can be a bit overwhelming. To make this easier consider using the test single goal: mvn -Dtest=ClassName test