I get asked over and over again about my opinion about Spring "vs." Java EE. There is no "vs." rather than "xor". Java EE 6 is similar to Spring. Java EE 6 comes even with the JSR-330 - a Dependency Injection specification led by Rod Johnson. The main difference between Java EE and Spring is the "philosophy" behind. Java EE 6 does follow the "Convention over Configuration" or "Configuration by Exception" idea - what appears for Spring guys as Voodoo (had a long on-stage conversation with Juergen Hoeller just about that) e.g. EJB 3.1 are "just" transactional without any further ceremony. Spring on the other hand relies on explicit configuration. "Convention Over Configuration" vs. explicit configuration, however, never decided in my projects, which platform to use.
The "support" or "maintenance" policy question made the decision in last few years. It seems like developers and managers don't even know, that Spring comes with well defined SpringSource Enterprise Maintenance Policy. You will have either to upgrade to the current version of Spring (read the policy for more details), or buy a support contract. Both are valid approaches - your sponsor / manager / client just have to know about that.
There are similar policies for Java EE servers as well - so your management will have to decide which contracts to buy - or whether to go with unsupported system into production. Regardless how well it may or would work, this is not a development, rather than "political" / "strategic" decision. Given that both platforms are rather similar it is just crazy to buy both contracts.
If you go with Spring - I would use the supported tc Server: Lightweight Application Server for Cloud and Virtual Environments. It comes with nice out-of-the-box experience and professional support from single vendor.
I would always prefer the tc Server, over "custom" Tomcat+Spring configurations...
Classic Java EE 7 Workshops: Bootstrap, Effective and Architectures, July, 13th-15th
Online workshop: Java EE 7 Bootstrap