Skip to content

Tag: spring

DbUnit

I’ve decided to revisit the JUnit testing Hibernate and Spring recipe that I posted a while back. A problem with the previous recipe is that it did not provide any means to initialize the test database. This wasn’t too much of a problem as I was mostly testing the data insert operations of the DAOs. I then used the same DAO to retrieve the newly inserted data and tested what came back. However this is no good if I don’t want insert operations on my DAO (if it’s to retrieve read only data from the database) or if I want to test the retrieval operations independently of the insert operations.

This post extends the recipe to include a means of initialising the database using DbUnit.

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.

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?

name
address
EMail

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