I do not have any thing against Spring. I agree it has some demerits against containers like Spring but makes your code and configuration portable across any Java EE container. Spring configuration being proprietary is not portable and you have to stick with Spring.
Uhm. My application runs well on Tomcat, WebSphere and WebLogic, and the only configuration files I have to change when I put it on one server or the other are specific to the implementation of the particular "standard" server: my Spring configuration remains untouched, and Spring actively shields me from part of those platform-specific configuration changes. So, what is the point of talking about the "platform dependence" of a Spring configuration? I use oscache as my caching solution, and so I do rely on a oscache.properties file: this does not make my app less portable. Portability is about different things: portability is about being able to run an APP on different platforms, it is not about being able to switch libraries at any time. Now that you've "standardized hibernate" I will be able to run EJB 3.0 persistence apps by switching the persistence provider when I do change my application server: is this "more portable" than what I can have now by moving my hibernate-based application on different application servers? I strongly doubt so: especially in the first months after the implementations will have come out there will surely be a number of subtle incompatibilities, not to mention the implementation-specific features that will probably be needed to manage more complex cases. I do absolutely agree that something standard like EJB3 persistence was needed, but "portability" is not a good argument for those kinds of standardizations, and the fact that the Spring team, their achievements and their lesson have been ignored in this iteration of JEE is frankly disappointing. I will probably stick with Spring, while doing JEE 5: as you say it's a framework to be used with a JEE container.