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).
Painful JPA 2.0 CriteriaQuery
JPA 2.0 offers a lot of nice features such as support for extended maps, collection mappings, automatic removal of related objects (orphan), configurable pessimistic locking and caching. But in my opinion, there are also downsides, such as the bloating CriteriaQuery which turns a simple JPQL query into a six line monster. The first time I had contact with JPA #2 was while reading IBM Developer networks “Dynamic, typesave queries in JPA 2.0″. Since there are already such great articles like “Don’t repeat the DAO” out there, I was a little confused about the focus of the article from IBM. Typesafety is great, if it’s applied in a generic way! The advantages and drawbacks of so much more code? Due raw type usage / type erasure no runtime checking for the type is possible. Secure / Deterministic refactoring may be to blame. Viewing type problems at runtime shouldn’t be an issue, since the application is being tested properly. Most IDEs offer features for String lookups during refactoring which can help with the refactoring issues. JPQL Queries tend to have a readable structure. The CriteriaQuery API looks like the opposite is the case if the query is a more complex one. In my opinion the price for such a “typesave” Query is too high; while the JPQL Query is based upon SQL and offers readability, the Criteria API looks verbose and bloated. I prefer to write good old JPQL Queries.