The [Grails cxf-client plugin][1] has been updated to version 1.2.9. When I first deployed the plugin I overlooked allowing checked exceptions and soap faults to bubble out of the client proxy appropriately. I modified the plugin to allow this now. In addition I added a configuration parameter for proxyFactoryBindingId to allow soap 1.2 (set to “http://schemas.xmlsoap.org/wsdl/soap12/”). #### Updated Parameter Documentation #### The following partial documentation is available in full at [https://github.com/Grails-Plugin-Consortium/cxf-client][2] Property|Description|Required :———–|:————|:———— proxyFactoryBindingId|The URI, or ID, of the message binding for the endpoint to use. For SOAP the binding URI(ID) is specified by the JAX-WS specification. For other message bindings the URI is the namespace of the WSDL extensions used to specify the binding. If you would like to change the binding (to use soap12 for example) set this value to “http://schemas.xmlsoap.org/wsdl/soap12/”. (default: “”)|No [1]: http://www.grails.org/plugin/cxf-client (Grails Cxf Client Plugin) [2]: https://github.com/Grails-Plugin-Consortium/cxf-client

The Grails cxf-client plugin has been updated to version 1.2.9. When I first deployed the plugin I overlooked allowing checked exceptions and soap faults to bubble out of the client proxy appropriately. I modified the plugin to allow this now. In addition I added a configuration parameter for proxyFactoryBindingId to allow soap 1.2 (set to “http://schemas.xmlsoap.org/wsdl/soap12/”).

Updated Parameter Documentation

The following partial documentation is available in full at https://github.com/Grails-Plugin-Consortium/grails-cxf-client

Property	Description	Required
proxyFactoryBindingId	The URI, or ID, of the message binding for the endpoint to use. For SOAP the binding URI(ID) is specified by the JAX-WS specification. For other message bindings the URI is the namespace of the WSDL extensions used to specify the binding. If you would like to change the binding (to use soap12 for example) set this value to “http://schemas.xmlsoap.org/wsdl/soap12/”. (default: “”)	No

I am creating a hello world grails project for internal use here at our company. The project encapsulates both the source code and the documentation in gdoc format. When a new user comes onboard, they get the project from the source repository and then run the grails doc target to generate the guide locally with a tutorial on building a simple application. In the project I have already included a full test suite that should pass when the tutorial is completed.

I needed a way to have my version control ignored domain, service, and controllers that I was using be added in a way that kept them out of the base grails-app directory so the user could generate them. At the same time I really wanted to put a link to what the finished classes would look like in the docs somewhere to help users along during the process if needed. During this process I only wanted to have one master file and not have to maintain the code blocks in the gdoc files separately from actual code.

The [Grails cxf-client plugin][1] has been updated to version 1.2.7. I have added the ability to specify timeouts (connection and receive) and allow chunking separately through params and also provided another parameter to pass the client name of an HTTPClientPolicy bean to use instead of setting the params seperately.

The Grails cxf-client plugin has been updated to version 1.2.7. I have added the ability to specify timeouts (connection and receive) and allow chunking separately through params and also provided another parameter to pass the client name of an HTTPClientPolicy bean to use instead of setting the params seperately.

Recently while developing a prototype application for performance testing using redis and jesque (see post) I got to thinking “why doesn’t the grails redis plugin currently have support for annotation based memoization like spring cache?” I figured I would set out to add that support and learn to write Groovy AST Transformations at the same time. The process was long and arduous and I learned a lot during my several weeks of coding.

I built a relatively simple framework to do performance testing of code using redis, jesque and executor. It uses some jQuery and ajax on the front end and provides a relatively simple administrative UI. The code is currently availabe on github. The overhead of the perf runner is relatively light and extremely fast as it is using redis as its storage mechanism for queues, jobs, statistics, and status. If you would like to change where or how the results are saved you could certainly hack the code in the ResultsService.

Based on a user request, I have added the ability to pass the wsdl2java script a wsdlArgs param in which you can use to pass custom args into the client creation process. I have also modified the name of the bindingFile parameter as the name binding was in conflict with groovy reserved keywords.

I am currently in the process of porting all the blog posts to Octopress. This is a WIP and I will try and get all the content updated ASAP.

Thanks!

Based on a request from a user to add user defined logging and fault interceptors, I have enhanced the [Grails cxf-client plugin][1]. I have included these features in the new release version 1.2.3. In the previous version (1.2.2) of the plugin I added the ability to override the security interceptor. This was done to allow users to diverge from using the standard WSS4J interceptor that I bundled with the plugin. I accomplished this by adding an single out interceptor to the cxf client proxy. In the latest version I have taken the interceptor injection one step further and allowed users to configure any number of in, out or fault out interceptors they want to add to the interceptor chain.  In addition I have provided a flag to turn on or off the default logging in and out interceptors that I am auto injecting for the users.