Two Spring/Hibernate gotchas that got me
Earlier this week I got caught out by two Spring/Hibernate features. One of my service layer methods threw a checked exception after a bit of relatively complex validation, just like I intended. What happened next, however, was not expected. My test failed. Well, it didn't fail, it died with an error and a horrible stack trace of doom. Hibernate was kind enough to tell me that a batch update failed. This struck me as slightly odd, considering the fact that an exception was thrown long before any saving was meant to occur.
I had, apparently, forgotten about the rather unintuitive automagic dirty checking and subsequent saving. In my rather humble opinion, it's a feature that should be disabled by default, but that's not the point here. I had been made aware of the feature in the past, but had somehow completely forgotten about it. Fine, no worries, I can live with it, I'll just roll back my transaction.
However! My test still shouldn't have failed, or so I thought. After all, I had Spring transaction support set up for all my service calls, and surely an exception will cause the transaction to roll back? Wrong. By default, transactions are only rolled back for Unchecked exceptions, not for checked exceptions. I can't for the life of me fathom what the reasoning behind this decision might be, but there you have it. It's well document in the Spring transaction documentation, but again I had completely forgotten about it.
A simple bit of config fixed the problem:
<tx:method name="*" rollback-for="java.lang.Throwable"/>
So please, don't be like me. Don't get caught out by these features! Unless you're looking for a couple of hours of entertainment, that is 
.
Patience, Questions & Talent
Over the years, I've come to notice a pattern. For reasons I can't explain, a lot of people come to me with their problems. Whether it's a coding problem, a boyfriend problem or just a big rant after a bad day, I've heard it all. When someone comes to me with a problem, I'm all ears and I do my best to help out. Nothing special about that, that's just part of being human.
When it comes to coding, some people keep coming back with more questions. I'm sure you've all experienced the same thing. They start off with really broad and general things like "Can you show me how to make a website" or "Can you help me with my Java homework?". After a while, they move on to more specific questions, along the lines of "Why doesn't this bit of CSS work in browser X?" or "What does this stacktrace mean?".
Some people stop asking questions after a while, because they've reached a level that's sufficient for their needs or because they lose interest. The people who ask the most questions — and don't stop asking, are in my opinion the most interesting ones. They inevitably surpass me in everything they do and eventually the roles become reversed.
Talent is cultivated and requires patience. So when someone comes to you with a question, I suggest you keep an open mind and exercise patience, even if your first thought is "OMFG RTFM n00b!". You never know when you might turn to them with your questions!
Howto: soapUI integration tests with Maven
Running soapUI tests with maven is surprisingly easy, all it requires is a few simple steps. This howto will walk you through deploying your web project in an embedded container and running the soapUI tests in the integration test phase.
Cargo configuration
With the cargo plugin you can deploy your project to just about any container. For the sake of simplicity I'll be using an embedded Jetty 6 container.
<!-- Deploy the project WAR to a built-in container during the integration test phase -->
<build>
[...]
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<executions>
<!--Start the container in the pre-integration-test phase -->
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<!-- Stop the container after integration tests are done -->
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
<configuration>
<wait>false</wait> <!-- We want to deploy, run tests and exit, not wait -->
<container>
<containerId>jetty6x</containerId>
<type>embedded</type>
</container>
<configuration>
<properties>
<cargo.servlet.port>${my.project.port}</cargo.servlet.port>
</properties>
</configuration>
</configuration>
</plugin>
[...]
</build>
soapUI project configuration
If you haven't already created a SOAP UI test suite, now's the time to do so. Once this is done, copy the test suite to your test resources folder (src/test/resources). Set up your project to filter resources.
<build> [...] <testResources> <testResource> <filtering>true</filtering> <directory>src/test/resources</directory> </testResource> </testResources> [...] </build>
With that out of the way, you can now edit the soapUI project file with your favourite XML editor. What you want to do is replace all endpoint references (and possibly WSDL locations) by property keys. So <con:endpoint>http://localhost:8080/MyProject/endpoint</con:endpoint> becomes <con:endpoint>${my.project.endpoint}</con:endpoint>.
Your webapp will be deployed to http://localhost:${my.project.port}/${project.artifactId}-${project.version}, so I suggest using that as a property value.
<project | profile>
[...]
<properties>
<my.project.port>8888</my.project.port>
<my.project.endpoint>http://localhost:${my.project.port}/MyProject/endpoint</my.project.endpoint>
</properties>
[...]
</project | profile>
soapUI plugin configuration
First, add the eviware soapUI maven repository to your list of repositories.
<pluginRepositories> <pluginRepository> <id>eviwarePluginRepository</id> <url>http://www.eviware.com/repository/maven2/</url> </pluginRepository> </pluginRepositories>
Then, add the plugin to your build and let maven know when you want to execute it. Considering the container is starting up before the integration test phase, and is shutting down afterwards, running the tests as integration tests seems like the best option 
.
<!-- Run SOAP UI tests during the integration phase. --> <plugin> <groupId>eviware</groupId> <artifactId>maven-soapui-plugin</artifactId> <version>2.5.1</version> <configuration> <junitReport>yes</junitReport> <exportAll>yes</exportAll> <projectFile>target/test-classes/soapui-project.xml</projectFile> <outputFolder>target/soapui-reports</outputFolder> </configuration> <executions> <execution> <id>wsn-server-test</id> <phase>integration-test</phase> <goals> <goal>test</goal> </goals> </execution> </executions> </plugin>
All done!
Now when you run maven verify (or install, or ..) your SOAP UI tests will automagically be executed and you'll be informed of any failures.
Bored Java Dev looking for Open Source project
I've got a bit too much spare time on my hands and I'm having a hard time finding an interesting open source java project. My definition of interesting is pretty broad, but it generally includes "useful".
If you want my assistance, just give me a shout!
FOSDEM 2010
Another FOSDEM has come and gone. I was present and accounted for as per usual. Like most years, I mostly perused an interesting mix of lightning talks and the hallway track. Somehow I managed to miss quite a few of the talks I wanted to see, but I can't say I mind. They'll be online before long and I enjoyed a bit of geeky socialising anyway.
The organisation was excellent as per usual. The beer event went off without a glitch, in spite of a couple of knobs (yes, knobs) wanting to boycott Google's sponsoring of free beer. I have no love for Google, but I do love free beer. If you're unfortunate enough to end up between me and said beer, well, I hear some religions offer an afterlife .
The talks were pretty good, even the keynotes were interesting the year. It's pretty hard to cater for such a big audience, but I think that it was mostly a success! And speaking of catering, the double-capacity chips-shop helped a lot. Although in what's becoming a tradition of sorts, I enjoyed a bit of Thai food just down the road from ULB. Much better than chips thankyouverymuch! And while I'm being positive, my biggest gripe of FOSDEMs past -- the toilets -- has been addressed as well. This year, they didn't resemble the cloaca maxima the way they used to. Not quite minty fresh either, but more than acceptable .
I am however a bit disappointed in one aspect. I was hoping to come home with an interesting project to work on, but it didn't happen. A couple of irssi devs pointed out that I should probably start spending a bit more time on IRC again. They're probably right.
The Real World sucks
Being of a reasonably calm disposition, I rarely reach boiling point, but there are a couple of things that really do grind my gears. Inefficiency is one of them, but let's not go there right now. What's really grinding my gears right now, is how much the so-called Real World (as opposed to the academic world) sucks.
Every once in a while, I will stumble upon a piece of code that I really wish wasn't there. It's the kind of code that screams "please refactor me!". It's the exploding septic tank of code smells. When I look at it, the words "well that's going to come back to bite us in the arse" pop into my head. In an ideal world, I'd be able to just sit down for a day and refactor the damned thing. This Real World thing, unfortunately, has something that's called management. Or was it manglement? They're part of Layer 8 either way. That's right, the political layer.
These politics seem to revolve solely around short term benefits. And so refactoring a piece of code that could cause problems eventually in such-and-such a situation isn't deemed important. This is fair enough in some cases, but sometimes you really do know that this decision will come back to haunt you. Sometimes I wonder whether managers really don't care about long-term implications, or whether they like having a couple of big bugs lurking in the code in the hope that some of these will be discovered much later so that we can get paid to fix them. Must be my cynical mind talking.
Is there a good way of dealing with this sort of nonsense? It's always possible to pull overtime and refactor the code then, but what if you introduce a bug? Good luck explaining a bug in new-and-improved code that you weren't supposed to write in the first place.
Yup, the Real World sucks. But if anyone has a way of making it better, I'd be glad to hear it!
Maven sucks?
Kent Spillner certainly seems to think so. I disagree with the conclusion, but I find myself agreeing with a lot of the points he makes. It's true that maven builds aren't always consistent across different platforms or even maven versions. It's also true that your pom.xml file can grow rather large and complicated if you want to get maven to do interesting things. And it's definitely very true that maven dependency management can be hair-pullingly-complicated and is essentially broken. Sure.
But saying that writing your own build manager is better? Advocating ant and rake? Seriously? Maven does a lot more than just build your project. It does reporting, site generation, eclipse project generation and pretty much anything else you can think of. The convenience of the thing is worth a lot. It's definitely worth having to struggle with the POM every once in a while. And to be honest, the POM syntax isn't much more horrible than ant's or rake's.
As for platform/version inconsistencies: if you can't force the people on your team to use the same software, then your problems probably run a lot deeper than just build management. Software has bugs, this includes maven as well. If you've hit a particular bug that causes your build to go kaboom, then fixing it sounds like the way to go.
If you have the time to write a build manager for every project you work on, be my guest. I for one don't, and maven has actually served me pretty well so far.
Iaido Explained, part 1: Metsuke
Iaido isn't exactly your average hobby. Most of my friends don't know anything about it other than the fact that it's got something to do with swords. The usual reaction is "Sweeeeet!". That's usually about as far as the interaction goes. If I played football, golf or tennis I'm sure people would come up with all sorts of interesting jargon-riddled chit-chat. Most people know, to some extent, what "off-side", "handicap" or "back-hand" mean. Well, martial arts too come with their own jargon. I'll try to explain a key term/concept on something of a regular basis.
Metsuke, or 目突, is an essential concept of many martial arts. It's not to be confused with 目付. That particular kind of Metsuke refers to some kind of government official back in the Tokugawa era. The one I'm referring to translates roughly as "eye thrust", and as such it refers to making eye contact and making sure your gaze is locked onto your target. This is not as easy as it sounds. When you're pairing up with someone, it's easy enough to keep an eye on them. When you're doing solo kata however – which is most of the time in iaido – things get a bit more complicated. Looking at something that isn't there isn't easy. Looking at a moving target that isn't there is down right hard. The distance has to be right, the timing has to be right. If you look to the left while cutting to the right, something is definitely wrong. These kinds of mistakes aren't as obvious as making a wrong step or cutting the wrong way, but they're still mistakes. Knowing where your enemy is and what you're doing to him is at least as important as being able to make nice cuts.
It's said that advanced iaidoka can not only visualise their own imaginary opponent, but also those of their students. Who knows, maybe one day...
Regensburg seminar with Esaka-sensei
I recently spent four days in the rather picturesque Regensburg, Bavaria, Germany. Not as a tourist or anything work related, thankfully. The only thing on my mind during those four days was iaido. Four days of training under the all-seeing eye of Esaka-sensei and some of his senior students.
My group (Ikkyu up to Nidan) was placed in the very capable hands of a man whose name I never quite got, although Niishima-sensei seems to come to mind. Not sure how old he is, and it would of course be rude to speculate, but let's just say that if I ever live to be his age I hope to be half as fit as him! He took a while to warm up (literally, quite likely, 't was chilly), but once he reached boiling point there was no stopping him. He corrected me several times, mostly on relatively minor points, but those corrections alone made the seminar worth the trip. When Esaka-sensei corrected my footwork, I could almost forget about the ridiculously overpriced hotel with crappy beds.
Doing nothing but iai for four days in a row is a great way to improve. I didn't learn anything I wasn't already supposed to know, but the sheer number of repetitions combined with viewing things in a different light made my iai progress rather nicely. Definitely worth the trip!
Some interesting things I learnt:
- The Japanese find it quite puzzling that we Westerners have such long femurs. For some people this means that the "Tsuka one fist from the Hara, Tsuba by the knee"-adage is simply impossible.
I had the Metsuke and footwork in Ukenagashi completely wrong. Now that I've got it right, the rest of the Kata feels much more natural. - Esaka-sensei may be old, but he can draw his sword in the blink of an eye without seemingly moving a muscle. Practice makes perfect, I suppose!
For some reason I've still not received any pictures from the seminar. A lot of people took a lot of pictures and I'd expected to find some of them online by now. No such luck, however. If and when they do appear on the interwebs, I'll be sure to upload some of the more flattering ones. Mental note: bring a camera next time.