The TR069 schemas which can be found at http://www.broadband-forum.org/cwmp.php define the communication. Unfortunately the CWMProtocol uses ancient technology – namely XML-RPC. One can find old libraries for XML-RPC on the web, but they look old and crusty. We decided to go with JAXB ( https://jaxb.dev.java.net ) to get Java classes from the schemas. However, JAXB doesn’t seem to handle the old XML-RPC ideas perfectly, so we have to apply some band-aid (more on the server side than on the client side, though). I’ll blog about this separately.

To get the JAXB processing to work at all I have deleted fixed="1" from the soapenv:mustUnderstand attributes.

The HTTP communication of GroovyCPE is done with the help of the Apache HttpComponents v3 which is a pretty OK library for HTTP communication.

The initial configuration content in testfiles/parameters_tg784/get*.txt is from a Thomson TG784 box.

GroovyCPE is built around a central store of the parameters it reads in. And as much as possible it uses the configuration parameters it self – eg. for the ManagementServer URL and the PeriodicInformInterval.

What it can do:

• Immediately send Inform messages with all event types
• Run a thread that sends scheduled Inform messages according to the PeriodicInformInterval
• Listen for connection requests on the ConnectionRequestURL (and send an Inform if requested
• Accept a DownloadRequest and initiate an HTTP download session according to the contents
• Respond to GetParameter{Names,Values,Attributes} requests.
• Accept SetParameter{Values,Attributes} and set the values
• Accept AddObject requests and add objects (but only if the object layout is known from the configuration parameters)

I don’t have any immediate plans for improvements to GroovyCPE. At some point I will probably look at fixing the JAXB classes at generation time with a JAXB plugin.

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.