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!

Grails to the test...

I've started working on this new project, a systemweb that enables me to monitor some of the things going on in our big super webapp.
The project is for admins only so for a change the focus will be on functional features instead of graphical features. Good start so far.

I very much like the idea of 'convention over configuration' (anyone would after working 1,5 years with Spring. Nothing bad about Spring but configuration wise it has become somewhat of a monster) so I turned to the new kids on the block: (J)Ruby on Rails and Grails.
I've seen both Graeme Rocher (Grails man) and Charles Nutter (JRuby man) talking about their own framework and must say that it did not make the choice easier. Both frameworks offer a great deal of features so in the end it would come to my personal preference to tilt the scales.

Since I'm a Java developer and I'm still a bit time-bound, which didn't give me much time to learn a complete new language I chose Grails. This way I could still do Java, which I love and do Groovy scripting too.
Actually as Graeme Rocher pointed out: Groovy IS Java so that makes things a whole lot easier.

Eager as I am to get started I created my grails project and my first controller, the ClientDomainController. It will manage my... client domains.
Then it got interesting. Instead of using the grails domain class structure I wanted to use our existing libraries. All the stuff I needed was already there.
In the manuals I could only find stuff about using the Grails domain classes so I started thinking: The only thing I would do in Spring to use a library would be importing it in my Spring file...

The import looks like this:

<import resource="classpath*:spring-common.xml" />
<import resource="classpath*:spring-business.xml" />

First I tried the spring.resources.xml file but that didn't work so I tried the applicationContext.xml file and...

Vòila! Now I have access to all my existing managers, domain classes, etc...
Great thing is that now I don't have to worry about my database stuff either. So for all this I only added 2 lines of xml to a file... sounds good to me.

Spring 2 seminar by Rod Johnson, London

On march 2nd 2006 I was in London to hear Rod Johnson speak about new features in Spring 2. Rod explained that the focus for Spring 2 was 'make complex things simple and simple things even simpler'. From what we heard I think they succeeded pretty good.
I was especially impressed by the integration of AspectJ and the declarative way that you now can use to define aspects. It is now possible to use a simple POJO as an aspect. No more implementing or extending advisors. They defined a couple of new namespaces in the xml schema, like the aop namespace.
You can do something like

< aop:aspect >
... use valid AspectJ expression to define pointcuts and joinpoints ...
... use an ordinary class as an aspect
< /aop:aspect >

and there is your aspect.
Also nice is the struts like tag support they now have build in. Binding of forms to commands is probably a lot easier and more intuitive than before.
Of course he could only tell us a little bit in 2,5 hours, but the things that he told made me sure that a migration from Spring 1.2.6 to Spring 2 is a good decision.
You can find Spring 2 at http://www.springframework.org/download

First posting

Hey all!

This blog will function as a reference for all the stuff that is worth saving for some reason.
It will probably mostly be stuff to do with Spring, Java, and everything else to do with the projects I work on.