The Spring container also has the ability to check for the existence of unresolved dependencies of a bean deployed into the container. These are properties of the bean, which do not have actual values set for them in the bean definition, or alternately provided automatically by the autowiring feature. Spring container provides a dependency checking mechanism for a bean which can be specified through dependency-check attribute of a bean when using XML-based configuration.

Various dependency checking modes supported and their behavior is provided below:

• none – This is the default mode and implies that dependency check will not be performed.
• simple – Dependency Check is performed for primitive types and collections
• object – Dependency Check is performed for objects
• all – Dependency Check is done for all objects, primitive types and collections

For annotation based configuration, this can be achieved using @Required annotation in in the org.springframework.beans.factory.annotation package.

The basic functions of both these transaction framework is the same. Both of them allow transaction to be applied at a method level and setRollbackOnly to be called within the transaction context to rollback. However Spring framework is far more versatile due to following reasons:

a) Spring declarative transactions can be applied to any class whereas EJB CMT can be applied only on EJBs
b) EJB CMT can only work with JTA whereas Spring can work with JDBC, JPA, Hibernate etc.
c) Spring framework allows declarative rollback rules whereas this can only be done programmatically in EJB CMT.

However, Spring framework does not support propagation of transactions across remote calls. This can be achieved only through EJB CMT.

Spring supports programmatic as well as declarative transaction management. The main benefits of using Spring transaction management are:

a) Provides a consistent programming model across different transaction APIs like JTA, JDBC, JPA, Hibernate etc.
b) Provides a simpler API for programmatic transaction management than JTA
c) Integrates very well with Spring’s various data access abstractions

The init-method and destroy-method can be used to provide custom code that will be invoked by the Spring container. The init-method is invoked immediately after the bean is initialized and the destroy-method is invoked before the bean is removed from the container.

Spring inner beans are beans that are defined within the scope of another bean. The concept is very similar to Java inner classes. Inner beans are supported both by constructor injection as well as setter injection.

Inner beans are typically used when a bean is being referenced by only one bean. An important point to note is that scope, id and name tags for inner beans are always ignored by the Spring container. Inner beans are always anonymous and they are always scoped as prototype.

The default behavior of Spring Container is to instantiate all singleton beans at startup. Lazy Initialization is a mechanism through which the Spring container can be instructed to instantiate the bean only when it gets a first client request. Lazy initialization is achieved by providing lazy-init property to true on the bean.

Lazy Initialization does not guarantee that a bean will not be instantiated at startup. A bean with lazy-init property set to true can still be instantiated at startup if it is referenced by a non-lazy-init singleton bean. In such case Spring container has to create the instance for dependency injection.

A Spring bean can inherit from another Spring bean through parent attribute on the child bean. The child bean will inherit all configuration information like constructor arguments, property values and container specific information. The inheritance concept is very similar to Java inheritance whereby the child can override some values and add some more if needed. However Spring does not enforce Java inheritance for the classes that are configured as parent child through spring configurations.

In Spring framework, the BeanPostProcessor interface defines a number of callback methods that an application developer can implement in order to provide their own  instantiation logic, dependency-resolution logic etc. These methods are invoked by the Spring container after it has finished with bean instantiation, configuring and initialization.

Multiple BeanPostProcessor can be configured for a bean. The order of their execution can be controlled through “order” property.

Spring provides an alternate means to configure beans through use of Java Annotations. Some of the common annotations and their usage is below:

@Configuration – The class having this annotation can be used by Spring container as a source of bean definitions
@Bean – The method having this annotation returns an object that will be treated as a bean by spring container
@Import – Allows loading of bean definitions from another configuration class.
@Scope – Used along with @Bean annotation to configure scope for the bean

The Spring Framework supports five scopes which allow us to control the scope of the bean.

a) singleton – This is the default scope and allows a single instance per Spring IoC container.

b) prototype – Allows a bean to be instantiated any number of times. A distinct instance is provided to everyone who has wiring for this bean.

c) request – Scopes a single bean definition to the lifecycle of a single HTTP request; that is each and every HTTP request will have its own instance of a bean created off the back of a single bean definition. This scope is only valid in the context of a web-aware Spring ApplicationContext.

d) session – Scopes a single bean definition to the lifecycle of a HTTP Session. This scope is only valid in the context of a web-aware Spring ApplicationContext.

e) global session – Scopes a single bean definition to the lifecycle of a global HTTP Session. Typically only valid when used in a portlet context. Only valid in the context of a web-aware Spring ApplicationContext.