Loggers are not constants

Loggers are not constants, they are mutable objects.

I am currently working on a legacy Java/Spring codebase littered with calls to LOG and LOGGER, proudly declared as static final. There appear to be sound justifications for adopting this convention (besides avoiding Checkstyle complaints) but sometimes it is useful to reflect on how we ended up here.

Loggers have traditionally been declared static as their construction was considered expensive and therefore justified a singleton status. Times have changed along with coding conventions.

Most of the applications in this particular codebase are of the vanilla Spring application variety, namely singleton services processing value objects on multiple threads.

Loggers used by service singletons are obviously singletons themselves and clearly don't warrant this premature optimization. Loggers in value objects shouldn't be there.

A slightly grey area exists for short lived domain objects, say some business logic encapsulated in a function that would log input arguments and the result. The solution is to have the object factory inject the logger at object construction time. Dependency injection ensures that logging is just another service, singleton or not.

A further argument against using static final loggers is the increased use of semantic logging. The implications are that if, in order to unit test the logging feature, the object under test requires the static mocking capabilities of PowerMock then you're doing dependency injection incorrectly or not at all.

In another example, this practice was followed to the absurd extreme with SimpleDateFormat. Not only is this not a constant but the methods are not thread-safe. Declaring it as such merely increases the likelihood of multiple threads executing the unsafe methods concurrently, even more so when running in a multi-application container.

The Google Java Style guide suggests some reasonable conventions for constant names.

Forgetting why we started doing it in the first place and blindly following the static final Logger convention is, at best, premature optimization and, at worst, a shining example of donning the coconut headphones.

posted by James Gemmell on Tue, 24 Nov 2015 at 07:01 | permalink | tags: ,

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: , ,

Pretty printing with Emacs

I recently completed a proof of technology using Spring Web Services to host a SOAP over JMS service. While writing it up for distribution on a so-called Sharepoint "wiki" I needed to include the applicationContext.xml. Pretty printing the XML with syntax highlighting seemed like a good idea.

GNU's xmllint --format --htmlout was my first attempt but this does a pretty poor job in that all it does is wrap the formatted output in an HTML header and footer. I found nothing for Eclipse other than the Java2Html plugin.

A somewhat foggy recollection of doing a similar thing in the past led me to reacquaint myself with Emacs Htmlize which I hadn't updated since 1999. Needless to say quite a few new features have been added in the interim and using an htmlize-output-type of "inline-css" generated exactly what was needed to paste into the "wiki".

posted by James Gemmell on Wed, 31 Mar 2010 at 09:26 | permalink | tags: , , , ,