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
   

@XmlAccessorType(XmlAccessType.FIELD)

to your class will resolve the issue. Has anyone else done this? How did you resolve the issue?

Error in mule-cxf.xsd?

I'm reposting this, as I've reached new conclusions. Originally, I was convinced that there was an error in the xsd for the cxf transport in mule. A collegue of mine posted a question on this to mulesource, but we haven't gotten a response back yet (except from me). Examples on their wiki feature using the inbound-endpoint in the cxf namespace with the address attribute, such as:
<cxf:inbound-endpoint address="http://localhost:63081/hello" wsdlLocation="foo/bar/hello.wsdl" />
And this style is correctly interpreted by Mule and runs fine. However, the address attribute shows up in red in IntelliJ IDEA as an invalid attribute on the cxf namespace. Anyone else ran into this? I originally attributed this to its not being present in the inbound-endpoint element in the cxf namespace, but being present in core. But the cxf inbound-endpoint is actually an extension of the one in core, this is visible in XmlSpy and it validates fine in Eclipse. I now believe this is some kind of problem with either the xml editor and/or error highlighting components of IntelliJ. I can't find any Jira cases about this or any reference to it in the forums, so I opened a Jira case here. Maybe we should all just use Eclipse?

During this research, I did come across another problem (which I originally thought was the cause of our issue). Some IntelliJ fans ran into it a while ago. There already is a Jira case with Mulesource for this here. The cxf shema wouldn't validate because there was a bad address for an imported schema for Spring. It's a one line fix. Instead of

<xsd:import namespace="http://www.springframework.org/schema/beans" schemaLocation="http://www.springframework.org/schema/beans"/>

It should have read

<xsd:import namespace="http://www.springframework.org/schema/beans" schemaLocation="http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"/>

The fix was merged into the 2.2.2 branch last week (and into 2.1.4 as well I believe). I don't know when they're deploying these fixes though, in the mean time you can download the files here (for 2.1.x) or here (for 2.2.x). I've tried to validate with these new files and validation still fails, though its due to the spring-context.xsd not Mule. Why can't people get xsds right? It would seem kind of important, as it's what everyone will be building their xmls off of.

Coincidentally, I've learned in writing this post how to paste xml/html code in blogger (found it here). Less than signs (<) must be written in their html equivalent, which is &lt;. There's also a cool script to translate it for you here. And to quote html special characters like I did above, use

&

instead of &. Also, Notepad++ has a built-in TextFX that can escape to HTML.

-- UPDATE 2009-11-17 --
JetBrains has released an update to IDEA 8, which includes the fix to the bug I submitted. The update notes can be found here
It is available as a free upgrade for those already with IDEA 8, get yours.
I believe this fix is also in the upcoming IDEA 9, so it should be in the Community Edition, for those who don't want to shell out for full-featured IDE.