JEE Project Setup with Gradle, Spring and JAX-WS integration
What I’m going to cover in this sample implementation:
- JAX-WS 2.2 Standard conform implementation
- Spring 3.0.5 Integration due SpringBeanAutowiringSupport
- Generic JPA 2.0 DAO with Hibernate as persistence provider
- Gradle 1.x as Build tool
- MTOM Transport for medium-size attachments
- Generic SLF4J logging with jcl and jul to log4j
- JUnit Testing with Spring Integration
- Generic Class for Services due DRY principles
Download the example here.
Run the example using: gradle jettyRun on the console. You should see something like:
INFO - <In-Memory Content Repository started...>
INFO - <Product Service started...>
INFO - <Product Service WS-* Endpoint started...>
The sample contains a simple domain with a few objects (Category, Product and Item) where Item is an generic byte[] abstraction item to store contents in a JCR compliant repository like Apache Jackrabbit. In the example it’s just in a Memory table to store Binary attachments. The Repository can be changed by implementing Repository<byte[]> with custom functionality.
Test the sample using SoapUI:
Ensure that Enable MTOM and Force MTOM are enabled. If other transports are available, SoapUI only uses MTOM if the attachment exceeds a specified size. Enforce this transport model to test the webservice.
The services are deployed at the following URL: “http://localhost:8080/shoppingEngine/services/product” . Append “?wsdl” to read the WSDL (during “add project” in SoapUI).
Gradle vs Maven vs Ant
Since I’ve done a lot of stuff with Ant and worked in many projects where maven was the weapon of choice, project sizes have differed massively. As a result I’ve seen a lot of different configurations, varying from simple standalone applications to complex multi-module projects. Maven looks really suitable for simple projects, or projects where everything should fit into one jar/war file. The problems begin with multi-module Management. Cross-References are not resolved the right way, the build is slow during cyclic references and cache and index reloading causes trouble. If you are using your own repository manager (Nexus, for example), the index and caching problems become much more significant. There are also a few issues with a central settings.xml where version numbers can be stored. Values are not resolved and the behaviour is not reproducible. Scary! The poorly managed primary / third-party repositories are also problematic. They force you to use excludes and old library versions if you don’t use a repository manager. The biggest problem with maven, however, is that it forces you to deal with the given project structure and the build life-cycle. There are a lot workarounds you can use (like running ant tasks in maven), but none of them feel right. Features like build automation and automatic deployment are supported but due the complexity of enterprise systems, you’ll end up with a bundle of ant tasks in the XML structure of the pom.xml. A few people also complain about XML as being the wrong language to write the build file in, but since I’ve written a lot of spring-wiring bean files, xml feels wordy, but it’s not a problem for me. So I tried to migrate the pom.xml of some of my projects to gradle. It worked fine, aside from the bad IDE support from Eclipse/STS. The resulting build file is about fifteen times smaller and looks pretty readable. WAR bundling and the Jetty task to run the application worked fine. The only problem I discovered: The dependency ‘com.sun.xml.ws:jaxws-rt:jar:2.1.4′ does not resolve its necessary dependencies. I fixed this issue by downloading the distribution and put them into my “lib” folder. Maybe I’ll try to fix it and show my experiments.