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.
posted by James Gemmell on Tue, 15 May 2012 at 21:00
| permalink
| tags: java, soap, spring
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: java, soap, spring
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: linux, gentoo, mythtv
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: java, saaj, soap
After a few of years of fairly intensive use I am migrating a MythTV
backend from a rather creaky and increasingly unstable Pentium 4 to a
shiny new Core i3 530 based box. I was quite impressed with
Phoronix's Linux benchmarks of the CPU. The performance of the integrated GPU
will help too since this box is destined to run an HD frontend at some
point.
It's been a while since I last set up a Gentoo box from scratch and
thought I'd give the Gentoo Quick Install a go rather than the
LiveCD. The i3's Hyper-Threading support meant that the boot was
graced with a 4 penguin salute and I was pleasantly surprised by the
performance.
When partitioning the 1TB drive I settled on the following layout,
setting aside /dev/sda5 as a future amd64 root partition.
/dev/sda1 /boot 256MB ext2
/dev/sda2 swap 2GB swap
/dev/sda3 / 100GB ext3
/dev/sda5 [amd64] 100GB ext3
/dev/sda6 /mnt/mythtv 729GB xfs
I diverged from the install guide in a few places. When the
gentoo-sources kernel download threatened to take more than a couple
of hours I performed the mirror-select step early and portage pulled
it from a local mirror. I prefer using genkernel and, setting
MAKEOPTS="-j5", this and the emerge world steps took next
to no time.
The backend is now up and recording and the next step is to
promote it to master backend status and get the frontend working.
posted by James Gemmell on Tue, 20 Apr 2010 at 09:17
| permalink
| tags: linux, gentoo, mythtv
RSS 2.0
