Active-Active Configuration

I received a comment on one of my previous posts asking how to run a test class using SpringJUnit4ClassRunner from normal application code (i.e. within a main method). I'll admit, I didn't know how to do this, but my interest was piqued.

In my current project, I have classes which are modeled like the following. At some point, a method like getReturnTypeForGetId() is called on classes A and B . Calling the method with A returns Integer as expected, but B returns Serializable . What am I missing here? Am I getting bitten by some heinous erasure thing, or am I just missing out on some sort of generic context-clobbering? EDIT: Adding an over-ridden getId() method to B fixes the problem, but I would still like to understand what I am running into. I've also asked this question on stackoverflow. import java.io.Serializable ; public class WeirdTester { static interface Identifiable & lt ; T extends Serializable > { T getId (); void setId ( final T id ); } static abstract class BaseEntity & lt ; T extends Serializable > implements Identifiable & lt ; T > { private T id ; public T getId () { return id ; } ...

The org.springframework.test.context.junit4.SpringJUnit4ClassRunner class is another implementation of the JUnit TestRunner class which is used to enable various features of Spring for every run of the test class and every test within it. To use the features provided by the SpringJUnit4ClassRunner class, you need to mark the class using the RunWith annotation using SpringJUnit4ClassRunner as its parameter. In addition to the custom test runner, you will want to mark the class with the ContextConfiguration annotation. The ContextConfiguration annotation is used to mark classes which will automatically read a Spring configuration file and use it to create an ApplicationContext . By default, this file located at <package path>/<test class name>-context.xml . Use the locations argument to over-ride. The ApplicationContext used by the Spring-integrated test will only be loaded once for the whole test class. This behavior can be over-ridden by annotating a test metho...

Groovy , the apparent golden child of Java, is a mostly dynamic-typed JVM language which seeks to add functionality to the core Java language such that writing and testing code is much easier and requires less boiler-plate code. Some of the features provided by Groovy that I have found useful for testing are:

The org.springframework.jdbc.object.SqlUpdate class is another tool that I use a lot. This class encapsulates INSERT , UPDATE , and DELETE queries as beans defined within your application context. In most situations, you will be using the SqlUpdate class as-is with multiple configurations within a DAO's context. Since the class is not abstract, it is quite easy to extend for creating dummy/mock instances for testing.

I'm currently working on a development package containing a series of .xsd files which will be used to define the external interface for our web service. Due to some other project constraints, it was decided that this package also needed to include the .wsdl files which will further define the web service.

The Hamcrest Matchers framework contains a series of Matcher classes which help implement comparison and assertion methods in a type-safe, declarative manner. When used in tests, the Matchers framework will produce more legible test code and more helpful failure messages. The Matchers framework is partially included in the JUnit 4.4 package and some portions can be used effectively. But, the full power of the framework can only be unleashed by including the real Hamcrest Matchers jar within your testing environment.

The JUnit framework is arguably the de-facto standard for unit testing java code, and is also the basis of many other testing frameworks (unit or otherwise). Using the JUnit framework, one can quickly run a test method, class, or suite and get one of three responses: Success: All of the assertions in the test method passed, no fail calls were encountered, and no unexpected exceptions were thrown. Failure: One of the assertions in the test method failed or a fail call was encountered. Error: An unexpected java.lang.Throwable was thrown within the test method's body.

There are a couple of interesting Spring classes which keep coming up in my daily work: RowMapper and MappingSqlQuery .

Often there are Spring-related configuration options which don't belong inside the final jar/war for a Java application. Either because the options are different for each deployment environment or because the value of the option is sensitive ( passwords ). The PropertyPlaceholderConfigurer class attempts to remedy the management and injection of the values for these options. It reads one or more property files, optionally using system properties for defaults, and uses the values found to fill property placeholders of the form ${property name} found in the ApplicationContext in which the configurer is defined.

While I've been using Spring in various capabilities for some time now, I've never run across a situation where I've needed to execute a sql query with a duplicated parameter from code utilizing Spring. The following is a simple example of the type of query I ran into:

I just wanted to give a shout-out to the members of the jTrac project. jTrac is an issue-tracking system which can be installed out of the box as a stand-alone server using Jetty and HSQLDB, or can be installed as a war in an existing server.

An update to this post . Okay, so we have been able to make the caching work with very little changes to our mappings. By moving the cache element from the child entity definition into the collection declaration in the parent entity we have gotten the caching to work.