It was fun meeting Wendy Devolder (now CEO of SkillsMatter) formerly from Valtech (I worked with her at Valtech London back in 2001-2002) and Michael Isvy (with SpringSource) also ex-former. Also had nice chats with Guillaume Laforge, Alexis Moussine-Pouchkine, Antonio Goncalvez and many others, including 2 more Valtech alumni.

Aside from the presenters, most of the participants seemed to be tech guys working for blue chips.

Overview of the presentations

Michael Isvy from SpringSource did a valuable demonstration of DM Server. I find it surprising that it bets on OSGi (I cannot get myself to like it). But it seems mostly to become a good server, further strengthened by the recent addition of Groovy to their portfolio (post in French).

Spring DM Server seems to be mainly Tomcat + Spring Framework + OSGi. Supposed to be 100% OSS, but it is not easy to guess when looking at their website…

Tugdual Grall did an entertaining presentation of eXo Platform. The WebOS part is impressive (but run from the local machine, so presumably much slower when used over the net). But I can’t imagine it winning most hearts. My money is currently on using separate apps such as Google Docs.

Guillaume Laforge, formely from G2One and now with SpringSource, did his classic Groovy/Grails presentation. Not much to add to what he has said at Paris JUG in September.

Oh yes, one thing: he hopes that Groovy will be used to script deployment under Spring DM Server. I totally agree.

Antonio Goncalvez presented JEE6, due for release in 2009 Q2. My feeling is that it is just getting too complex, in the sense that it is getting impossible to know about all its various standards and API (reminding me of the whole SOAP fiasco). The JEE6 team knows about this and has a plan where only subsets would be used. As for me, I think most developers will just stick with Spring or some other simpler options (though I guess Spring is getting less and less simple…).

Another thing: it seems EclipseLink is used as the reference implementation for JPA by GlassFish. EclipseLink is in fact TopLink, only Open Source. Interesting comeback, for a tool considered as dead after the Hibernate landslide.

Alexis Moussine-Pouchkine talked about GlassFish as a full-fledged JEE Server, open source, much faster and still as powerful than Weblogic and WebSphere. Strangely, few references to JBoss, except to mention that it (GlassFish) seems to have more downloads.

Christophe Laprun from JBoss had a session on JBoss Portal. I didn’t follow all of it (did work for Valtech instead). Portals and portlets are not that interesting to me. I’m glad other people work on them.

Hughes le Bars & Oktay Istanbullu from Yahoo! presented Hadoop, a solution to do grid computing for storage of very large data sets (in the order of PetaBytes). I couldn’t quite understand all the presentation, but the whole thing seems terribly interesting. It is used for web search and ads matching by Yahoo!

Oh, Hughes also mentioned PIG, apparently an equivalent of SQL, just better (!).

Drinks were paid after the conference, and a good time was had by all.

Check out my pictures of the conference on flickr.

A list usually looks like this in a Spring configuration file:

<bean id="aList" class="org.springframework.beans.factory.config.ListFactoryBean">
<property name="sourceList">
<list>
<value>a list element</value>
<value>another list element</value>
</list>
</property>
</bean>

Or, if you are the fun-loving type, you can write this as follows:

<util:list id="someList">
<value>a list element</value>
<value>another list element</value>
</util:list>

…as long as you provide the appropriate schema with xmlns:util="http://www.springframework.org/schema/util", as described in the Spring documentation.

What you cannot do, however, is merge two lists. You add can a list bean to your list, but it will only be considered as a separate item; it won’t be merged.

A solution is to provide a new Spring bean that supports lists.


package com.company.utils.spring;
import java.util.*;
import org.springframework.beans.factory.config.ListFactoryBean;
public class ListMergerFactory extends ListFactoryBean {
private final List listOfLists;
public ListMergerFactory(List listOfLists) throws Exception {
this.listOfLists = listOfLists;
setSourceList(new ArrayList());
}
protected Object createInstance() {
List listOrigin = (List) super.createInstance();
for (Iterator iter = listOfLists.iterator(); iter.hasNext();) {
List element = (List) iter.next();
listOrigin.addAll(element);
}
return listOrigin;
}
}

This will let you define a list as follows (I don’t have the source for this part anymore, so some details may be wrong):

<bean id="aList" class="com.company.utils.spring.ListMergerFactory">
<constructor-arg value="myOtherList"/>
<property name="sourceList">
<list>
<value>a list element</value>
<value>another list element</value>
</list>
</property>
</bean>

The downside is that you cannot use the util:list shortcut for defining a list that is made of another list.

I just heard today about Unitils, a more ambitious tool. In addition to Spring, it supports TestNG, DbUnit, EasyMock, and Hibernate (ie. almost all that we are using here!). It also provides a number of additional services, such as helper asserts.

Especially intriguing are two things:

• they recommend temporarily removing some db constraints, and provide help to do so (“To keep database tests maintainable, test data files have to be as small as possible. (Referential) constraints however don’t help you to achieve this. We advise to disable all foreign key and not null constraints. Doing so makes it possible to specify only the data that matters for your test.“)
• they handle database versions is a way very similar to Ruby on Rails (“The database maintainer monitors a directory on the filesystem that contains DDL scripts for creating the structure of the database. The name of these scripts should comply with following naming convention: <version>_<some name>.sql. For example: 001_create_person_table.sql, 002_create_car_table.sql“)

See here for details.

This is an excerpt from file xfire-spring-1.2.5.pom:

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-mock</artifactId>
<version>1.2.6</version>
<scope>test</scope>
</dependency>
...
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</dependency>

This last bit is especially deceitful, as it refers to a ‘spring’ module… that only exists in Spring 1.x, not in Spring 2.x.

Suppose that you have your own POM where both Spring 2.x and XFire are configured:

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>2.0.2</version>
</dependency>
...
<dependency>
<groupId>org.codehaus.xfire</groupId>
<artifactId>xfire-spring</artifactId>
<version>1.2.5</version>
</dependency>

Apparently, because of the configuration of xfire-spring, when running mvn compile, the classpath uses modules from Spring 1.x, although as runtime, modules from Spring 2.x are correctly used.

As long as you are using methods available both in Spring 1.x and Spring 2.x, this won’t really be a problem. This is in fact often the case, which might explain why I never found any reference to this problem on the web

But if you are, like me, using methods only in Spring 2., you’ll get a compilation error.

The fix is to direct Maven to explicitly exclude Spring 1.x:


<dependency>
<groupId>org.codehaus.xfire</groupId>
<artifactId>xfire-spring</artifactId>
<version>1.2.5</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</exclusion>
</exclusions>
</dependency>

Update (25/04/07): another thing seems necessary to get this to work.

The example provided with the XFire distribution has a service.xml file that looks like this:

<beans xmlns="http://xfire.codehaus.org/config/1.0">
<service>
<name>LotDonneesService</name>
...

In practice, it seems to work with Spring 1.x but not with Spring 2.x. The correct syntax is:

<beans>
<service xmlns="http://xfire.codehaus.org/config/1.0">
<name>LotDonneesService</name>
...

This issue is, in fact, described in the official documentation for XFire.

The first approach is by requesting the bean from Spring before the tests are being executed:

public class MyDaoImplTest {
	@BeforeClass
	public static void setup() {
		myDao = (MyDaoImpl) TestSpringUtil.getFactory().getBean("myDao");
	}
}

Notice that you need a specific SpringUtil class if you want (like me) to have a slightly different configuration for your beans under test. In my case, I needed them to point to a test database instance, not to the production instance.
The code was for JUnit 4, of course, but that’s extremely similar in JUnit 3.x:

public class MyDaoImplTest extends TestCase {
	public void setUp() {
		myDao = (MyDaoImpl) TestSpringUtil.getFactory().getBean("myDao");
	}
}

(written from the top of my head)

If you do not want to get the bean manually from Spring, one option is to declare your tests in your Spring configuration. Quite ugly of course: I do not want to burden my configuration with tests (though that can be mitigated by having a separate, additional Spring configuration for test classes).

An alternative is to use the class AbstractDependencyInjectionSpringContextTests (cute name) from Spring. That will allow you declare your dependencies in your test classes and wait for Spring to populate them.

public class MyDaoImplTest extends
        AbstractDependencyInjectionSpringContextTests {

	private MyDaoImpl myDao;

	public void setMyDao(MyDaoImpl myDao) {
		this.myDao = myDao;
	}

	// specifies the Spring configuration to load for this fixture
	protected String[] getConfigLocations() {
		// applicationContext-dbaccess-test.xml is the place where access to my test db
		// is defined and overrides access defined in applicationContext.xml
		return new String[] {
		        "classpath:com/company/application/applicationContext-dbaccess-test.xml",
		        "classpath:com/company/application/applicationContext.xml" };
	}
}

The drawback, though, is that you are stuck with JUnit 3.x. The Spring team has not ported their class to JUnit 4.x yet.

Enter Gienah Testing.

Gienah is a very simple tool that let you weave declaratively your test classes with their dependencies:

@RunWith(value = SpringRunner.class)
@Configuration(locations = {
        "classpath:com/company/application/applicationContext-dbaccess-test.xml",
        "classpath:com/company/application/applicationContext.xml" })
public class MyDaoImplTest {

	@Dependency
	private MyDaoImpl myDao;

}

That’s it! Clean and easy.

Gienah is still in version E0.3, but seems already very useful. Check out their 5 mins tutorial, it’s well worth it.

A last word: Gienah can handle transactional contexts as well, so that you can test your collections in your unit tests, even if they are lazy loaded. Just add the @Transactional annotation:

	@Test
	@Transactional
	public void testListEmpty() {
		assertEquals(0, myDao().getAnObject().getDependentObjectList().size());
	}

However, a limitation on that is the name of the transaction manager in your Spring configuration must be exactly “transactionManager”, not “txManager” or anything else. I couldn’t find a way to specify it. This is unfortunate as Spring claims to find the transaction manager whatever its name is. See Testing – Transaction Management:

AbstractTransactionalSpringContextTests depends on a PlatformTransactionManager bean being defined in the application context. The name doesn’t matter, due to the use of autowire by type.