Update 2021: It's been 10 years since I answered the original question, and I'm still getting the occasional upvote. Can I just ask future readers to take my response as what it is: A reflection of the Java Enterprise landscape in 2011.

CDI stands for "context and dependency injection", while Spring is a complete ecosystem around a dependency injection container. To compare both, you have to differentiate the comparison.

Dependency injection is handled by both containers. The main difference is the fact that CDI handles DI in a dynamic (aka: stateful) way - this means that dependencies are resolved at execution time. Spring's approach is static - this means that components are wired together at creation time. While the CDI-way might seem a bit unusual at a first glimpse, it's far superior and offers way more and advanced options (I'm writing this with the background of two productive CDI apps).

If you look at the ecosystem, the situation is different: Spring comes bundled with a lot of jars (>150), while CDI is pretty small by itself. A typical CDI-usage would be inside of a Java EE 6 application server, but you can easily make it work in a servlet engine or even Java SE. This means that using CDI makes no assumption about using Hibernate, JPA, EJB or whatever - that's up to you.

If you need more functionality, CDI comes with the concept of portable extensions (which by itself makes the API worthwile). Independent extension modules like Apache CODI and Seam 3 exist and cover topics like security, mailing, reporting and more.

To summarize: CDI is nothing like a "replacement" for the Spring ecosystem, it's rather an improvement over Spring's dependency injection mechanism. It's part of Java EE 6, so if you are on a GlasFish with Java EE 6, you should definitely go for CDI. In my eyes your question is rather: Can I replace Spring with Java EE 6? I guess my answer is pretty obvious ;-)