We spent some time integrating Spring and JBoss, primarily focused on the testing and batch processing side of our application. Recently we ran into a difficult problem space in our "runtime" environment :

Our application follows a blackboard type architecture where we have several independent modules (packaged as standard ear files) publishing data to common, shared location. The contribution from each module contributes to the overall solution. This architecture works well, however we ran into a situation whereby we required multiple instance of the application to run, but the behavior of each instance differs.

Each instance required a different combination of the independent modules, and a module may be used across many instances. This posed a problem since each module needed a different configuration depending on the instance it was deployed to (I hope this is making sense). Some of the modules used standard factory type patterns where applicable (which ties you in programmatically to a specific configuration), others had pluggable components which where programmatically set up.

To solve this problem we decided that each jboss instance would have it's own spring configuration (ie every module deployed to a jboss instance would use the same spring configuration), and within the spring configuration you can specify what components each module must use and how to configure their behaviour. This gave us the ability to unobtrusively configure each module to a fine granuality while reusing all the generic module code.

Using a template spring configuration, our build process would determine what instance we are deploying to and setup the spring template accordingly. This made the springification transparent and easy to work with - factories would load their components from the spring configuration and the pluggable components would load their required behavior.

This is just another application of integrating spring into a jboss application.