Recently in the Grails Filterpane Plugin I had to figure out a way to allow users to selectively override the bundled template files that were rendered in the filterpane taglib. I was able to achieve this through a bit of simple code that may be helpful to plugin authors in the future.
For quite a while I have been stuck using grails 2.2.0 on a Travis CI build server due to any later version not being added to the groovy ppa on ubuntu. This was done because of the move to the GVM tool. I was able to cobble together a travis script and GVM hack to get this working. This is great because now I can use Grails 2.2.1, 2.2.2, etc.
Recently I ran into an issue where using the builtin
HTTPBasicAuthorization provided by wslite did not meet the needs of using a simple plain text username and password in the soap header of a soap service request.
The Grails Cxf Plugin makes exposing classes (services and endpoints) as SOAP web services easy and painless. Since version 1.0.0, it has been rewritten and enhanced to support more features including the migration to grails 2.x.
The current cxf version is 2.6.2
Some new things as of version 1.x are as follows:
- The plugin will autowire configured classes in the grails-app\endpoints* AND the grails-app\services* directories
- Endpoint creation scripts create-endpoint and create-endpoint-simple will create cxf artefacts in grails-app\endpoints
- Service creation scripts create-cxf-service and create-cxf-service-simple will create cxf artefacts in grails-app\services
- The suggested pattern to isolate cxf endpoints is to have endpoints live in grails-app/endpoints directory (or you can use grails-app/services for overlapping and shared services)
- Built in support for simple Map response type handling via
@XmlJavaTypeAdapter(GrailsCxfMapAdapter.class)method annotation has been included to use or to kick start your own map adapter creation
- Many new examples to help with configuration can be found in the source via functional specs and test classes at https://github.com/Grails-Plugin-Consortium/grails-cxf
- Default plugin configuration is provided via
DefaultCxfConfig.groovy. Although usually not necessary, you can override in your project’s Config.groovy
- The default url for wsdl viewing remains
http://.../[app name if not root]/servicesas it was in previous versions. Multiple cxf servlet endpoints can be configured or the default changed via Config.goovy
- Wsdl First services are now available to use
- Plugin should be mostly backwards compatible and work in grails 1.3.x
You can get more details at https://github.com/Grails-Plugin-Consortium/grails-cxf
There is also a demo project if you do not want to run the cxf plugin code inline at https://github.com/Grails-Plugin-Consortium/grails-cxf-demo
We were migrating some existing Java code to Grails 2.0 and we were looking for a good solution to test domain constraints as we were migrating from an existing schema. We already use and love Spock for most of our testing needs. We came up with a relatively easy and reusable solution for testing constraints that I wanted to share. As we make improvements or changes I will update the post.
Update I have updated the project and samples to work with Grails 2.1.1 and Spock 0.7.
All files for this demonstration can be found at my grails-spock-constraints GitHub repository.
I have struggled a lot with getting our corporate-standard WebSphere container to play nicely with Grails in the past and when we moved to Grails 2.1.1 and WebSphere 7.0 it was no different.
In my grails cxf-client-demo project I needed a way to test if the simple username token authentication wss4j interceptors were working. I looked around the web for help on how to inject an inbound security interceptor into the grails cxf plugin. I found some example on how to do this with cxf 2.3.x versions, but when I was recently helping update the grails cxf plugin to use cxf 2.5.2, I found out they changed the way that username token was done.