Skip to content

Category: Java Technologies

Spring-WS SAAJ problem in JBoss

I recently used Spring-WS in an application that we wanted to deploy under JBoss 4.0.1sp1 / JDK 1.5 and JBoss 5.1.0GA / JDK 1.6. I had a good few problems getting the dependencies just right but the biggest problem was with SAAJ.

If you’re running JBoss 4.0.1sp1 and JDK 1.5, you’ll need to package a SAAJ implementation with your app. Easy enough. However, if you’re running JBoss 5.1.0GA and JDK1.6, you don’t want to include a SAAJ implementation as it’s included in the JDK 1.6 release. Also easy enough? Er no.

Maven 1 to Maven 2

I’ve been using Maven 1 for close on to five years now.  I’ve been meaning to upgrade to Maven 2 for pretty much all of that time but never quite got round to it. A combination of my starting work on a new project and finding some nasty bugs in Maven 1  has finally nudged me towards Maven 2.

Surprisingly, in my team of around a dozen developers, we’ve had only minimal exposure to Maven 2. Everyone has stuck loyally to the now completely obsolete and unsupported Maven 1. I think everyone hopes someone else will do the hard work first.

As we have dozens of build projects in our repo I can’t migrate them all at once. I’m just doing my project and its immediate dependencies. Unfortunately, this causes problems for the old Maven 1 projects as Maven 2 repos are not compatible with Maven 1. So during the transition period I must ensure that both old style Maven 1 projects and new style Maven 2 projects have access to their dependencies from one or other of the repos.

Memory usage

A year or two back I was working on a web application which was expected to have moderate use – around 50 concurrent users. The product was generally getting thumbs up from our QA guys. It did everything we expected it to do. Then we had a go at testing under load.


We found that if we had only a few users hammering the system for any length of time, the memory usage became unacceptable. Simple maths showed that the problem was to do with the number of open sessions. Each session required 20-30MB of memory from the app server. This is a piddly small amount when we have a handful of test users. It went completely unnoticed against the background noise of a typical server’s memory use. However, once just a hundred sessions have been opened (not necessarily at the same time) we’re chewing gigabytes at a time.

JUnit testing Hibernate and Spring

Here’s a nice recipe for unit testing Spring configured Hibernate. It allows me to neatly test my Spring configured DAOs and reuse a lot of the Hibernate Session and Transaction configuration beans from my production code. This saves having to rewrite it for my tests and also makes the tests more realistic. I’d rather test my production code rather than use mocks as far as possible.

Bean introspection

Spotted this nasty little quirk today – not for the first time. Every time I see it I want to get angry at someone but I’m not quite sure who.

What’s wrong with this list of properties?

private String name;
private String address;
private String eMail;

Nothing immediately obvious perhaps. Here are the standard generated getters and setters (signatures only):

public String getName();
public void setName(String name);

public String getAddress();
public void setAddress(String address);

public String getEMail();
public void setEMail(String eMail);

All perfectly valid. Now, given these auto-generated getters and setters, what names would standard bean introspection derive?


Hang on, what happened there? How did my eMail property turn into EMail?