Friday, August 7, 2009

Groovy & CXF JAXB

I was working on making an existing application a mule service, when I ran into the snag that Groovy classes, when exposed as an parameter to the service method, which throws an error when JAXB attempts to deserialize the object to xml (for creating the wsdl). Every Groovy object possesses a property called metaclass that cannot be serialized because it is an interface. At the time, I solved this problem by wrapping the Groovy stuff with Java, to expose only what I wanted. Another way I could have done it would have been to have the Groovy class implement a Java class.

I later found out a third method, when I attended a brown bag session where a colleague gave a talk about using JAXB. Today, I found this link, which describes exactly that. Annotations can be used to override the default JAXB behavior to exclude that messy Groovy stuff. I haven't experimented with this yet (since I've already got my service working and there was no compelling reason to do it in Groovy instead of Java), but I wonder which of these three solutions would be the cleaner solution. I don't have a really strong opinion on this, but its probably preferable to have extra annotations than to have extra classes. Extra wrapping classes just result in more boilerplate code for the next guy down the road to wade through, at least annotations would only add a few lines (one line I believe in the case of CXF). Allegedly, just adding the annotation
to your class will resolve the issue. Has anyone else done this? How did you resolve the issue?