A review of Packt Publishing's Spring Data

Packt Publishing's Spring Data is their latest offering in the now familiar cookbook format covering the Spring Data support for JPA and Redis. The Kindle version was well laid out, which can be difficult for technical texts.

The cookbook uses a simple domain model for contact data to demonstrate the creation of a CRUD database and then steps the reader through creating operations using Native SQL, Java Persistence Query Language (JPQL) and the Criteria API. What I found most useful was being able to compare and contrast the pros and cons of each approach.

This section may be less suited to the novice it assumes a working knowledge of JPA. The cookbook could not be treated as a JPA tutorial or reference as other texts have greater coverage using more complex data models.

The chapters on Redis start with step-by-step instructions on configuring the connection to a Redis service using the Jedis, JRedis, RJC and SRP connectors. It then proceeds through to the implementing a CRUD application for the contact data and adding publish/subscribe notifications for updates.

By far the most beneficial thing I found in these chapters was how to use Spring Data Redis to add transparent caching support to a JPA repository.

Spring Data can be bought from Packt Publishing and Amazon.com.

posted by James Gemmell on Sat, 19 Jan 2013 at 13:46 | permalink | tags: , , ,

A review of the Spring Web Services 2 Cookbook

The Cookbook fills a long-standing vacancy on the Spring bookshelf and plays a useful complementary role to the online Spring Web Services reference documentation. Considering the volume of publications, Spring WS is by far the poorer cousin of the Spring core, persistence, MVC, batch and integration lineup.

Over the last two years I've used Spring Web Services extensively in the implementation of a multi-operation web service facade to a foreign exchange dealing system in a large Australian bank.

I wish I'd had this book when I started the project. The WS examples from SpringSource are great, but they don't come close to demonstrating the richness of the platform's capabilities. The Cookbook's recipes and the accompanying sample projects cover just about every combination of transport and object-XML mapping that you're likely to use (SOAP over HTTP and JMS with JAXB2 and XMLBeans) and some of the more esoteric (SOAP over e-mail and XMPP with JiBX and MooseXML.)

Both XWSS and WSS4J for security are dealt with comprehensively. I was pleasantly surprised to find a chapter dealing with JAX-WS and Apache CXF as well as creating RESTful services, using Spring MVC. Testing using Spring's MockWebService as well as TCPMon and soapUI also get their own much needed chapter.

As you would expect of any cookbook, this one doesn't read easily cover to cover, and the recipes can appear repetitive at times. In-depth coverage has been sacrificed in favour of breadth. However, in my opinion, this is the Cookbook's strongest selling point. The wide range of subject matter allows the reader to easily explore the featured technologies and make educated evaluations and comparisons.

I find the Spring Web Services 2 Cookbook a worthwhile addition to my bookshelf. The book can bought from Packt Publishing and Amazon.com.

posted by James Gemmell on Tue, 15 May 2012 at 21:00 | permalink | tags: , ,

Using What instead of Why to report errors

During peer code reviews I have sometimes observed that there is a preference for programmers to interpret errors or exceptions as part of the error handling process. Instead of reporting what caused the error, an interpretation is applied and why the error occurred is reported instead.

As an example, an exception such as "connection failed" is reported as "the server is down". This is, quite clearly, a naive interpretation. There may be many other reasons as to why the "connection failed"; the connection credentials may be incorrect, there may be a network fault, the service application may not be running or a solar flare may be affecting your Wifi. Under these circumstances, all you can safely assume about the situation is that, well, the "connection failed".

The example above seem obvious but it becomes even easier to make the mistake when reporting business exceptions from a web service. When required to handle a particular error, the programmer often has to rummage through a toolbox of available business exception codes and apply the one that fits best. More often than not it doesn't.

The importance of getting this right may only become apparent after that prolonged phone call with the irate user who insists that your "server is down" when you know perfectly well that it isn't.

posted by James Gemmell on Wed, 01 Jun 2011 at 21:14 | permalink | tags: , ,

Moving a MythTV Master backend

This proved to be a whole lot easier than I thought. It required backing up the mythconverg MySQL database on the old system and restoring it on the new one.

   ~ /usr/share/mythtv/mythconverg_backup.pl
   ~ /usr/share/mythtv/mythconverg_restore.pl --filename mythconverg-VERSION-TIMESTAMP.sql.gz

A further step was needed to update the hostname of existing recordings to the new host.

   mysql> update 'recorded' set hostname='peeves' where hostname<>'peeves'

This machine became the frontend at the same time. The i3 GPU support was included in the xf86-video-intel driver from version 2.10. I ended up using 2.11 which had just become available and added the following entry to /etc/portage/package.keywords.

   =x11-drivers/xf86-video-intel-2.11.0 ~x86

posted by James Gemmell on Sun, 29 Aug 2010 at 12:13 | permalink | tags: , ,

Faulty SOAPFaults and Java5

There may not be many good reasons for wanting to perform XML schema validation on a SOAP Fault. I had cause to as part of a unit test for a piece of fault generation code. I used SAAJ to create the fault and Spring's XMLValidator to validate.

The unit test passed on JDK 1.6 but failed with the exceptions below when run under JDK 1.5.

   org.xml.sax.SAXParseException: UndeclaredPrefix: Cannot resolve 'SOAP-ENV:Server' as a QName: the prefix 'SOAP-ENV' is not declared.
   org.xml.sax.SAXParseException: cvc-type.3.1.3: The value 'SOAP-ENV:Server' of element 'faultcode' is not valid.

The XML in question was the qualified name in the faultcode that had been created by default.

   <faultcode>SOAP-ENV:Server</faultcode>

The fix was to remove the SOAP-ENV namespace prefix by calling setFaultCode("Server") on the SOAPFault. The test then passed on both JDKs.

Here's the reason. Under the hood, XMLValidator uses the Xerces JAXP validator bundled in the JRE's rt.jar. From 1.5 to 1.6 the validator implementation was changed from using a SAX parser to DOM. It appears that the former is unable to resolve the prefix correctly when it features in the text content.

posted by James Gemmell on Mon, 17 May 2010 at 15:33 | permalink | tags: , ,