Spring-WS SAAJ problem in JBoss

Published on August 29, 2010

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

Published on July 22, 2010

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.

Resizing a virtual hard disk

Published on May 2, 2010

No matter what size hard disk you have, sooner or later you’ll find it’s too small. This is just as true for virtual hard disks as it is for physical ones. One of the benefits of virtialization is that you can change your ‘hardware’ setup on a whim. Want an extra gigabyte of memory? No problem, just assign it in your virtual machine config. So long as your host machine has capacity and the guest O/S supports it, this is easy to do.

Frustratingly though, none of the main VM software vendors (VMWare, Microsoft Virtual PC / Server and Sun VirtualBox) offer a way to resize a disk from the standard user interface. It is possible, but it takes a little fiddling to get it to work.

Code Bubbles

Published on April 26, 2010

I’ll try to avoid simply reposting other people’s stuff here, but this is something I’d like to keep an eye on:

Code Bubbles

In its own words, it’s Rethinking the User Interface Paradigm of Integrated Development Environments.

Memory usage

Published on April 10, 2010

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.

Bang!

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.

Bugs part 3: Don’t shoot the messenger

Published on January 17, 2010

I’ve spent the last couple of posts discussing developers’ attitudes to bug tracking. More often than not, it could be better. In this third and final post on how developers deal with bugs, I’ll discuss how we might improve our attitudes. Forgive me, but just this once I want to go all hand-wavey and go on about positive attitudes, constructive criticism and so on.

Would it come as a surprise to you if I said that developers see bugs in a negative light? Yes, when we see other people criticising our software, telling us that it’s not good enough, saying “no mate, it’s broke”, we take it as a personal insult. I can’t imagine why.

Bugs part 2: Towards perfection

Published on January 6, 2010

There is an expectation placed on developers – and pretty much everyone else – that they must strive towards perfection. Failure is not an option. There’s a general attitude anyone who makes mistakes is not good enough. When mistakes are made, heads should roll.

There’s a nasty cycle where mistakes are ignored or at least forgotten about. First, we all assume that we are good at what we do. When mistakes (inevitably) happen, we assume therefore that they’re someone else’s fault. If the system does not behave the way the customer expects it to, we assume it was poorly specified. If a bug makes it to production, we assume that the tester failed. Even if it’s decided that the bug is our fault and our fault alone, we assume it was a one-off mistake – a bad code day or whatever. Or else assume that it’s the sort of mistake that we’d have made a year or two ago but we’re too experienced to let that sort of thing happen again. Either way, we assume it won’t happen again. Because we’re good at what we do.

The big problem is that we assume that we’re perfect. We’re not. There’s a simple test: Have you ever made a mistake? If the answer’s yes, you’re not perfect. If the answer’s no, you’re a liar. And not perfect.

Bugs part 1: Don’t mention the war

Published on December 21, 2009

My wife – a doctor – has been looking recently at safety systems in the aviation industry and their applications to the health service. In particular, how errors are reported and followed up. Apparently, NASA’s Aviation Safety Reporting System (ASRS) is the way to go. Every industry wanting to improve safety and reduce errors looks to NASA and ASRS.

Software is usually not quite as safety critical as aviation or health but one of the key targets for a software business is quality. Even if people would not die as a result of buggy software, we usually want high quality bug free software as the long term cost is lower and so profits are higher. Yet I often find the general attitude to bugs and mistakes is all wrong. The standard attitude is:

My boss wants bug-free software. Bugs make my boss unhappy. Therefore, my boss will be happier if he doesn’t know about the bugs.

It’s slightly simplistic perhaps, but who can honestly say that they’ve discovered some obscure bug in the system and felt absolutely happy about bringing it to the attention of management or other developers? Have you never considered just conveniently forgetting all about it?

JUnit testing Hibernate and Spring

Published on November 15, 2009

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.

Continue readingJUnit testing Hibernate and Spring

Less is More and other cliches

Published on November 8, 2009

We’ve recently released the latest version of our product. A relatively minor change – just a couple of months dev plus same again in QA. As we get closer to the release date, we’re less inclined to make major changes to the codebase. Unit tests or no, it’s just not appropriate to perform major refactor work in response to a bug report the week before release. So we tiptoe round the code, tweaking this and adjusting that with only one eye on how maintainable it will be in future.

For example, a few days before release I found that a few text fields on a web form were completely redundant. Whatever they wired up to has been replaced by something that can work out the value for itself. Should I have removed the text area? I was 99% sure it was safe to do so, but I must have made judgement calls like this 80 or 90 times in my career. I’m due to get one wrong soon. And the consequences would be another phase of QA, making the project late or (worse) releasing a broken product.

The result of this is that beautifully designed code is written during the dev phase, it’s carefully rationalised and refactored. Should anything be found not to hang together quite right during QA, out comes the gaffer tape.

Don't Panic! Posts