So if you go back to the early days of J2EE, you'll notice that it was very EJB-centric - for the most part, J2EE containers were EJB containers with some extra stuff to support EJB. EJB, for the most part, was pre-ORM ORM back when object-relational mapping was a relatively new concept. There was more to it than that, of course, but using Entity EJBs for object-relational mapping was the core of what J2EE was all about.
The problem was, it was a massive unusable beast of a mess. Rod Johnson came along, found some ways to simplify the concept into a "lightweight" container and called it "Spring" as an alternative to the heavyweight EJB containers of the late 90's.
The thing that everybody seems to be missing is that the only reason you needed the container in the first place was to support the Entity EJB's that were more trouble than they were worth. Standalone ORM tools like Hibernate solve the actual entity-relational mapping problem far less intrusively than J2EE or Spring ever did (Hibernate is still more trouble than it's worth but at least you can understand why it's there).
Spring doesn't actually do anything except make other things available in Spring, and it actually damages your codebase by forcing you to make most of your variables effectively global (which Spring calls singleton beans).
The problem was, it was a massive unusable beast of a mess. Rod Johnson came along, found some ways to simplify the concept into a "lightweight" container and called it "Spring" as an alternative to the heavyweight EJB containers of the late 90's.
The thing that everybody seems to be missing is that the only reason you needed the container in the first place was to support the Entity EJB's that were more trouble than they were worth. Standalone ORM tools like Hibernate solve the actual entity-relational mapping problem far less intrusively than J2EE or Spring ever did (Hibernate is still more trouble than it's worth but at least you can understand why it's there).
Spring doesn't actually do anything except make other things available in Spring, and it actually damages your codebase by forcing you to make most of your variables effectively global (which Spring calls singleton beans).