Earl Douglas

When writing Spring-enabled JUnit tests, I often make use of the @Autowired annotation to inject my test with various beans from my test context. After much tinkering around with various test configurations, I noticed that the placement of the @Autowired annotation affects the behavior of the injection, which piqued my curiosity.

With a private field and its corresponding setter method annotated with @Autowired, I observed the expected behavior: the setter is called during initialization of the Spring context, and the dependency injected as usual.

In my earlier discussion of self-validating domain objects, I left open the issue of distinguishing between an initialized and an uninitialized instance of a domain object, and some of the problems created by this difference. I have given it some further thought, and it occurred to me that I was making a common fundamental error in my judgement: I was applying a design pattern for the pattern's sake.

In my first attempt at SPR-3926, I ended up with a @Service annotation which was wholly separate from Spring's existing @Service annotation, and required either a confusing coexistence or an inappropriate integration of the two. It also required implementations of service interfaces to be annotated as Spring Remoting services, which is arguably less intuitive than annotating the service interfaces themselves as Spring Remoting services.

A common problem I encounter in enterprise systems is the messy business of validating domain objects. This all-too-common problem permeates every tier of operation, from low level persistence to high level UI, manifesting itself in multiple ways depending on operational circumstances. Operations which introduce instances of domain objects must take care to populate them appropriately before passing them on.

SPR-4545 suggests an extension of JdbcTestUtilsTests to add two simple JDBC-based queryRow() methods, which can be used to test other database functionality, such as Hibernate code.

SPR-3926 requests a @Service annotation for Spring Remoting configuration, and makes for an interesting foray into Spring's annotation support.

The goal I had in mind in my initial attempt at tackling this was to create an annotation which would allow specification of the common Spring Remoting configuration supporting the four remoting technologies:

• Spring's HTTP invoker (conventional Java serialization)
• Hessian (binary HTTP serialization)
• Burlap (XML HTTP serialization)
• RMI

Hibernate's ability to simplify database access with Spring at the helm removes an almost unbelievable burden from enterprise development. Gone are the days of tedious SQL maintenance and overly agile trial-and-error development of homegrown data access objects. Hibernate and Spring take care of all but top-level configuration and implementation of database access. It is this level that will be demystified here, as a universally portable and minimalistic approach to database access is built on the shoulders of these giants.

Remote access to the business logic of a J2EE web application is often a useful capability, though it can be time-consuming to implement. Spring Remoting takes nearly all of the confusion out of exposing services over the web for Spring clients to consume as easily as though they were locally instantiated. Commonly, Spring Remoting is used to expose a black-boxed implementation of a published interface over HTTP, with all communication between the client and server abstracted behind Spring libraries, and with data serialized between the client and server using simple Java serialization.