Sunday, January 29, 2012

Spring MVC -- My understandings and Notes


Which is better Bean factory or Application Context?.

Bean factory instantiates and Configures the Bean, Application context also does the same however Application Context enables the configured bean for many other enterprise specific features like AOP and transactions.

So always Application Context is better except in case where resources are limited as in mobile.

Bean Factory provides advanced configuration mechanisms to manage the beans of any types.Application context is build on top of this and provides easy access to features like AOP and Transaction Management.Application Context is Complete super set of Bean factory and all features in bean factory are present in application context and it enables the beans to be more enterprise centric.

The org.springframework.beans.factory.BeanFactory is the actual representation of the Spring IoC
container
.org.springframework.beans.factory.BeanFactory is the actual representation of the Spring IoC
container.

The Most Commonly used BeanFactoryImplementations are XmlBeanFactory class were the configurations are specified in XML file and the the class reads these files and creates configurable system out of it.

One way to load all the beans is to configure Application Context with all the Xml fragments and  use the application context constructor which takes multiple locations.

Eg:
ApplicationContext context = new ClassPathXmlApplicationContext(
new String[] {"services.xml", "mockServices.xml"});


//Copied From Spring Documentration.
Or can use the Import within Application Context to load it.


<beans>
<import resource="services.xml"/>
<import resource="resources/messageSource.xml"/>
<import resource="/resources/themeSource.xml"/>
<bean id="bean1" class="..."/>
<bean id="bean2" class="..."/>
</beans>
fully qualified resource locations instead of relative paths: e.g. "file:C:/config/services.xml" or "classpath:/config/services.xml". However It is generallypreferable to keep an indirection for such absolute locations, e.g. through "${...}" placeholders that are resolved against JVM system properties at runtime.

Every bean has one or more ids (also called identifiers, or names; these terms refer to the same thing). These
ids must be unique within the container the bean is hosted in.

Aliasing beans

Format is :
<alias name="fromName" alias="toName"/>

As a concrete example, consider the case where component A defines a DataSource bean called
componentA-dataSource, in its XML fragment. Component B would however like to refer to the DataSource as
componentB-dataSource in its XML fragment. And the main application, MyApp, defines its own XML
fragment and assembles the final application context from all three fragments, and would like to refer to the
DataSource as myApp-dataSource.

<alias name="componentA-dataSource" alias="componentB-dataSource"/>
<alias name="componentA-dataSource" alias="myApp-dataSource" />


Inner Class

The inner class Definiton requires a Binary Name.

com.example.Foo$Bar
Foo in the com.example package, and this Foo class has a static
inner class called Bar

Instatantiation Using Spring

Static Instance

1 . The normal way were container will instantiate a class with default constructor if the class name is specified in class property else the class property can be specified by a factory class in this case it need not be the object of the same class, for container it doesnt matter.

Eg: < bean id="sampleBean" class="org.sample.SampleBean" factory-method="createInstance"/>

Factory Instance Method

<!-- the factory bean, which contains a method called createInstance() -->
<bean id="serviceLocator" class="com.foo.DefaultServiceLocator">
<!-- inject any dependencies required by this locator bean -->
</bean>
<!-- the bean to be created via the factory bean -->
<bean id="exampleBean"
factory-bean="serviceLocator"
factory-method="createInstance"/>

In Spring Constructor Argument Resolution is through type of the parameters.If the parameters are non ambiguous there is no issues in the resolution.
To Resolve this issue -- The Constructor Argument Type can be specified.

1. Argument Type
<bean id="sample" class="org.com.Sample>
<constructor-arg type="java.lang.String" value="Aravind"/>
<construcot-arg type="int" value="30000"/>
</bean>


2. Index Based

<bean id="sample" class="org.com.Sample">
<constructor-arg index="0" val="100"/>
</bean>

The container validates the bean definition when container is getting created however it will not cretate the bean until and unless it is required.For those beans that are singleton-scoped
and set to be pre-instantiated (such as singleton beans in an ApplicationContext),When a bean actually has to be created, this will potentially cause a graph of other beans to be created, as its dependencies and its
dependencies' dependencies (and so on) are created and assigned.

Disadvantage of Constructor Injection.

The constructor injection can lead to Circular Dependencies.The class A requires B in constructor and B requires A in Constructor.This time Spring will throw a "BeanCurrentlyInCreationException" during runtime.
The best way to avoid this through setter injection.With Setter injection unlike above case if a circular dependancy happens then any one of the objects will be injected before fully constructing it.

Prototype vs Singleton
----------------------

By Default the Bean is singleton in a spring container( even if a getBean method is used).Inorder to make a bean non singleton or protoype we have to apply the singleton= false explicitly.

Life Cycle of a bean can be controlled using the init-method and destroy-method of bean

<bean id="connectionPool"
class="com.sample.connection"
init-method="initialize" destroy-method="destroy"/>

There is yet another way using 2 interfaces InitialzingBean and DisposableBean..The afterPropertiesSet method is called when initializing bean interface is used and Destroy method is called when Disposable Bean interface is implemented.However it is not advisable to use any of these as there is a direct coupling with Spring code and is better to use injection properties.This can be used if we are extending the framework code.

Wiring
-------

1. Instead of using a Ref a bean can be decalred directly under the <property> tag and the disadvantage is it cannot be reusable however we can use it if we dont want actual bean object without the wrapper.

2 .

<list> java.awt.List, arrays
<set> java.awt.Set
<map> java.awt.Map
<props> java.awt.Properties

Can use this directly at the place of value to create an object of these type.

3.A null property can be wired by giving the value as <null/>.
  Eg: <beans>
<bean id="simpleBean">
<property name="refacor"><null/><property>

No comments:

Post a Comment