Source Allies Blog » Java

Hibernate Logging

David Kessler — Mon, 30 Jan 2012 14:54:22 +0000

Through the years I’ve encountered a recurring requirement. Clients need to log changes to the database for auditing and legal purposes. To satisfy this requirement you could add logging to every save/update/delete call in your code. Or better yet, you could create an aspect that wraps these calls. While these would certainly work Hibernate provides a convenient interceptor.

In this article I will show you how to add a simple logger to Hibernate.

Start with a Test

As an avid TDD practitioner I will of coarse start with a test. Here is the final version of the test that I used to drive my code.

package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;
 
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.logging.Log;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class HibernateInterceptorTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	@Resource
	private HibernateInterceptor hibernateInterceptor;
 
	private Session currentSession;
 
	private Log logger;
 
	private static final Date NOW = new Date();
 
	@Before
	public void setUp(){
		logger = mock(Log.class);
		currentSession = sessionFactory.getCurrentSession();
		hibernateInterceptor.setLogger(logger);
	}
 
	@Test
	@Transactional
	public void testSaveLogging(){
		saveOrUpdate(createPerson());
 
		assertEquals(1, findAll().size());
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testUpdateLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
		firstPerson.setFirstName("testFirst2");
 
		saveOrUpdate(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Updating Person [firstName=testFirst2, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testDeleteLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
 
		delete(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Deleting Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Transactional
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@Transactional
	public void delete(Person person) {
		currentSession.delete(person);
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
 
 
	private Person createPerson() {
		Person person = new Person("testFirst", "testLast", NOW);
		return person;
	}
}

I used a mock logger to gather information from the interceptor.

Spring Configuration

Here is the configuration required for the interceptor.

 
	 id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
                ...
		 name="dataSource" ref="dataSource" />
		 name="entityInterceptor" ref="hibernateInterceptor"/>
	>
 
	 id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
		 name="sessionFactory" ref="sessionFactory" />
	>
         ...	
	 base-package="com.sourceallies" />
        ...

The ‘entityInterceptor’ property on the ’sessionFactory’ takes a Hibernate interceptor.

Entity

@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	private Date birthDate;
...
	@Override
	public String toString() {
		return "Person [firstName=" + firstName + ", lastName="
				+ lastName + ", birthDate=" + birthDate + "]";
	}
}

For this example you need to implement the ‘toString’ method on the entity being logged.

Interceptor

Here is the interceptor code.

package com.sourceallies.logging;
 
import java.io.Serializable;
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.hibernate.EmptyInterceptor;
import org.hibernate.type.Type;
import org.springframework.stereotype.Component;
 
@Component
public class HibernateInterceptor extends EmptyInterceptor {
 
	private static final long serialVersionUID = 1L;
	private Log logger = LogFactory.getLog(HibernateInterceptor.class);
 
	@Override
	public void onDelete(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Deleting", id, entity);
		super.onDelete(entity, id, state, propertyNames, types);
	}
 
	@Override
	public boolean onFlushDirty(Object entity, Serializable id,
			Object[] currentState, Object[] previousState,
			String[] propertyNames, Type[] types) {
		log("Updating", id, entity);
		return super.onFlushDirty(entity, id, currentState, previousState,
				propertyNames, types);
	}
 
	@Override
	public boolean onSave(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Saving", id, entity);
		return super.onSave(entity, id, state, propertyNames, types);
	}
 
	protected void setLogger(Log logger) {
		this.logger = logger;
	}
 
	private void log(String action, Serializable id, Object entity) {
		logger.info(action + " " + entity + ".");
	}
}

While the ‘onSave’ and ‘onDelete’ methods are clearly named the ‘onUpdate’ method appears to be missing. With a little research it quickly becomes obvious that ‘onFlushDirty’ is used for updates.

Logging database activity is this simple.

Here is the complete code. Hibernate Logging Zip

Back to Basics: hashCode() & equals()

David Kessler — Tue, 06 Dec 2011 15:53:22 +0000

So we all know that if we implement equals() we must override hashCode() too. But why? The best explanation of this commandment can be found in Effective Java (2nd Edition) starting on page 45.

… Failure to do so will result in a violation of the general contract for Object.hashCode, which will
prevent your class from functioning properly in conjunction with all hash-based
collections, including HashMap, HashSet, and Hashtable. (Bloch, Effective Java, 2nd Ed.)

If you’re like me, you like to see a problem in running code. Well here you go.

	@Test
	public void testHashMapRetrieval_WithoutHashCode(){
		PersonWithoutHashCode person = new PersonWithoutHashCode("first", "last");
		PersonWithoutHashCode person2 = new PersonWithoutHashCode("first", "last");
		Map<PersonWithoutHashCode, String> map = new HashMap<PersonWithoutHashCode, String>();
		map.put(person, "friend");
 
		assertNull(map.get(person2));
	}
 
	@Test
	public void testHashMapRetrieval_WithHashCode(){
		PersonWithHashCode person = new PersonWithHashCode("first", "last");
		PersonWithHashCode person2 = new PersonWithHashCode("first", "last");
		Map<PersonWithHashCode, String> map = new HashMap<PersonWithHashCode, String>();
		map.put(person, "friend");
 
		assertNotNull(map.get(person2));
	}

Two equivalent ‘PersonWithoutHashCode’ instances are not considered equivalent when the ‘get’ method is called on HashMap. On the other hand the ‘PersonWithHashCode’ instances are considered equivalent for the same method.

While you can implment equals() and hashCode() by hand or generate them with your IDE, you might consider using the Objects class within the Guava Libraries. Here is the Person class using Guava.

	@Override
	public int hashCode() {
		return Objects.hashCode(firstName, lastName);
	}
 
	@Override
	public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (getClass() != obj.getClass())
			return false;
		PersonWithGuava other = (PersonWithGuava) obj;
		return Objects.equal(firstName, other.firstName) 
				&& Objects.equal(lastName, other.lastName);
	}

Here’s the test for this new code.

	@Test
	public void testHashMapRetrieval_WithGuava(){
		PersonWithGuava person = new PersonWithGuava("first", "last");
		PersonWithGuava person2 = new PersonWithGuava("first", "last");
		Map<PersonWithGuava, String> map = new HashMap<PersonWithGuava, String>();
		map.put(person, "friend");
 
		assertNotNull(map.get(person2));
	}

So why use this? This helps make our code DRY. Much of the generated code for the ‘hashCode()’ and ‘equals()’ method can be encapsulated. The Guava Library has done just that for us. If the implementation needs to be changed it can be updated in one place.

Now if you’re like me, you are lazy. As a lazy person I ask myself, “Do I want to write code that I can generate?”. My initial thought is “no”. Luckily you can use this new library and continue to generate your ‘equals()’, ‘hashCode()’ and even your ‘toString()’ methods. Simply add the Guava Eclipse plugin to your favorite version of Eclipse and voila.

This plugin adds new menu options.

This is the code that the plugin generated for the Person class.

	@Override
	public int hashCode(){
		return Objects.hashCode(firstName, lastName);
	}
 
	@Override
	public boolean equals(Object object){
		if (object instanceof PersonWithGuava) {
			PersonWithGuava that = (PersonWithGuava) object;
			return Objects.equal(this.firstName, that.firstName)
				&& Objects.equal(this.lastName, that.lastName);
		}
		return false;
	}

While we all know that we must override ‘hashCode()’ and ‘equals()’ together, we also know that we should eliminate duplication in our code and encapsulate common functionality. Install the Guava plugin today and remove another piece of duplication from your code.

Please read the comments below before you use this plugin.

Here’s the complete code HashCode.

Debugging memory leaks with VisualVM

Cory Wandling — Mon, 18 Jul 2011 12:45:01 +0000

At work I had run into a memory leak when scrolling through large result sets returned from Hibernate. I thought I had fixed it by performing a evict()/clear()/flush() in the HibernateTemplate that I was using but suddenly the leak was back. I was using VisualVm to monitor the heap so I started poking around to see if there was anything to help diagnose where the leak was.

First thing I did was to take a heap dump.

I selected the classes and I see

Well THAT was not helpful. It turns out that the leak is in a class that only has one instance and it is holding onto thousands of objects.
Then on the summary page I notice the “Find 20 biggest objects by retained size:”.

I click it and a long time later I see

Shazam! There it is! In this faked up example I built there is a single Stack instance but it’s retained size is huge. That because VisualVM computed not just the size of that object but the sizes of all of the objects it was holding onto. How sweet is that. I found my memory leak in like 5 minutes.

Another useful tool!

Would you start mocking me?

David Kessler — Thu, 05 Aug 2010 14:54:39 +0000

One of the primary principles of unit testing is to test a small piece of functionality in isolation. In order to achieve this, mock objects are often necessary. Historically using mocks could be quite painful. After using several mock frameworks, my favorite by far is Mockito.

Tutorial

In this tutorial we will walk through examples of the most common features of Mockito. My sample project can be downloaded here.

Interfaces and Implementation

Some mocking frameworks only supported mocking interfaces. As a result our projects became bloated with useless interfaces that were only used for testing. Mockito creates mock objects with interfaces or classes.

interface Person{
   List getChildren();
   Boolean isCitizen();
   Integer getAge();
   Map getSchedule();
   void haveChild();
}

class PersonImpl implements Person{
   public List getChildren() { return null; }
   public Boolean isCitizen() { return null; }
   public Integer getAge() { return null; }
   public Map getSchedule() { return null; }
   public void haveChild() { }
}

assertNotNull(Mockito.mock(Person.class));
assertNotNull(Mockito.mock(PersonImpl.class));

Default Values

Mockito provides stub implementations for all of the methods on the interface/class. It also provides several common sense defaults out of the box.

Person mockPerson = Mockito.mock(PersonImpl.class);
assertNotNull(mockPerson.getChildren());
assertEquals(0, mockPerson.getChildren().size());
assertFalse(mockPerson.isCitizen());
assertEquals(new Integer(0), mockPerson.getAge());
assertNotNull(mockPerson.getSchedule());

Mockito returns empty Lists and Maps to prevent NPE’s in your test code. It defaults to false for Boolean return values. By default Zero is returned for Integer, Long and Double. Notice that even though PersonImpl returns null for all of its methods the Mockito version returns reasonable default values.

Changing Behavior

Person mockPerson = mock(PersonImpl.class);
Mockito.when(mockPerson.getAge()).thenReturn(35);
assertEquals(new Integer(35), mockPerson.getAge());

Mockito.when() takes a mock and a method call that returns a value. Mockito’s thenReturn() method takes the return value that Mockito will provide to all matching calls. By default the method getAge() returns Zero, within Mockito, but now it returns 35. This ability to control behavior is the key to testing functionality in isolation.

Verifying Method Calls

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
Mockito.verify(mockPerson).getAge();

Mockito.verify() takes a mock object and verifies that the following method is called.

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
mockPerson.getAge();
Mockito.verify(mockPerson, Mockito.times(2)).getAge();

This is the same verify as before except a second parameter is passed to the verify() method telling it how many times the trailing method should be called.

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
mockPerson.getAge();
Mockito.verify(mockPerson, Mockito.atLeastOnce()).getAge();

Sometimes it is not important how many times a method is called as long as it is called at least once. Mockito.atLeastOnce() method provides this flexibility.

No More Interactions

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
Mockito.verify(mockPerson).getAge();
Mockito.verifyNoMoreInteractions(mockPerson);

Mockito.verifyNoMoreInteractions() ensures that no other methods have been called on the PersonImpl class. Since Mockito is very helpful in stubbing out all of the methods for a class or interface there is no control over which methods have been called. Only methods that have been explicitly verified are checked for specific calls.

Throw Exception

@Test(expected = RuntimeException.class)
public void testThenThrow(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.when(mockPerson.getAge()).thenThrow(new RuntimeException("test exception"));
   mockPerson.getAge();
}

The thenThrow() method prepares the method defined in when() to throw an Exception. While I am not attempting to provide a tutorial on JUnit4 features, I feel it necessary to point out the Annotation verifies that a RuntimeException is thrown in the test.

@Test(expected = RuntimeException.class)
   public void testDoThrow(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.doThrow(new RuntimeException("test exception")).when(mockPerson).haveChild();
   mockPerson.haveChild();
}

The doThrow() syntax is necessary to throw an Exception for a void method. The previous example threw an exception for Person.getAge() which is not a void method. In this example Person.haveChild() is void and requires this alternate syntax in order to compile.

TDD with Mockito

Let’s drive a small class that we will call Bouncer. This class will check if a Person is old enough to drink. First let’s write a test.

@Test
public void testCheckAgeOf_UnderAge(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.when(mockPerson.getAge()).thenReturn(20);
   Bouncer bouncer = new Bouncer();
   assertFalse(bouncer.checkAgeOf(mockPerson));
}

Of coarse this does not even compile. We need to create a Bouncer class with the checkAgeOf() method. And here is the amazing class

class Bouncer{
   public boolean checkAgeOf(Person customer){
      return false;
   }
}

So why did I return false. Well the test does not require anything more than this to pass. TDD is about doing the simplest thing that works and then refactor the code. This is the simplest thing that works. Now let’s write another test.

@Test
public void testCheckAgeOf_OfAge(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.when(mockPerson.getAge()).thenReturn(21);
   Bouncer bouncer = new Bouncer();
   assertTrue(bouncer.checkAgeOf(mockPerson));
}

Now we need real business logic in our method.

return customer.getAge() &gt;= 21;

Green again. Now it is time to refactor. In this simple case I am not sure how to simplify the code. There are a few more tests that should be written. A test if getAge() returns null and if Person is null and other boundary cases. Since the focus of this article is on Mockito I will stop here.

Mockito is a powerful mocking framework that simplifies the creation and usage of mock objects. I encourage you to download my sample code and continue to explore the Mockito framework.

Rendering Global t:messages After Redirect

Max Kuipers — Mon, 08 Mar 2010 19:24:46 +0000

A common problem when working with JSF is getting global info messages via or to display messages set in the previous request when you have a in your faces-config for a particular page You will not see your that are set on the previous page.

The Problem

For instance, say you have two pages – page1.xhtml and page2.xhtml. In your faces-config.xml, you will have 2 entries.

>
	>page1>
	>/pages/page1.xhtml>
	/>
>
 
>
	>page2>
	>/pages/page2.xhtml>
	/>
>

Let’s say page1Bean is called in page1 and you want it to display messages in page2. So your bean would have something like this:

public class page1Bean {
	...
	public String page1Action{
		...
		/** Add message */
		FacesMessage facesMessage = new FacesMessage();
		...
		FacesContext.getCurrentInstance().addMessage(null, facesMessage);
		...
		return "page2";
	}
	...
}

Your page2.xhtml has like the following somewhere in it.

One would expect that this would display the message on the next page, however these messages are request scoped and so are not available in this second request and you do not see your message unless you remove the on page2.

Fortunately, there is a nifty and quick solution. Basically, it is a phase listener that saves the messages from the previous request and then restores them just before the RENDER_RESPONSE phase of the second request.

The Solution

To solve the problem, save the following class into some package where your faces-config will be able to access it

package com.myproject.web.jsf.phaselistener;
 
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
 
import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
 
/**
 * Enables messages to be rendered on different pages from which they were set.
 * To produce this behaviour, this class acts as a PhaseListener.
 *
 * This is performed by moving the FacesMessage objects:
 *
	After each phase where messages may be added, this moves the messages from
 * the page-scoped FacesContext to the session-scoped session map.
 *
	Before messages are rendered, this moves the messages from the session-scoped
 * session map back to the page-scoped FacesContext.
 *
 * Only messages that are not associated with a particular component are ever
 * moved. These are the only messages that can be rendered on a page that is different
 * from where they originated.
 *
 * To enable this behaviour, add a lifecycle block to your
 * faces-config.xml file. That block should contain a single phase-listener
 * block containing the fully-qualified classname of this file.
 *
 * EDIT: This code was minimally modified by Max Kuipers to address some of the Java 1.6
 * compiler warnings.  All code was originally written by Jesse Wilson.
 *
 * @author Jesse Wilson
 * @author Max Kuipers
 */
 
public class MessageHandler implements PhaseListener {
	private static final long serialVersionUID = 1L;
 
	/**
	 * a name to save messages in the session under
	 */
	private static final String sessionToken = "MULTI_PAGE_MESSAGES_SUPPORT";
 
	/**
	 * Return the identifier of the request processing phase during which this
	 * listener is interested in processing PhaseEvent events.
	 */
	public PhaseId getPhaseId() {
		return PhaseId.ANY_PHASE;
	}
 
	/**
	 * Handle a notification that the processing for a particular phase of the
	 * request processing lifecycle is about to begin.
	 */
	public void beforePhase(PhaseEvent event) {
 
		if(event.getPhaseId() == PhaseId.RENDER_RESPONSE) {
			FacesContext facesContext = event.getFacesContext();
			restoreMessages(facesContext);
		}
	}
 
	/**
	 * Handle a notification that the processing for a particular phase has just
	 * been completed.
	 */
	public void afterPhase(PhaseEvent event) {
 
		if(event.getPhaseId() == PhaseId.APPLY_REQUEST_VALUES ||
				event.getPhaseId() == PhaseId.PROCESS_VALIDATIONS ||
				event.getPhaseId() == PhaseId.INVOKE_APPLICATION) {
 
			FacesContext facesContext = event.getFacesContext();
			saveMessages(facesContext);
		}
 
	}
 
	/**
	 * Remove the messages that are not associated with any particular component
	 * from the faces context and store them to the user's session.
	 *
	 * @return the number of removed messages.
	 */
	private int saveMessages(FacesContext facesContext) {
		// remove messages from the context
		List messages = new ArrayList();
		for(Iterator i = facesContext.getMessages(null); i.hasNext(); ) {
			messages.add(i.next());
			i.remove();
		}
		// store them in the session
		if(messages.size() == 0) {
			return 0;
		}
		Map sessionMap = facesContext.getExternalContext().getSessionMap();
		// if there already are messages
		@SuppressWarnings("unchecked")
		List existingMessages = (List) sessionMap.get(sessionToken);
		if(existingMessages != null) {
			existingMessages.addAll(messages);
		}
		else {
			sessionMap.put(sessionToken, messages); // if these are the first messages
		}
 
		return messages.size();
	}
 
	/**
	 * Remove the messages that are not associated with any particular component
	 * from the user's session and add them to the faces context.
	 *
	 * @return the number of removed messages.
	 */
	private int restoreMessages(FacesContext facesContext) {
		// remove messages from the session
		Map sessionMap = facesContext.getExternalContext().getSessionMap();
		@SuppressWarnings("unchecked")
		List messages = (List)sessionMap.remove(sessionToken);
		// store them in the context
		if(messages == null) {
			return 0;
		}
		int restoredCount = messages.size();
		for(Iterator i = messages.iterator(); i.hasNext(); ) {
			facesContext.addMessage(null, i.next());
		}
 
		return restoredCount;
	}
}

And then add something like the following in your faces-config.xml. Be sure to replace the example package location with your own.

>
	>com.myproject.web.jsf.phaselistener.MessageHandler>
>

The forum post that documented this solution is here.

Environment Specific Properties in Spring

Travis Klotz — Mon, 01 Mar 2010 19:10:16 +0000

On many occasions I want to be able to inject environment specific property values into my Spring managed beans. These may be things like web service endpoints, database URLs, etc. Values I know for each environment at build time, but I want to use the same WAR/EAR file in each environment. I would like to keep the actual values separate from the Spring config files themselves. And I would really like to manage a set of default values for each property, so that I do not need to specify a value for every property in every environment (ex. my credit card processing URL for dev, test, uat is the same, but for production it is different.)

Spring already has 90% of this solution already worked out. The PropertyPlaceholderConfigurer can be used to externalize property values into Java properties files. These properties can then be referenced “ant style” in your configuration files ex. ${myPropertyValues}. It can even handle multiple files, checking them in order for each property, so one file can override one or move values that are stored in another. However the PropertyPlaceholderConfigurer doesn’t have any concept of an environment specific file.

Thats where we come in:

package com.sourceallies.config;
 
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.Resource;
 
public class EnvironmentPropertyPlaceholderConfigurer extends
		PropertyPlaceholderConfigurer {
 
   @Override
   public void setLocation(Resource location) {
      if (!(location instanceof ClassPathResource)) {
         throw new RuntimeException(
               "EnvironmentPropertyPlaceholderConfigurer " + 
               "locations must be on the classpath");
      }
 
      ClassPathResource cl = (ClassPathResource) location;
      String filename = cl.getFilename();
 
      //switch  "env.properties" to "env.dev.properties"
      String envFilename = filename.replaceAll(
            "(.*)\\.properties", 
            "$1." + getEnvironment().toLowerCase() + ".properties");
 
      Resource envLocation = cl.createRelative(envFilename);
      if (envLocation.exists()) {
         setLocations(new Resource[] { location, envLocation });
      } else {
         setLocations(new Resource[] { location });
      }
   }
 
   public String getEnvironment() {
      /*
       * Magic goes here. This method must be able to determine which
       * environment it is running in without any help from injected
       * properties.
       */
 
      return System.getProperty("sai.env", "DEV");
   }
}

This version of the configurer expects a single resource to be passed in via the location property. In this case I restrict it only to ClassPathResource instances, but really it can be any version that can generate a new resource with a relative path. The resource we configure here should be the “default” file, the configurer will then build an environment specific file based on the default name and check its existence. If the environment specific file is found the are ordered up so that any properties in the environment file will override the values in the default file. If no environment file is found, only the default file is used.

The only real magic here is how the configurer determines the environment that its running in. In this simple case, the configurer relies on a system property to tell it what environment its running in. In larger organizations I have found that getting system properties set reliably across environments to be extremely difficult (most shops still tack on application server administration to the jobs of the DBA’s or the Unix/Windows admins who are already overworked.) In these cases, more extreme methods may be needed to determine the environment name. JNDI lookups, Database queries, reading files from the file system may all be good solutions. The important thing is that you can’t inject the environment name, if it were that easy, we wouldn’t actually need this configurer!

Replacing and Patching Java Application and Core classes

Alexandru Luchian — Mon, 15 Feb 2010 16:00:40 +0000

Why would you ever need that?

Say you get a jar file. After using the jar for a while you realise that there is a bug in a class in the jar file. Unfortunately you also find out that the jar is no longer supported and there is no way you will get a fix from the author (who is long gone fishing).

In order to solve this issue, you first need to get the source of the class. If you are lucky enough and the author did not obfuscate the class file you can decompile it with a decompiler (my favourite one is JD-GUI).

After you get the source, you modify it, recompile and tell the java interpreter to load your new class first before the old one. Easy right?

Let me give you an example

Say we have this “outdated” Spider class

alex@tractorash:~/work/java$ pwd
/home/alex/work/java
alex@tractorash:~/work/java$ cat sai/Spider.java

package sai;
 
class Spider{
 
    private static final String URL = "http://www.google.com/search?q=best+software+2009";
 
    public String getURL(){
        return URL;
    }
 
}

Now, we have the Main class:

package sai;
 
class Main{
 
    public static void main(String[] args){
        Spider spider = new Spider();
        System.out.println(spider.getURL());
    }
 
}

Now, if we compile and run the Main class we will get:

alex@tractorash:~/work/java$ javac sai/Main.java
alex@tractorash:~/work/java$ java sai.Main
http://www.google.com/search?q=best+software+2009

As we expected. Suppose we want to search for http://www.google.com/search?q=best+software+2010. The only way to do that is create another sai.Spider class and return the needed string.

So, here we go

alex@tractorash:~/h$ pwd
/home/alex/h
alex@tractorash:~/h$ cat sai/Spider.java

package sai;
 
class Spider{
 
    private static final String URL = "http://www.google.com/search?q=best+software+2010";
 
    public String getURL(){
        return URL;
    }
}

We compile our new class

alex@tractorash:~/h$ javac sai/Spider.java

Then, switch to previous path:

alex@tractorash:~/h$ cd ~/work/java/
alex@tractorash:~/work/java$ java -cp /home/alex/h:/home/alex/work/java sai.Main
http://www.google.com/search?q=best+software+2010

So what did we do? We modified the classpath (http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/classpath.html) and told the JVM to load our new class first, since it’s first in our list of directories we specified as classpath.

This way we “tricked” the JVM in loading our new class first so we could get the desired output.

What we’ve done so far is called replacing and patching application classes.

You will not be able to modify/replace system classes like java.lang.Integer using this method.

You are probably wondering why would you ever want to replace java.lang.Integer. Let me give you an example. As you might know the Integer class is immutable, in other words once the object is initialised you cannot modify it’s value. So, let’s add a new method called setValue(int newVal) which will modify the current value of the Integer object.

As you can imagine, applying the method used in the Spider class example will not work. The reason is: to load system classes and libraries, the JVM does not use the CLASSPATH variable, but the BOOTCLASSPATH. The boot strap class loader uses the boot class path to load the main/system classes.

What’s interesting is that you can specify/modify the BOOTCLASSPATH as well. In order to to that we have to use the -X argument for the java launcher:

alex@tractorash:~$ java -X
-Xbootclasspath:
set search path for bootstrap classes and resources
-Xbootclasspath/a:
append to end of bootstrap class path
-Xbootclasspath/p:
prepend in front of bootstrap class path

We are interested in the -Xbootclasspath/p: option since we want to prepend the directory that contains the patched Integer class.

First, let’s add that new method. Get the source of java.lang.Integer. You can get it either from the src.zip file that comes with the JDK, or download it from online.

Switch to our working directory:

alex@tractorash:/$ cd /home/alex/work/java/

Add the method:

public void setValue(int value){
    this.value = value;
}

If you are modifying a Java 6 version of Integer class you have to remove the final keyword from the value variable.

Was this:

private final int value;

Has to be this:

private int value;

Now we need a test class where we will test the new functionality. Let’s create the IntegerTest class:

public class IntegerTest{
    public static void main(String[] args){
        Integer tInt = new Integer(1);
        System.out.println("Initial value: " + tInt);
        tInt.setValue(25);
        System.out.println("New value: " + tInt);
    }
}

Compiling patched versions of system classes can be a little tricky.

First let’s compile our Integer class:

alex@tractorash:~/work/java$ javac java/lang/Integer.java
java/lang/Integer.java:571: warning: sun.misc.VM is Sun proprietary API and may be removed in a future release
if (!sun.misc.VM.isBooted()) {
^
Note: java/lang/Integer.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning

We get the warning because we use a sun.* class in our new class. Since sun.* packages and classes are proprietary to Sun, it is strongly advised not to use them, but in our case we just reuse them (so we can ignore the warning).

Now, we have our Integer.class file. We have to use it when we execute our test class.

Now compile IntegerTest.java:

alex@tractorash:~/work/java$ javac -Xbootclasspath/p:/home/alex/work/java/lang/:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/rt.jar IntegerTest.java
./java/lang/Integer.java:571: warning: sun.misc.VM is Sun proprietary API and may be removed in a future release
if (!sun.misc.VM.isBooted()) {
^
Note: ./java/lang/Integer.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning

Copy Integer.class to the directory where your IntegerTest class is:

alex@tractorash:~/work/java$ cp ./java/lang/Integer.class .

So IntegerTest.class and Integer.class are in the same directory.

Finally run IntegerTest:

alex@tractorash:~/work/java$ java -Xbootclasspath/p:/home/alex/work/java:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/rt.jar IntegerTest
Initial value: 1
New value: 25

Success! Now you have a mutable Integer class.

I recommend you read the Java Covert book.

However, I have to warn you that this post is for academic purposes only. Patching/removing/replacing Java core classes can be against the Java license agreement. Please consult the license before going down this path.

Keep your dataTable clean with a custom popup

David Casleton — Wed, 13 Jan 2010 14:05:57 +0000

The basic idea is to output some data to a user in a table and allow them to take an action on each row individually. A fairly straightforward solution is to create a separate page to link to, passing the necessary row information along. If the action is simple enough, like a single checkbox, you could just embed the necessary component(s) in each row of the table. Too many components, however, can bloat the table and make the UI cumbersome to the user. Instead we can create a popup window to overlay our page, containing whatever components are needed, and activate it by a link embedded in our table. Passing the row information is a little trickier, but the result is a cleaner interface and a better user experience.

The example implementation below is done using Java with JSF, a little JavaScript, a little jQuery, and some CSS. The tag libraries being referenced are:

xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:t="http://myfaces.apache.org/tomahawk"

The page is constructed using two separate forms, one for the main components of the page, including the datatable, and the other for the popup. A little JavaScript and jQuery are used to show/hide the popup form and pass around the pertinent row information. Some CSS is used to shadow the main page components while the popup is active.

Our simple main form is:

 id="someForm">
 
	 id="actionDetailsDiv" styleClass="info" 
			rendered="#{not empty myAction.actionDetails}">
		 escape="false" value="#{myAction.actionDetails}" />
	>
 
	 var="currentRow" 
			rowIndexVar="rowNum" 
			value="#{myAction.myData}" >
		>
			 name="header">
				 value="row" />
			>
			#{rowNum}
		>
 
		>
			 name="header">
				 value="some colummn" />
			>
			#{currentRow.someProperty}
		>
 
		>
			 name="header">
				 value="action links" />
			>
			 href="javascript:showHiddenForm('#{rowNum}')">action link>
		>
	>	
>

Here the row number (rowNum) has been passed to a piece of JS, but you could just as easily pass a property from the current row object. Also, actionDetails is a string on our backing action bean used to inform the user that the action has been taken on the appropriate data. This should be declared in the backing bean as an empty string and thus the containing div is not initially rendered.

Our hidden form is:

 id="hiddenForm">
	 id="backgroundDiv" class="fullscreen outer" />
 
	 id="foregroundDiv" class="centerPopup inner">
		>Action Heading>
 
		 id="hiddenInfo" forceId="true" />
 
 
		 value="Backing Action" actionListener="#{myAction.backingAction}"/>		
		 onclick="hideHiddenForm()" value="Cancel"/>
	>
>

To prove that the data in the hidden field is being populated correctly, change the inputHidden component to inputText.

The CSS referenced above is:

div.fullscreen {
	position:absolute;
	top:0;
	left:0;
	width:100%;
	height:100%;
}
 
div.centerPopup {
	position: fixed;
	top: 50%;
	left: 50%;
	height: 200px;
	width: 500px;
	overflow: auto;
	margin-top: -100px;
	margin-left: -250px;
}
 
div.outer {
	filter: alpha(opacity=50);
	-moz-opacity: 0.5;
	opacity: 0.5;
	background-color: #D8D8D8;
	z-index: 2000;
}
 
div.inner {
	background-color: #000000;
	z-index: 2001;
}
 
p.inner {
	color: white;
}
 
div.info {
    text-align: center;
    font-weight: bold;
    border-top: 1px solid;
    border-bottom: 1px solid;
}

Most of the CSS is pretty straightforward. The “outer” class is setup to make a div gray and transparent in most browsers and “centerPopup” creates a statically sized div in the middle of the screen. The crucial part of the CSS is the z-index used by the “inner” and “outer” classes. The higher the z-index, the higher on the stack the element is, thus to show the “inner” popup over the somewhat transparent “outer” fullscreen overlay, the popup’s z-index must be higher. Both z-indexes are set arbitrarily high to ensure other elements don’t interfere.

The JavaScript/jQuery to show and hide the hidden form is:

function hideHiddenForm() {
	$("#hiddenForm").hide();
}
 
function showHiddenForm(selection) {
	//set the value of the hidden field
	var thingy = document.getElementById("hiddenInfo");
	thingy.value=selection;
 
	$("#hiddenForm").show();
}
 
$(document).ready(function() {
	//initially hide the popup form
	hideHiddenForm();
});

Note showHiddenForm takes a single input and sets this as the value of the hiddenInfo element. Also, we need to hide the popup form when the page is first loaded.

In our backing bean (MyAction) the backingAction method needs to find the hidden field and do something with the value. Here the value is passed to the actionDetails property forcing actionDetailsDiv above the table to render when the page is rerendered. Typically we would actually act on the value instead of merely redisplaying it.

public void backingAction(ActionEvent event) {
	UIComponent link = (UIComponent) event.getSource();
	for (UIComponent divChild : link.getParent().getChildren()) {
		if (divChild.getAttributes().get("id").equals("hiddenInfo")) {
			String rowNum = (String) divChild.getAttributes().get("value");
			setActionDetails("Action taken on row " + rowNum);
			break;
		}
	}
}

The hidden form (popup) can become as complicated as you need and allows your main form to remain clean. If anyone knows an easier way to pull the value out of the hidden element, let me know.

Spring’s refreshable beans

Octavian Covalschi — Fri, 08 Jan 2010 14:00:19 +0000

A couple of days ago I found out about a really nice feature in Spring, called ‘refreshable bean’.

Spring’s vision a refreshable bean is a dynamic-language-backed bean that monitors changes to its source code and then reloads itself when changes occur. And it is all this is done without restarting/re-deploying entire app. Sweet!

Currently Spring supports only 3 dynamic languages: JRuby, Groovy, BeanShell.

A simple example taken from springsource’s website looks like:

>
    ...
     id="messenger"