Web service clients – where Grails lost its mojo

I am working on a Grails 2.0.x application that needs to consume some web services. Simple enough, I have written many clients in the past, using Axis and Spring-WS in Java, and WCF in .Net. Almost everything I have done so far was easy with Grails and Groovy, so I set out to create a client in Grails.

First off, I found GroovyWS and discovered the ease in which one can create clients with this tool. All was well when running Grails locally, but when the application deployed to our dev integration server (Tomcat 6, Java 6), it was throwing some exceptions about not finding the JAXB types for the specified class name. Apparently, the JAXB implementation on the dev integration was creating classes of different names than the implementation running on my local machine, from the same WSDL. I started debugging but quickly found myself in dependency hell, so I stepped back and tried a different client.

I had used Spring-WS before on a Spring 2.5 Java project and knew how it worked, so I gave it a shot. Even with this implementation, I was getting errors and again finding myself in dependency hell. There was still one more client I had used in the past, so I thought I would give it a try. Running wsdl2java against Axis 1.4 resulted in a client where classes actually would not compile. I attribute this to the complexity of the service itself and Axis’ inability to correctly parse out the types correctly. In any case, no dice on Axis 1.4.

Then I remembered JAX-WS. It is the most up-to-date web service tool supported by Java. After some issues with wsimport failing to generate a client at all (the WSDL has not WS-I BP 1.1 compliant and was later fixed by the service developer), I was able to successfully generate the client. I integrated it with my code, fired up Grails, invoked the service and bam!:


runtime modeler error: SEI rsastationinventorymgmtcontract.StationInventoryMgmtPT has method __execute annotated as BARE but it has more than one parameter bound to body. This is invalid. Please annotate the method with annotation: @SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)

What?! So JAX-WS doesn’t know how to correctly generate a client from a WSDL? I was doubtful and wanted to prove it worked. I created a simple Java application containing the source files for the generated client and a single Java class to test the service. I fired up the 1.6 JVM and ran the class, and lo and behold, the client invoked the service successfully. Then I thought, ‘Oh no, more dependency issues?!’ Then I thought of something. What if I ‘forced’ the JAX-WS implementation used at runtime? Surely that would help, right? I added the following to the Grails BuildConfig.groovy:

grails.project.dependency.resolution = {
	...
	dependencies {
		...
		runtime('com.sun.xml.ws:jaxws-rt:2.1.4')
	}
}

I built the application and fired up Grails, and was able to invoke the service successfully.

All in all, I have been happy with my development experience in Grails, but dealing with web service clients left me wanting more from the framework in this area. Maybe it is just my unfamiliarity with the framework, but this solution was not obvious to me and left me scratching my head for a while.

About these ads
This entry was posted in Grails, Groovy, Java, Web Services and tagged , , , , , , , . Bookmark the permalink.

12 Responses to Web service clients – where Grails lost its mojo

  1. vasya10 says:

    Good finding. Yes, Grails webservices leaves a little bit more to be desired, compared to how well the other plugins work just out of the box. Especially when you get ‘this plugin may not be actively developed. please look at this site’. You go there, there is a similar one there too. Hopefully we dont have to look beyond this jax-ws solution.

    May be a similar dependency issue was the reason for jaxb failures in the dev integration?

    Well when everything fails, we still always have an option for a stork that delivers the raw xml.. hehe.

    • asoftwareguy says:

      Yeah, after doing some more research with Grails and JAX-WS, it looks like having the jaxws-rt jar file as a runtime dependency is required. I only find this in other user’s blogs; nowhere on either the Grails or JAX side of the house.

  2. GA. says:

    Cheesh–no wonder you’ve been logging hours between 9PM and 1AM! Thanks for toughing it out, Eric–

  3. Pingback: Extensions via metaclass in Grails « Vasya's Weblog

  4. Pingback: Questa settimana in Grails (2012-08) - luca-canducci.com - Il blog di Luca Canducci: notizie, tips e nuove tecnologie dal mondo dell’IT.

  5. Ingo says:

    Thank you for publishing this! I’m adding this comment with my error messages, so more people with the same problem will find your post.

    I got a runtime error of “undefined operation name …” in com.sun.xml.internal.ws.model.AbstractSEIModelImpl.freeze. Most interestingly, it worked for the integration tests, but not for dev and prod environments. Adding the runtime dependency to BuildConfig.groovy solved the problem.

  6. van Geir says:

    > dealing with web service clients left me wanting more from the framework in this area

    You think web service clients are hard. You should try generating javascript from Groovy and Grails. They simply can’t do it, though there’s plenty that can: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

    • Lyle says:

      Almost *all* of those languages are built from the ground up to compile to JavaScript, and the majority of that subset are CoffeeScript forks. Not really apples to apples.

      • Lyle says:

        Oops, I spoke too soon, didn’t see the whole document. I retract my statement.

  7. Pingback: Team Blog | Classloader problem with Java 7 and WebServices in Grails

  8. asoftwareguy says:

    Myself and one of my colleagues have started using groovy-wslite to generate markup for the web service calls as opposed to generating tons of binding classes that are ultimately marshalled/unmarshalled to/from XML. I have a post in the works about it.

  9. Knight says:

    I was also facing the error message of ERROR method __execute operation not found in the WSDL while I was using Groorvy on Grails to callout to a JAX-WS implementation and this post fixed the same.
    Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s