The problematic situation occurs when a Spring-based application is running within JBoss AS v7, where JBoss has changed the shutdown sequence which renders certain cleanup procedures (bound to the destruction phase of Spring's application context) invalid.
More specifically, the ability to access JMS resources after shutdown has been initiated (same applies to the JDBC resources) has been compromised. By checking the logs you can spot that both JDBC datasources as well as JMS destinations, are both being unbound from JNDI before the web application context destruction is initiated.
A simple way to replicate this issue is to deploy an application with DataSourceInitializer and its databaseCleaner property configured. Then, when the AS is being shutdown the "ResourceException: IJ000451: The connection manager is shutdown" is raised and DB cleanup will not be executed.
Obviously this is not a Spring Framework issue and all the blame goes to the JBoss AS. However, I would like to verify this and check there is no known workaround on Spring side, which can be deployed to avoid this?
I agree that this isn't a Spring issue, but it's also not a JBoss issue - it's an application one. Using <resource-ref> isn't a workaround or a trick, it's simply the way you are supposed to do it (ideally using java:comp/env/... to look them up too).
Declaring resources in your web.xml tells the container you need them, so it makes them available and ensure they work for the duration of your application's lifecycle. If you do not declare them, then they may also not be available during initialisation (as well as destroyed before shutdown). JBoss certainly isn't the only EE container where this can happen, it just may occur more often on JBoss because it aggressively does work in parallel.
[disclaimer: since I wrote that comment I actually joined Pivotal and the Spring framework team]
Thanks for the reply James. I would tend to agree if the services we are talking about weren't core services provided by the container (and the spec). Why would you want to stop something like the JMS broker while the deployed (external) applications have not been shutdown yet? As you said, for optimizations. But can't you guys look at the current usage of the broker and postpone shutdown when you still have registered sessions? Just a thought. Thanks.
JBoss does ensure it stays alive if it knows of any references in the application, such as <resource-ref> entries, @Resource/@EJB/@Inject annotations and so on. The problem only really occurs for things where an application (or library like Spring) code does a programmatic JNDI lookup, since the container can't know for sure when it is not longer needed.
Trying to guess tends to end badly, and doesn't entirely solve the problem. For example if an app is otherwise idle but needs a new JDBC connection during shutdown, then it would still fail. Real applications tend to do things like store references to services in static variables, and we don't want to break them or hang during shutdown either.
If there is a clear split between "container services" which provide things and application which consume them, then a two-phase shutdown can work well - shut down the apps, then shut down the services. It doesn't work for more complex situations when applications provide services as well (EJBs, declarations of queues/topics/datasources), and container services can require other components before they are available.