Running CDI Source on JBoss AS 6

For those unaware, last month an initiative called CDI Source was announced by Rick Hightower. It looks like their goals are pretty similar to Seam, a tool I've been using for a few years now; and most recently started actually contributing to!

I was curious yesterday (mostly because it was pouring here all day) to see what had come of it, and happened to notice they were first tackling CDI & Spring interoperability. Not a bad move I thought, Spring already has all of the add-ons you would be looking for (arguably too many), so being able to bring that in to a CDI enabled application makes a lot of sense. I would still argue that Spring really needs to be able to delegate down to an underlying CDI implementation in these cases, mostly for performance reasons.

I decided to clone their repositories. They have two currently, one is their underlying beancontainer and another for examples (they also host a resin plugin for maven, but out of scope..). When I cloned and started digging in to it, I found some things that were cool (tests worked out of the box) and some things I didn't like (platform dependence). I built the main project, no issue. I built the example spring app, had an issue there - tests didn't run. So I rebuilt without tests, generated a WAR file. I then tried to deploy it to JBoss AS 6. No luck, talk about nearly killing a VM. I deployed to a stopped JBoss instance, and attempted to start up, received a lot of classloader based errors (missing XAManager, base classloader setup wrong, etc). Never fun, though reminded me of the issues I have in Seam JMS :-)

When I dug into the code, I found a few problems. The biggest I saw was due to all of the extra dependencies that Spring pulls in, deployment to a full application server (as it always used to be) was going to be a challenge. I tried marking dependencies as provided, but no luck. Still were being pulled in for some reason. So I decided to pull out the pre-maven rule book and ripping out libraries under WEB-INF/lib. I was able to string the list down to these:

• aopalliance-1.0.jar
• aspectjrt-1.6.11.M2.jar
• aspectjweaver-1.6.11.M2.jar
• beancontainer-api-1.0-SNAPSHOT.jar
• commons-beanutils-1.8.0.jar
• commons-collections-3.1.jar
• commons-dbcp-1.3.jar
• commons-digester-2.0.jar
• commons-fileupload-1.2.1.jar
• commons-pool-1.5.4.jar
• dom4j-1.6.1.jar
• flexjson-2.1.jar
• jcl-over-slf4j-1.6.1.jar
• joda-time-1.6.jar
• slf4j-api-1.6.1.jar
• slf4j-log4j12-1.6.1.jar
• spring-aop-3.0.5.RELEASE.jar
• spring-asm-3.0.5.RELEASE.jar
• spring-aspects-3.0.5.RELEASE.jar
• spring-beans-3.0.5.RELEASE.jar
• springbridge-1.0-SNAPSHOT.jar
• spring-context-3.0.5.RELEASE.jar
• spring-context-support-3.0.5.RELEASE.jar
• spring-core-3.0.5.RELEASE.jar
• spring-expression-3.0.5.RELEASE.jar
• spring-jdbc-3.0.5.RELEASE.jar
• spring-js-resources-2.2.1.RELEASE.jar
• spring-orm-3.0.5.RELEASE.jar
• spring-tx-3.0.5.RELEASE.jar
• spring-web-3.0.5.RELEASE.jar
• spring-webmvc-3.0.5.RELEASE.jar
• tiles-api-2.2.1.jar
• tiles-core-2.2.1.jar
• tiles-jsp-2.2.1.jar
• tiles-servlet-2.2.1.jar
• tiles-template-2.2.1.jar

Yep, had to shrink it down to 36 libraries. Still a lot of libraries in place. Attempting to deploy this resulted in some Weld errors, resolving around injection targets. I figured they were incorrectly creating injection targets in the code, and confirmed that in their SpringIntegrationExtention class, they were making beans that were also injection targets, for some reason. When I removed this code, the application deployed fine. I still can't run the application correctly due to a tiles error (see here) but at least it deploys fine now.

As of this morning, I saw that Rick had also been working on it, and made essentially the same change I did to the code to make it work with Weld.