First of all, you're not really using dependency injection there. DI means that the bean is injected *external* to the class. In your example the action is still managing the instantiation, the only difference being that the implementation is decided in an external configuration file. This is the weakest form of "DI" possible, if it would even be called that.
Consider this instead:
The PersonManager implementation is still defined in a Spring config, as before. Here's the difference: now you can instantiate TheAction and set its PersonManager implementation in arbitrary code--like a
unit test, or on action instantiation (like if you're using the S2 Spring plugin).
With the implementation decided by external means we can now play a lot of games with both the action and the PersonManager implementation. We could, for example, have a PersonManager implementation that always throws a specific exception. Or disallows login, or whatever--thus giving us the ability to create unit tests for any aspect of system functionality.
There are a million web references for IoC/DI--it's usually a situation where until you use it and understand why it useful you won't "get it", like Lisp macros. It's easier to understand by utilization. The first step is to understand what it actually *is*; hopefully the simplistic example above has at least cleared up your initial misconceptions.