Need feedback: Working on a JBoss Spring Deployer

[Stefan Arentz]

Howdy.

I'm working on an extension for JBoss (4.x) that allows you to easily package and deploy Spring applications. This is mostly for a specific use case of our own but since we are committed to share code like this I would like to ask a bigger audience for feedback.

The basic idea is that you can package a Spring application in a .spr file. This file is a simple jar file and has the following layout:

my-app-1.0.spr/
my-app-1.0.spr/META-INF/spring-config.xml
my-app-1.0.spr/foo.jar
my-app-1.0.spr/foo.xml
my-app-1.0.spr/bar.jar
my-app-1.0.spr/bar.properties
my-app-1.0.spr/spring-core-2.0.jar
my-app-1.0.spr/commons-logging-1.0.4.jar

The META-INF/spring-config.xml describes how to deploy this application and the other files are simply code and resources. As an example, the spring-config.xml can look like this:

<spring-config>
  <config-locations>
    <config-location>com/test/foo/FooService.xml</config-location>
    <config-location>com/test/bar/BarService.xml</config-location>
  </config-locations>
</spring-config>

This tells the deployer that it should first create an ApplicationContext that is describes in those two bean definitions.

The spring-config.xml is optional. If you don't supply one then the deployer will look for **/*-spring.xml files in the jar files contained in the .spr archive.

The deployer does not contain the Spring jars. You will have to include these in your .spr project. This is done to make it easier to run applications that use different Spring versions together in one JBoss instance without having to deal with classloader issues that arise when using multiple versions of the same class.

Couple of notes:

I'm not sure if not including Spring in the deployer is a good idea. Another option would be to include 1.2.x and 2.x in the deployer and have a <version> element in the spring-config.xml to say which version needs to be added to the deployed app's classpath. Another option is to simply say, the deployer supplies Spring 2.0 and that is what all apps will use. That would work for me actually.

A simple Maven 2.0 plugin is also underway to make it easy to build .spr archives.

What do you think? Useful? Do you miss features?

S.

[gmatthews]

Have you ruled out that there isn't a way to kick start a .sar?

Seems like reusing the existing .sar deployer might be simpler if there was a way to load the application context.

I've just been deploying as a .war, which is more portable than the proposed .spr. I'm not sure what a .spr would buy you beyond what you can already do with a .war.