Couple of things about CXF

Here's a couple of things you need to think about when you're using CXF. I have my services working pretty good now. I prefer to work 'code-first' so I wanted to have my wsdl file generated (using java annotations) which in the end was really not a lot of work. Just to get the wsdl exactly right can be a bit tricky.
Anyway it works now and Axis1 and Axis2 client code can handle my services perfectly.

Just a couple of things I ran into...

- In CXF 2.0.2 there is a bug that duplicates the exception declarations in your wsdl file when specifying a target namespace in your exception class like so:

@WebFault(name="WhateverException", targetNamespace="http://exceptions.api.tripolis.com/")

A workaround is to omit the targetNamespace property. It's fixed in 2.0.3 thanx to Daniel Kulp (https://issues.apache.org/jira/browse/CXF-1127)

- I also noticed that Flex apps can't handle an array of items in the response object of a call when they're directly defined inside the object inside the response. For instance I return an array of picklistitems inside the object I return like so:

<xs:element name="keyValuePairs" maxOccurs="unbounded" minOccurs="0" type="tns:KeyValuePair" nillable="true"/>

Apparently the first elemnt in this array is not accessable when trying to iterate over the array. I don't know why but there is a fix for this.
You can wrap the array in a container object like so:

<xs:xs:element name="keyValuePairs" minOccurs="0" type="tns:KeyValuePairContainer"/>

This container just contains the array of KeyValuePair objects. When the client code is generated the container becomes transparent so the client will not see the container and will directly get the array of objects; now it works fine. Other clients (e.g. Axis1 and Axis2) won't notice the change and just keep on working.

Correcting error in previous post

Ok, I noticed that I posted some information in the Grails to the test... post that was not correct.
I said that, in my Grails project I had to use the applicationContext.xml instead of the resources.xml to get my existing spring beans working. This is not correct. It worked like that back then but apparently this is not how it should be.
From what I understand you really shouldn't use the applicationContext.xml file for your own custom stuff. This is used by Grails to set up some default stuff.
I just upgraded to the latest Grails version which is 1.0-RC1 (I'm using Groovy version 1.1-RC1 btw) and noticed that it works fine in resources.xml indeed.
I'll do an update on my findings during the project real soon.

What I also noticed in the new version and that was especially nice, is that the PropertyPlaceholderConfigurer bug is solved too. Before the properties in spring files were not replaced when a war'red application was run inside an appserver.
I believe that the problem had to do with the PropertyPlaceholderConfigurer kicking in too late - after bean initialization.
Anyway I can build a great working war file now - great stuff, you Grails guys!

Grails Exchange was pretty eerrrm... Groovy!

I attended the Grails Exchange from 16 - 19 october 2007 and that was absolutely great. Great talks by great speakers, many leading different open source projects incl of course the 2 men it was all about these days: Guillaume Laforge (Groovy project lead) and Graeme Rocher (Grails project lead). Couple of nice down to earth kinda guys (I've got their autographs as well as Dirck Koenig's in my new 'Groovy in Action' book :-) Thanx guys.

Subjects handled included Grails, Groovy but there was also a lot on testing of code e.g. with GroovyTestCase (Jeff Brown had some good stuff on that) and I was very impressed by Alex Popescu's talk about TestNG. This lifts the whole concept of testing to a higher level.
Instead of having multiple mechanisms and/or frameworks doing the testing (JUnit, Canoo WebTest, JMeter etc) you can now perform almost any kind of test with TestNG.
You can read the whole story about it at http://testng.org/doc/index.html
It's using JDK5 annotations and one of the great features is the is uses DataProviders so you will not actually have to rely on anything outside of the test environment like e.g. a database.

I spoke to almost all the attendees; each and everyone of them having a great story to tell about their reason of being there.

Finally I want to give my compliments to skills Matter for setting the whole thing up - it was perfect.
All in all I can honestly say this was the best conference I've been to in my programming career. Conclusion: I'll be there next year!