englishteeth.co.uk

Something that felt like forever to track down…

A test running problem free on the test server was throwing a transformer error locally:

javax.xml.transform.TransformerException:
Had IO Exception with stylesheet file: C:\jboss-4.0.3SP1\server\default\conf\documentservice\pmi\include.xslt
at org.apache.xalan.processor.TransformerFactoryImpl.processFromNode(TransformerFactoryImpl.java:126)
...


On the surface, it looked like there was no difference in the environments; same deployed war file, same JBoss version, same Java version, same everything. Obviously something was different…

Xalan 2.7.0 was distributed in the WEB-INF/lib of the war, but stepping through the code on the failing local server, the byte code didn’t match the attached source. It wasn’t 2.7.0 being used, it was actually the 2.6.0 version shipped with JBoss (found in lib/endorsed).

It turns out that libraries in the lib/endorsed directory are considered system libraries by virtue of being loaded by the System and bootstrap class loaders and as such being used in preference to deployed war files version. (It should be noted that this is an older version of JBoss, namely 4.0.3 SP1.)

That explained why the wrong class was being picked up locally, but not why it worked in the test server environment.

The main difference was that the server was being run as a service on the test server and via a batch file locally.

Purely by chance, the endorsed.dirs parameter had been missed from the configuration of the service wrapper.

wrapper.java.additional.2=-Djava.endorsed.dirs=%JBOSS_HOME%\lib\endorsed

Striking this out of the local batch file, sanity returned once more.

rem set JBOSS_ENDORSED_DIRS=%JBOSS_HOME%\lib\endorsed

Removing Xalan and Xerces from lib\endorsed would have much the same effect and is proposed in this jira task at jboss.org

Having persevered with mapping my existing database in grails, it actually made for much cleaner domain objects.

I never much liked when hibernate started creeping out of configuration and into the code via Java annotations, so on the same score, it was cathartic to remove the database aware gorm mappings from my domain classes.

Adding the hibernate configuration was straight forward and clean and tucked away in the conf/hibernate directory; an hibernate.cfg.xml file listing the mapping resources and an hbm.xml resource file for each entity.

All was going swimmingly until I was adding my last domain class; modelling an Application.

As soon as I wanted to “show” a particular Application I was getting a ClassCastException.

It would appear that I’m not the first to hit this, so luckily I didn’t have waste too much time trying to figure out why:

application/create throws java.lang.ClassCastException: Application cannot be cast to javax.servlet.ServletContext

Apparently…

there is a variable in the GSP binding called ‘application’ that is the ServletContext this gets overridden when you return the model from the controller

The bug is on create, but I guess as I am coming from the legacy database angle, I didn’t have to “create” before I tried to “show”.

Mmm.

I had to rediscover a bit of lost knowledge last Friday, namely integrating Selenium RC into a set of integration tests. Pretty straight forward really, but I thought I’d better record it for the next time I can’t remember how to start and stop the server from ant.

<project name="Selenium RC Server">

	<target name="start_selenium_rc" description="Start the Selenium RC server">
		<java
			jar="selenium-server.jar"
			fork="true" failonerror="true">
			<arg value="-Port" />
			<arg value="4440" />
			<arg value="-forcedBrowserMode" />
			<arg value="*iehta" />
		</java>
	</target>

	<target name="stop_selenium_rc" description="Stop the Selenium RC server">
		<get taskname="selenium-shutdown"
			src="http://localhost:4440/selenium-server/driver/?cmd=shutDown"
			dest="junit_report/result.txt" ignoreerrors="true" />
	</target>

</project>

The forced browser mode is IE for project constraints, but I did have an issue with *iexplore not working due to some proxy error but the experimental “elevated security privilege” browser worked fine.

Not so fine is that the goBack() command does not work in SeleniumRC with “*iehta”.

A colleague pointed out an aspect of auto boxing in Java 5 that could catch you out. Which I have hopefully captured in the following contrived little unit test.

	@Test
	public void shouldTakeCareWithAutoBoxing() throws Exception {

		Map<String, Integer> myMap = new HashMap<String, Integer>();

		String letters = "Gotchas";
		Integer count = 0;

		myMap.put(letters, count);

		// count the letters
		for (int i = 0; i < letters.length(); i++) {
			count++;
		}

		assertSame(letters.length(), count);

		assertNotSame(letters.length(), myMap.get(letters));
		assertNotSame(count, myMap.get(letters));

	}

Auto boxing allows you to do seemingly convenient things, such as manipulate your Integer object like you would a primitive. However, Integers are immutable and what incrementing count is doing behind the scenes is referencing a new instance of an Integer with the updated value. Therefore count no longer references the object placed in the Map, that’s the old object…

Putting the each incremented value in the map would at least give you what you might be trying to achieve…

		// count the letters
		for (int i = 0; i < letters.length(); i++) {
			myMap.put(letters, ++count);
		}

		assertSame(letters.length(), count);
		assertSame(letters.length(), myMap.get(letters));
		assertSame(count, myMap.get(letters));

…but it’s not nice.

Following a quick google search I found Autoboxing Considered Harmful which provided an even more interesting aspect, which I have reproduced here as a simple JUnit test.

import org.junit.Test;
import static org.junit.Assert.*;

public class FurtherExperimentsInAutoBoxing {

	@Test
	public void twoObjectsWithTheSameValueShouldNotBeTheSame() throws Exception {

		Integer a1 = new Integer(150);
		Integer a2 = new Integer(150);

		assertNotSame(a1, a2);

	}

	@Test
	public void withAutoboxingTheyCanAppearToBe() throws Exception {

		Integer a1 = 100;
		Integer a2 = 100;

		assertSame(a1, a2);

	}

	@Test
	public void sometimesAnyway() throws Exception {

		Integer a1 = 150;
		Integer a2 = 150;

		assertNotSame(a1, a2);

	}

}

As the original author points out in his post, this is not the way you would want to write these, but for someone trying to grasp the concepts of what an object is and how to deal with them, these language features wouldn’t exactly help.

In my struts 2 project, I have an action that implements the ScopedModelDriven interface.

I have configuration that references the ScopedModelDrivenInterceptor with a session scope…

	<interceptor name="scoped-model-driven" class="com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor">
	     <param name="scope">session</param>
	</interceptor>

My action references this interceptor and specifies the key used when the object was previously put in the session.

	<interceptor-ref name="scoped-model-driven">
		<param name="name">session-key</param>
	</interceptor-ref>

This all works fine, except in my freemarker templates I now need to reference model.myproperty, rather than just property.

I could live with that, but unfortunately

	<#if myproperty?has_content>
		...

no longer returns any results and worse

	<#if model.myproperty?has_content>
		...

blows up completely!

javax.servlet.ServletException: ?size is unsupported for: freemarker.ext.beans.SimpleMethodModel
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:515)
org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:419)
com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:119)
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:55)
org.apache.struts2.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:99)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)


I’ve tried a few variations of reference to no avail.

Very disappointing.
The reason I’m writing this up is that the scoped model driven thing looked almost exactly how I wanted to go with these actions, so I want to remember where I got to, but getting it working is more important.

Back to ModelDriven, SessionAware and Preparable…