Spring

Programmers are linguists. We make up words, assemble grammars, and use them to express concepts both abstract and concrete.

From procedural, to object oriented, and to the newer linguistics of aspect oriented programming, the way we think about coding is eternally evolving alongside the languages and technologies we use.

IOC - Inversion Of Control
AOP - Aspect Oriented Programming. It's feature and model of programming.

While helping you make your code more truly object oriented, Spring introduces you to two new grammars in the world of application development – the Inversion of Control (IoC) container and Aspect Oriented Programming (AOP). Both of these concepts arose naturally from the needs of developers to improve maintainability, productivity, portability, and design.

Frameworks such as Struts and Avalon gave more formal structure to web applications, and best practices began to emerge from, and inform, these frameworks. Spring's framework expanded on the concepts introduced in Struts and Avalon, adding its own twist in the form of its extremely lightweight Inversion of Control (IoC) container. Spring is different from other frameworks in that it can be used with virtually any Java component, including POJOs (Plain Old Java Objects), and can be leveraged in small pieces.

A framework is essentially a skeleton, a structure around which the fleshing out of your application occurs.

In this chapter we'll explore the context of Spring's most important component – the IoC container – and how Spring can lead you to better Object Oriented programming and eventually to new possibilities with Aspect Oriented Programming. The Spring framework can't make bad code good, but it can enforce good coding practices that make it easier for you and your fellow developers to cooperate in writing well-factored, reusable, readable, and manageable application components.

Constructor based DI -Springs
Setter based DI - Springs
Interface based DI - Avalon

The IoC container enforces the dependency injection pattern for your components, leaving them loosely coupled and allowing you to code to abstractions.

AutoWiring :

auto wiring by Name : the bean names matched against member variable of the class. If matched, the beans get referred automatically by member variables of a class. 
auto wiring by Type : the bean types matched against member variable type. If matched , the beans get referred automatically by member variables of a class.
Note: there should be only one bean expected in spring configuration for the type to avoid ambiguity
auto wiring constructor : it is same as auto wiring by Type , the difference is it works with constructor unlike the above where it works based on setters. 
Note: there should be only one bean expected in spring configuration for the type to avoid ambiguity

ApplicationContext:

The default behavior of an AC is to creating bean objects when it gets initialized by reading the configuration file passed to it.

Basic Scopes:

singleton: Only once per spring container. It's a default behavior. this singleton is not same as the Single Design pattern. You can have multiple spring containers in the same jvm , so as you have multiple references of a same object in one jvm which is against to Singleton principle. The spring singleton scope doesn't give the exact representation of singleton.

prototype: New bean is created with request or reference. Beans are not gets initialized when the Context gets created. It only creates when getBean() called or when the bean referred.

web-aware context bean scopes:
request: New bean per servlet request.
session: New bean per session
Global session : New bean for global HTTP Session(portlet context)

AOP (Aspect Oriented Programing) :