Getting up and running was certainly a breeze.


grails create-app ...
grails install-plugin cxf


Grails is a plugin-based framework. And the cxf plugin seems to be the best plugin for webservices right now. Exposing the services was then as simple as adding a

static expose=['cxf']

to the the grails service classes. We wante to allow our service interfaces to operate with complex objects. And to do that best we decided to use the DTO plugin and specify our interfaces in terms of DTOs mostly generated from our domain objects. This was only a semi-good idea, I think, as the conversion to/from complex domain objects was not great out of the box (more on that in another post).

To consume webservices, the most straighforward way is to simply dump the minimal jar of the GroovyWS module in the lib folder of the project. Since we already had all the dependencies included by the cxf plugin the minimal jar is all that is needed.

To test the services, most of our test were simply the usual integration tests of the service classes. But for functional tests we used the functional-tests plugin and the GroovyWS client we already had installed.

class MyServiceFunctionalTests extends functionaltestplugin.FunctionalTestCase {

	def myServicePort

	protected void setUp() {
		super.setUp();

		myServicePort = new WSClient("http://localhost:9091/myservice/services/my?wsdl", this.class.classLoader)
		myServicePort.initialize()
	}

	public void testAMethod(){
		final List resultVals = myServicePort.aMethod();

		assertEquals(4, resultVals.size());
	}
}

It feels a bit wrong to work with old and crufty technology like SOAP with shiny new technology like Groovy on Grails. But with that in mind it works surprisingly well. Points where I found the greatest room for improvement were.

• Grails has great support for Controllers as entrypoints, with interceptors for logging and authorization. For Services this seems harder if not impossible. I haven’t succeeded in using either groovys invokeMethod or the built-in spring support for aspect-oriented-programing.
• As mentioned above, the DTO plugin could use a more flexible mapping tool than the one it has.
• With code that has no immediate GUI feedback, testing is extremely important. But the Grails test run so slow that it is annoying.

Still, would I recommend Grails for a large SOAP project. Yes, I would.

This patch has now been applied to 1.2-SNAPSHOT.

http://jira.codehaus.org/browse/GRAILS-4540

The mockDomain method makes it possible to test code that uses GORMs dynamic methods, without having to use a real database.

IBM Developerworks has a great article on mock testing in Grails here.

Google told me that the problem probably was an empty Java file in my
project and to look in the
~/.grails/1.2-M4/projects/myproject/classes directory to
see which file kept changing timestamp.

However, no files did that. The solution was to modify
$GRAILS_HOME/scripts/_GrailsCompile.groovy and add
listFiles:true to the compile target:

ant.groovyc(destdir:classesDirPath,
classpathref:classpathId,
encoding:"UTF-8",
listFiles:true,
compilerPaths.curry(classpathId, false))

And it turned out Google was right, I had a Java file with only the
package specification in it.

		if(argsMap['no-reports']){
			println testRunner.out.toString()
			println testRunner.err.toString()
		}

should do the trick, if you add them to $GRAILS_HOME/script/_GrailsTest.groovy in the “runTests” closure, right after ” def result = testRunner.runTests(testSuite)”

With those lines in place you can run your test like


grails -Dserver.port=9090 test-app -integration -no-reports MyController


Specifying the name of the class to test is important since only the output from the last test class will be printed. So we might as well only run one.

The solution is not really more or less elegant than the one for Seam and Richfaces. I followed the guide on Grails.org but decided to make the solution a bit more general. So I pass the name of the select-element-to-update as a string to the update function. This way I can also put the function in a separate file for inclusion (updateselect.js).

function updateSelect(e, elemId) {
// The response comes back as a bunch-o-JSON
var values = eval("(" + e.responseText + ")") // evaluate JSON

if (values) {
updateSelectFromJSON(values, elemId);
}
}

function updateSelectFromJSON(values, elemId) {
var rselect = document.getElementById(elemId)
// 	Clear all previous options
rselect.options.length = 0

// Rebuild the select
for (var i=0; i < values.length; i++) {
var opt = document.createElement('option');
opt.text = values[i].name
opt.value = values[i].id
try {
rselect.add(opt, null) // standards compliant; doesn't work in IE
} catch(ex) {
rselect.add(opt) // IE only
}
}
}

Which is then called like this

...

<form>
optionKey="id" optionValue="name" name="country.name" id="country.name" from="${Country.list()}"
onchange="${remoteFunction(
controller:'country',
action:'ajaxGetCities',
params:''id=' + escape(this.value)',
onComplete:'''updateSelect(e, 'city')''')}"
>

</form>

One thing is missing from this solution, though. Unlike the solution on grails.org, the chained select is not updated based on the default value of the previous select. This can be fixed by inserting the following in the head element of the .gsp page.

function init() {
document.cityform['country.name'].onchange();
}
window.onload = init;

Grails is not packaged officially for Ubuntu yet. And the packages that can be downloaded from grails.org don’t have bash completion. This guy however packaged grails for Debian/Ubuntu, and it include a bash completion script. The package seems to work great, and for one of my machines where I already installed grails from the usual tar.gz download, I pulled out the bash completion from the deb-package. To make it work completely with the tar.gz dowload I just had to modify the location of the grails installation (to use $GRAILS_HOME). Ahhhh.

Somewhat less useful (but fun), I also added the Ubuntu “notify-send” notification feature described here. I feel all set for Grails development.

The tools used in Pauls piece don’t exactly fit my project however. I use Guice, and since that can be a bit confusing it would be nice to have some overview of how Guice binds the app together. With Guice 2.0 however there is a nice Guice plugin to generate diagrams. The only problem is that the Seam/Guice integration is not updated to Guice 2.0 yet. So I guess I’ll postpone this.

An important part of any application is the data model. So I would like to have entity diagrams generated. Since I use hibernate/JPA I thought that there would be an ant task to have entity diagram generated directly. However, lots of searching on google brought me nowhere. Linguine maps would have been a solution back in the days when one used “.hbm.xml” files to configure entity classes. But noone does that anymore. So I asked a question on Stackoverflow but that didn’t help. Finally I tried a workaround that involves starting a database deploying the entities and then letting SchemaSpy generate diagrams from the database. This could definitely be more elegant.

I usually don’t program with deep or advanced class hierachies so I don’t see the point in doing inheritance graphs. Others do, however, and the tool API viz does a nice and easy job of creating them, so I might as well include that. I could presumably also have used UMLJGraph or UMLGraph (like in the developerworks article).

The really fun part begins if I were to write a small ant task that could process an ODF document with ODFDOM and automatically insert the graphs in the right place. I attended the ODFDOM hands-on-lab at JavaOne, and while the api is a bit rough now, it should actually not be too much work I think (especially if I use Groovy). I guess the first version would just replace some placeholder string in the document with the appropriate diagram. This way it should not be too difficult to use with the different documentation template documents one encounters. Poor mans LaTeX, yay! I’ll blog it when I get it running.

+++++++++++++++++++++++++++++++++++++

The AntTask for ApiViz just requires the apiviz jar file which I put in a folder “buildlib”:

<target name="javadoc">
 <javadoc destdir="docs/api"
 author="true"
 version="true"
 use="true"
 windowtitle="TACS API"
 classpathref="class.build.path"
 doclet="org.jboss.apiviz.APIviz"
 docletpath="buildlib/apiviz-1.3.0.GA.jar"
 additionalparam="-author -version">
 <fileset dir="src"/>
 </javadoc>
 </target>

The not very elegant integration of SchemaSpy involves the buildtarget below which starts two tasks in parallel. The top one just executes a class that programatically start an HSQLDB and then loads a datasource which points to that database. This then causes Hibernate to create the tables specified by the entity classes. When the database is started and the datasource loaded it sleeps 20 secs to allow the schemaspy task to connect. The bottom parallel task then sleeps 10 secs (to allow the datasource to load) and then runs schemaspy.

<target name="db-diagram" depends="db-start">
<parallel>
 <daemons>
 <java dir="build/classes/test" classname="TestEntityManagerProvider" fork="true">
 <classpath>
<pathelement location="build/classes/test"/>
<path refid="class.test.path"/>
 </classpath>
 </java>
 </daemons>
 <sequential>
 <sleep seconds="10"/>
 <java jar="buildlib/schemaSpy_4.1.1.jar"
 output="docs/output.log"
 error="docs/error.log"
 fork="true">
 <arg line="-t hsqldb"/>
 <arg line="-host localhost"/>
 <arg line="-db tacs"/>
 <arg line="-u sa"/>
 <arg line="-s PUBLIC"/>
 <arg line="-cp buildlib/hsqldb.jar"/>
 <arg line="-o docs/api"/>
 </java>
 </sequential>
 </parallel>
 </target>

public class TestEntityManagerProvider {

 public static void main(String[] args) throws InterruptedException {
 System.out.println("Starting hsqldb");

 new Thread(new Runnable(){
 public void run() {
 Server s = new Server();
 s.setDatabaseName(0, "tacs");
 s.setDatabasePath(0, "mem:test;sql.enforce_strict_size=true");
 s.start();
 }
 }).start();

 Thread.sleep(2000);

 final Map props = new HashMap();
 props.put("javax.persistence.jtaDataSource", "");
 final EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("tacs-diagram", props);

 final EntityManager entityManager = entityManagerFactory.createEntityManager();

 entityManager.getTransaction().begin();
 entityManager.persist(new Cpe());
 Query q = entityManager.createQuery("from Cpe");
 System.out.println("Results from cpe" + q.getResultList());

 System.out.println("Sleeping 20 sec");
 Thread.sleep(200000    );
 System.out.println("Done sleeping");
 }
}

My favorite presentation was “The feel of Scala” by Bill Venners (I ran out and bought his Scala book after the presentation). This presentation is not online (yet?) but I have found a video of the talk from another conference

Enjoy!

Unix users (who use shell scripts) know that a small amount of programming is effective at solving these problems. So for my web-app I was contemplating how to get something “shell-like” into the project. There are several projects that present a nice AJAX based web interface to the system shell on unix machines. Eg. shellinabox and ajaxterm. And there are several programming languages that seem suited for interacting with a Java app. Eg. Groovy, Jython, or Beanshell.

So I decided to try to combine the interactive groovy shell with an ajax frontend. After looking around quite a lot I found shellinabox which has a nice GPL’ed javascript vt100 front end (I found another here which is LGPL’ed).

After a some weekend studies of shellinabox I could make a prototype with the vt100.js of shellabox and the nice little python webserver of ajaxterm. With a little more hacking I was able to hook up the groovyshell as a web-app through a java servlet. The interactive performance sucked, because of some weirdness in standard java.io.PipedInput/OutputStream classes, but fortunately I was not the first with that problem so with some small hacks to the replacement classes from LiveGraph the interactivity became tolerable.

From this working state there is actually still quite a bit of work to have something that I can deploy on a customer production server. But when Guillaume Laforge announced his cool little app “GroovyWebConsole” to run a groovyshell on the Google AppEngine I figured that I might as well upload what I had and announce it as well. Here is the announcement I sent to groovy-users

I have made a similar app to administer a JEE app I’m doing. It is
similar but is stateful and uses a vt100 interpreter in javascript (from
shellinabox).

You can find it here

http://code.google.com/p/ajaxgroovyshell

It is mostly a prototype – to be really useful for me I need to add

1) Access control
2) A way to paste text from the system (a pop-up textarea?)
3) Proper sessions
4) A robust way to handle threads
5) Syntax highlighting?
6) Better tab completion in GroovyShell (more like ipython)
Unfortunately it won’t run on the Google AppServer since I need a thread
for the GroovyShell.

Best
Anders

Since then I have noticed several java server projects that have some kind of console facility. But not as an ajax webpage (yet). I have suggested it a couple of places (like for Hudson, and for FRESH).

<ui:include src="vendormodelmenu.xhtml">
	<ui:param name="vendormodelheader" value="Appropriate header"/>
	<ui:param name="searcher" value="#{searcher_object_name}"/>
</ui:include>

Neat!