The Java singleton is scoped by the Java class loader, the Spring singleton is scoped by the container context.
Which basically means that, in Java, you can be sure a singleton is a truly a singleton only within the context of the class loader which loaded it. Other class loaders should be capable of creating another instance of it (provided the class loaders are not in the same class loader hierarchy), despite of all your efforts in code to try to prevent it.
In Spring, if you could load your singleton class in two different contexts and then again we can break the singleton concept.
So, in summary, Java considers something a singleton if it cannot create more than one instance of that class within a given class loader, whereas Spring would consider something a singleton if it cannot create more than one instance of a class within a given container/context.
Change spring-servlet.xml Filename
(Spring Web Contenxt Configuration Filename)
The first thing that we do when we want to implement
Spring MVC in our project is to add DispatcherServlets entry in deployment
descriptor (web.xml). Also we write a spring web configuration xxxx-servlet.xml
which contains all the MVC mappings and data.
By
default the name of file must be XXX-servlet.xml where XXX is the name of
servlet. For example in below entry in Web.xml we defined servlet named
“spring”.
<servlet>
<servlet-name>spring</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
Note
that the servlet name is “spring” and thus, Spring will by default load file
named “spring-servlet.xml” from your webapps WEB-INF folder.
What if we want to load a file
called “bean.xml” instead of default “XXX-servlet.xml” ?
Well,
this can be achieved by passing one init-parameter to spring’s
DispatcherServlet. Check the following web.xml snippet.
<servlet>
<servlet-name>spring</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/bean.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
Note that in above code snippet, we have passed an
init-param to DispatcherServlet called contextConfigLocation. Using
this parameter not only can we change the name of Spring’s web context file but
also change its location.
This parameter will call setContextConfigLocation method
on DispatcherServlet and
overrides default context config file. Note that it is possible to add multiple
locations separated by any number of commas and spaced.
How Spring Controller
Request Mapping works in Spring MVC
In
the previous tutorial, we have discussed the role of a Dispatcher Servlet and
the steps required to create a Spring MVC application. In this tutorial, we
will discuss different type of request mapping to Spring controllers.
Dispatcher
Servlet is used to handle all incoming requests and route them through Spring.
When DispatcherServlet receives a web request,
it determines which controllers should handle the incoming request.
It
first scans for all classes that are declared with the @Controller annotation. The
dispatching process depends on the various @RequestMapping annotations declared in a
controller class and its handler methods. There are three levels of request
mapping can be defined in Spring controller.
The
simplest strategy for using @RequestMapping annotations is to decorate the
handler methods directly. In this method, you need to declare mapping for each
handler method with the @RequestMapping annotation containing a URL pattern. If
a handler’s @RequestMapping annotation matches the request URL,
DispatcherServlet it dispatches the request to this handler for it to process
the request.
Following
are the different mapping types supported.
·By path
@RequestMapping(“path”)
·By HTTP method
@RequestMapping(“path”, method=RequestMethod.GET). Other Http methods such
as POST, PUT, DELETE, OPTIONS, and TRACE are are also supported.
In the above code snippet, the
controller add() method is declared
with @RequestMapping("/employee/add"). If the incoming request path
to matches is /employee/add, then the add() handler method
will be invoked to process the request.
Handler
mappings match URLs according to their paths relative to the context path
(i.e., the path where the web application is deployed) and the servlet path
(i.e., the path mapped to DispatcherServlet).
Mapping at Controller class level
The
@RequestMapping annotation can also be used to decorate a controller class.
This is helpful to take the control at top level and filter the incoming
requests. If the incoming request matches the pattern defined in controller
class, then it search the controller methods mappings.
The
following code snippet describes how to define Spring @RequestMapping at
controller class level.
Notice that, we have used the
wildcard (*) for the @RequestMapping annotation for broader URL matching.
Mapping requests by request type
The @RequestMapping annotation handles all
types of incoming HTTP request including GET, POST, PUT, DELETE, PATCH etc. By
default, it’s assumed all incoming requests to URLs are of the HTTP GET kind.
To differentiate the mapping by HTTP request type, we need to explicitly
specify the HTTP request method in the @RequestMapping declaration.
The
following code snippet describes how to declare Spring mappings by HTTP request
methods.
Which is the default handler mapping used by DispatcherServlet?
BeanNameUrlHandlerMapping
"By default the DispatcherServlet uses the BeanNameUrlHandlerMapping to map the incoming request. The BeanNameUrlHandlerMapping uses the bean name as the URL pattern. Since BeanNameUrlHandlerMapping is used by default, you need not do any seperate configuration for this."
Dispatcher
Servlet
What is the front controller class of Spring MVC?
A front controller is defined as a controller that handles all requests for a Web Application. DispatcherServlet servlet is the front controller in Spring MVC that intercepts every request and then dispatches requests to an appropriate controller. When a web request is sent to a Spring MVC application, dispatcher servlet first receives the request. Then it organizes the different components configured in Spring?s web application context (e.g. actual request handler controller and view resolvers) or annotations present in the controller itself, all needed to handle the request.
The Spring Framework is a very comprehensive framework.
The fundamental functionality provided by the Spring Container is dependency injection.
Spring provides a light-weight container, e.g. the Spring core container, for
dependency injection (DI). This container lets you inject required objects into
other objects. This results in a design in which the Java class are not
hard-coupled. The injection in Spring is either done via setter injection of
via construction injection. These classes which are managed by Spring must
conform to the JavaBean standard. In the context of Spring classes are also
referred to as beans or as Spring beans.
The Spring core container:
·handles the configuration, generally based on
annotations or on an XML file (XMLBeanFactory)
·manages the selected Java classes via the BeanFactory
The core container uses the so-called bean factory to
create new objects. New objects are generally created as Singletons if not
specified differently.
Class should be "Public" and "Public Constructor".
Dependency Inversion
Principle
1.1Motivation
When we design software applications we can consider the low
level classes the classes which implement basic and primary operations(disk
access, network protocols,...) and high level classes the classes which
encapsulate complex logic(business flows, ...). The last ones rely on the low
level classes. A natural way of implementing such structures would be to write
low level classes and once we have them to write the complex high level
classes. Since high level classes are defined in terms of others this seems the
logical way to do it. But this is not a flexible design. What happens if we need
to replace a low level class?
Let's take the classical example of a copy module which reads
characters from the keyboard and writes them to the printer device. The high
level class containing the logic is the Copy class. The low level classes are
KeyboardReader and PrinterWriter.
In a bad design the high level class uses directly and depends
heavily on the low level classes. In such a case if we want to change the
design to direct the output to a new FileWriter class we have to make changes
in the Copy class. (Let's assume that it is a very complex class, with a lot of
logic and really hard to test).
In order to avoid such problems we can introduce an abstraction
layer between high level classes and low level classes. Since the high level
modules contain the complex logic they should not depend on the low level
modules so the new abstraction layer should not be created based on low level
modules. Low level modules are to be created based on the abstraction layer.
According to this principle the way of designing a class
structure is to start from high level modules to the low level modules:
High Level Classes --> Abstraction Layer --> Low Level Classes
1.2Intent
·High-level modules should not depend on low-level modules.
Both should depend on abstractions.
·Abstractions should not depend on details. Details should
depend on abstractions.
1.3Example
Below is an example which violates the Dependency Inversion
Principle. We have the manager class which is a high level class, and the low
level class called Worker. We need to add a new module to our application to
model the changes in the company structure determined by the employment of new
specialized workers. We created a new class SuperWorker for this.
Let's assume the Manager class is quite complex, containing
very complex logic. And now we have to change it in order to introduce the new
SuperWorker. Let's see the disadvantages:
·We have to change the Manager class (remember it is a
complex one and this will involve time and effort to make the changes).
·Some of the current functionality from the manager class
might be affected.
·The unit testing should be redone.
All those problems could take a lot of time to be solved and
they might induce new errors in the old functionality. The situation would be
different if the application had been designed following the Dependency
Inversion Principle. It means we design the manager class, an IWorker interface
and the Worker class implementing the IWorker interface. When we need to add
the SuperWorker class all we have to do is implement the IWorker interface for
it. No additional changes in the existing classes.
// Dependency Inversion Principle - Bad example
classWorker {
publicvoidwork() {
//....working
}
}
ClassManager {
Workerworker;
PublicvoidsetWorker(Workerw)
{
worker=w;
}
publicvoidmanage(){
worker.work();
}
}
classSuperWorker {
publicvoidwork(){
//....working much more
}
}
Below is the code which supports the Dependency Inversion
Principle. In this new design a new abstraction layer is added through the
IWorker Interface. Now the problems from the above code are solved(considering
there is no change in the high level logic):
·Manager class doesn't require changes when adding
SuperWorkers.
·Minimized risk to affect old functionality present in
Manager class since we don't change it.
·No need to redo the unit testing for Manager class.
When this principle is applied it means the high level classes
are not working directly with low level classes, they are using interfaces as
an abstract layer. In this case instantiation of new low level objects inside
the high level classes (if necessary) cannot be done using the operator new.
Instead, some of the Creational design patterns can be used, such as Factory
Method, Abstract Factory, Prototype.
The Template Design Pattern is an example where the DIP
principle is applied.
Of course, using this principle implies an increased effort,
will result in more classes and interfaces to maintain, in a few words in more
complex code, but more flexible. This principle should not be applied blindly
for every class or every module. If we have a class functionality that is more
likely to remain unchanged in the future there is not need to apply this
principle.
Spring
Annotations: Contents:
ANNOTATION
USE
DESCRIPTION
@Autowired
Constructor, Field, Method
Declares a constructor, field, setter method, or configuration
method to be autowired by type. Items annotated with @Autowired do not have
to be public.
@Configurable
Type
Used with <context:springconfigured> to declare types
whose properties should be injected, even if they are not instantiated by
Spring. Typically used to inject the properties of domain objects.
@Order
Type, Method, Field
Defines ordering, as an alternative to implementing the org.
springframework.core.Ordered interface.
@Qualifier
Field, Parameter, Type, Annotation Type
Guides autowiring to be performed by means other than by type.
@Required
Method (setters)
Specifies that a particular property must be injected or else
the configuration will fail.
@Scope
Type
Specifies the scope of a bean, either singleton, prototype,
request, session, or some custom scope.
For spring to process annotations, add the
following lines in your application-context.xml file.
<context:annotation-config />
<context:component-scan base-package="...specify your package name..." />
Spring
supports both Annotation based and XML based configurations. You can even mix
them together. Annotation injection is performed before XML injection, thus
the latter configuration will override the former for properties wired through
both approaches.
@Service
Annotate all your service classes with
@Service. All your business logic should be in Service classes.
Annotate all your DAO classes with
@Repository. All your database access logic should be in DAO classes.
@Repository
publicclassCompanyDAOImpl implementsCompanyDAO {
...
}
@Component
Annotate your other components (for example
REST resource classes) with @Component.
@Component
publicclassContactResource {
...
}
@Component is a generic stereotype for any Spring-managed
component. @Repository, @Service, and @Controller are specializations of
@Component for more specific use cases, for example, in the persistence,
service, and presentation layers, respectively.
@Autowired
Let Spring auto-wire other beans into your classes using
@Autowired annotation.
@Autowire by default is a type driven injection. @Qualifier
spring annotation can be used to further fine-tune autowiring.
@Resource (javax.annotation.Resource) annotation can be used for
wiring by name.
Beans that
are themselves defined as a collection or map type cannot be injected through
@Autowired, because type matching is not properly applicable to them. Use
@Resource for such beans, referring to the specific collection or map bean by
unique name.
@Transactional
Configure your transactions with
@Transactional spring annotation.
To activate
processing of Spring's @Transactional annotation, use the
<tx:annotation-driven/> element in your spring's configuration file.
The default @Transactional settings are as
follows:
Propagation
setting is PROPAGATION_REQUIRED.
Isolation
level is ISOLATION_DEFAULT.
Transaction
is read/write.
Transaction
timeout defaults to the default timeout of the underlying transaction
system, or to none if timeouts are not supported.
Any
RuntimeException triggers rollback, and any checked Exception does not.
These default settings can be changed using various
properties of the @Transactional spring annotation.
Specifying
the @Transactional annotation on the bean class means that it applies to all
applicable business methods of the class. Specifying the annotation on a
method applies it to that method only. If the annotation is applied at both
the class and the method level, the method value overrides if the two
disagree.
@Scope
As with Spring-managed components in
general, the default and most common scope for autodetected components is
singleton. To change this default behavior, use @Scope spring annotation.
@Component
@Scope("request")
publicclassContactResource {
...
}
Similarly, you can annotate your component with
@Scope("prototype") for beans with prototype scopes.
Please note
that the dependencies are resolved at instantiation time. For prototype
scope, it does NOT create a new instance at runtime more than once. It is
only during instantiation that each bean is injected with a separate instance
of prototype bean.
Spring MVC Annotations
@Controller
Annotate your controller classes with
@Controller.
@Controller
publicclassCompanyController {
...
}
@RequestMapping
You use the @RequestMapping spring
annotation to map URLs onto an entire class or a particular handler method.
Typically the class-level annotation maps a specific request path (or path
pattern) onto a form controller, with additional method-level annotations
narrowing the primary mapping.
@Controller
@RequestMapping("/company")
publicclassCompanyController {
@Autowired
privateCompanyService companyService;
...
}
@PathVariable
You can use the @PathVariable spring
annotation on a method argument to bind it to the value of a URI template
variable. In our example below, a request path of /company/techferry will bind
companyName variable with 'techferry' value.
@Controller
@RequestMapping("/company")
publicclassCompanyController {
@Autowired
privateCompanyService companyService;
@RequestMapping("{companyName}")
publicString getCompany(Map<String,
Object> map,
@PathVariableString companyName) {
Company company
= companyService.findByName(companyName);
map.put("company",
company);
return"company";
}
...
}
@RequestParam
You can bind request parameters to method
variables using spring annotation @RequestParam.
Similarly, you can use spring annotation @RequestHeader to
bind request headers.
@ModelAttribute
An @ModelAttribute on a method argument
indicates the argument should be retrieved from the model. If not present in
the model, the argument should be instantiated first and then added to the
model. Once present in the model, the argument's fields should be populated
from all request parameters that have matching names. This is known as data
binding in Spring MVC, a very useful mechanism that saves you from having to
parse each form field individually.
@SessionAttributes spring annotation
declares session attributes. This will typically list the names of model
attributes which should be transparently stored in the session, serving as
form-backing beans between subsequent requests.
@Controller
@RequestMapping("/company")
@SessionAttributes("company")
publicclassCompanyController {
@Autowired
privateCompanyService companyService;
...
}
@SessionAttribute works as follows:
@SessionAttribute
is initialized when you put the corresponding attribute into model (either
explicitly or using @ModelAttribute-annotated method).
@SessionAttribute
is updated by the data from HTTP parameters when controller method with
the corresponding model attribute in its signature is invoked.
@SessionAttributes are cleared when you call
setComplete() on SessionStatus object
passed
into controller method as an argument.
The following listing illustrate these concepts. It is also
an example for pre-populating Model objects.
publicString
processSubmit(@ModelAttribute("pet") Pet pet,
BindingResult
result, SessionStatus status) {
newPetValidator().validate(pet, result);
if(result.hasErrors()) {
return"petForm";
}else{
this.clinic.storePet(pet);
status.setComplete();
return"redirect:owner.do?ownerId="
+
pet.getOwner().getId();
}
}
}
Spring Security Annotations
@PreAuthorize
Using Spring Security @PreAuthorize annotation,
you can authorize or deny a functionality. In our example below, only a user
with Admin role has the access to delete a contact.
@Transactional
@PreAuthorize("hasRole('ROLE_ADMIN')")
publicvoidremoveContact(Integer id) {
contactDAO.removeContact(id);
}
Loose Coupling and Tight Coupling
Core Module is
the heart of Spring, tight coupling
and loose coupling is the heart concept of Core Module :-) so let us try to understand
about tight and loose coupling between java objects in
spring [ you can't move further without
understand this concepts, be care ]
Tight Coupling Between Java Objects
Let us see tight
coupling between java objects first, take
an example..
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class Traveler
{
Car c=new
Car();
void
startJourney()
{
c.move();
}
}
class Car
{
void move()
{
// logic...
}
}
·In the above
example, Traveler object is depends on car object. So traveler class
creating an object of Car class inside it [ line number 3 ]
·If the other class
object is created in the dependent class [ like Car class object in Traveler
class ], there exist tight coupling, i mean if method in car object is changed
then we need to do the changes in the Traveler class too so its the tight coupling between Traveler and Car class objects
Loose Coupling between Java Objects
Let us see loose coupling between java objects, take an example..
In order to overcome tight coupling
between objects, spring framework uses dependency injection mechanism with the
help of POJO/POJI model and through dependency injectionits possible to achieve loose coupling
In the above example
Traveler, Car is tightly coupled. If we want to achieve loose coupling between the objects Traveler and Car, we need to re-write
the application like….
In above example, spring container will inject either Car object or Bike object into theTraveler by calling
setter method, So if Car object is replaced with Bike then no changes are
required in Traveler class, this means there is loose coupling between Traveler and Vehicle object. Actually setter
method will be activated through xml file, will see this later
for now we are good to go
1.1Tight-coupling and
Loose-coupling between objects
1.2Tight-Coupling:-
1. While creating complexapplication injava,the logicof one class will callthe logicof another class to provide same
service to the clients.
2. If one class calling another class logic then it is called
collaboration.
3. When one class is collaborating with another class then
there exists tight-coupling between the twoclasses.
4. If one class wants to callthe logicof asecond classthen
they first class need an object ofsecond
classit means the first class
create an object ofsecond class.
5. For example, if we have twoclassescalled traveller and car, traveller
class is calling logicof carclass;
in this case traveller class creates an objectof carclass.
6. In the above traveller class and carclasses, car class object of
dependency for traveller object.
Example:-
7. In the above example traveller object is tightly
coupled with car object because in place car object if you want to use
bike object then, we need to make changes in Traveller class
Example :-
1.3Loose-Coupling:-
1. In Loose-Coupling, when one object is depending on another
class object, some external entity will provide that dependency object to the
main object that external object we call as a Container.
2. In order to get loose-coupling between objects the
following two rules are required
1. Theclassesshould follow POJI/POJO model.
2. Apply dependency injection mechanism.
For example:-
3. In the
above traveler class, an external entity injects either car (or) Bike
object.
4. In traveler, these are no changes required we are
shifting the dependency from car to a Bike.
5. In the above traveler class, we aretokenvehicle reference, so that an external
object (Container) can injects either car object (or) Bike object,depends onrequirement if a traveler.
6. In springframe work, spring container follows dependency injection
mechanism and injects the dependency objectsrequired fora
main object.
7. Springframe
workis much success because of
one of the main reason is it promotes Loose-Coupling between the objects.
·First step is to
create application context where we used framework API ClassPathXmlApplicationContext(). This API loads beans
configuration file and eventually based on the provided API, it takes care of
creating and initializing all the objects ie. beans mentioned in the
configuration file.
·Second step is
used to get required bean using getBean()
method of the created context. This method uses bean ID to return a generic
object which finally can be casted to actual object. Once you have object, you
can use this object to call any class method.
The spring container is at the core of the Spring Framework. The
container will create the objects, wire them together, configure them, and
manage their complete lifecycle from creation till destruction. The spring
container uses dependency injection (DI) to manage the components that make up
an application.
The container gets its instructions on what objects to instantiate,
configure, and assemble by reading configuration metadata provided. The
configuration metadata can be represented either by XML, Java annotations or
Java code.
The Spring IoC container makes use of Java POJO classes and
configuration metadata to produce a fully configured and executable system or
application.
Beans
The objects that form the backbone of your application and that are
managed by the Spring IoC container are called beans. A bean is an object that
is instantiated, assembled, and otherwise managed by a Spring IoC container.
These beans are created with the configuration metadata that you supply to the
container, for example, in the form of XML <bean/> definition.
The bean
definition contains the information called configuration metadata which
is needed for the container to know the followings:
·How to create a bean
·Bean's lifecycle details
·Bean's dependencies
Spring
Configuration Metadata
Spring IoC
container is totally decoupled from the format in which this configuration
metadata is actually written. There are following three important methods to
provide configuration metadata to the Spring Container:
·XML based configuration file.
·Annotation-based configuration
·Java-based configuration
sample of XML based configuration file with
different bean definitions including lazy initialization, initialization method
and destruction method:
<!-- collaborators and configuration for
this bean go here -->
</bean>
<!-- A bean definition with lazy init set
on -->
<bean id="..."
class="..." lazy-init="true">
<!-- collaborators and configuration for
this bean go here -->
</bean>
<!-- A bean definition with initialization
method -->
<bean id="..." class="..."
init-method="...">
<!-- collaborators and configuration for
this bean go here -->
</bean>
<!-- A bean definition with destruction
method -->
<bean id="..."
class="..." destroy-method="...">
<!-- collaborators and configuration for
this bean go here -->
</bean>
<!-- more bean definitions go here -->
</beans>
Autowiring
Advantages of Autowiring
Autowiring requires less
code because we don’t need to write the code to inject the dependency
explicitly.
It reduces develop time
by removing the necessity of specifying properties and constructor
arguments.
Disadvantages of Autowiring
Autowiring is less exact
than explicit wiring. Spring is careful to avoid guessing in the case
of ambiguity that might have unexpected results, the relationships between
Spring-managed objects are no longer document explicitly.
Wiring information may
not be available to tools that generate documentation from a Spring
container.
Multiple bean definition
within the container may match the type specified by the constructor or
setter method argument to be autowired.
Limitations With Autowiring
Explicit dependencies in
constructor-argument and property settings always override autowiring. You
cannot autowire simple properties such as primitives, Strings, and
Classes.
Overriding possibilities:
We can define dependencies using property or constructor-args tag which
will always override autowiring.
Primitive data type: We
have to define primitive data types String or Integer using property or
constructor-args tag. You cannot autowire these tags.
Confusing Nature: If you
have lot of dependency in a program, then it’s hard to find using
autowire attribute of bean.
Autowiring
Spring can
autowire a relationship between collaborating beans without using
constructor-arg and property tags which helps with the amount of XML
configuration.
You can allow Spring to
resolve collaborators automatically for your bean by inspecting the
contents of the Application Context.
Autowiring of the Spring
framework enables you to inject the object dependency implicitly.
Autowiring needs significantly less specification
with properties or constructor arguments.
Autowiring can update
configuration as your objects. For example, if you need to add
a dependency to a class, that dependency can automatically satisfy your
need to modify the configuration. Autowiring can be especially useful
during development, without negation the option of switching to explicit
wiring when the code becomes more stable.
Autowiring Modes
Modes
Description
1.
No
It’s a default autowiring mode. It means no
autowiring.
2.
byName
Autowiring using property name. Spring container
looks the properties of the beans on which autowire attribute is set to
byName in the XML configuration file. It tries to match and wire its
properties with the beans defined by the same name in the configuration file.
3.
byType
Autowiring using property type. Allows a property to
be autowired if exactly one bean of property type exists in the container. If
more than one exists, it’s a fatal exception is thrown, which indicates that
you may not used byType autowiring for that bean.
4.
constructor
Tries to match a constructor of the autowired bean
with
beans whose types are assignable to the constructor
arguments. There is not exactly one bean of the constructor argument in the
container, a fatal error is raise.
5.
autodetect
Spring first tries to autowire by constructor, if it
doesn't work then If that fails than tries to autowired by using byType.
Example of Autowiring
publicclassBook
{
privateAuthorauthor;
publicBook(Authorauthor) {
this. customer=customer;
}
publicvoidsetAuthor (Authorauthor) {
this.author=author;
}
//.......
}
publicclassAuthor
{
//......
}
1.
Auto-Wiring ‘no’
This
is a default autowiring mode. It means no autowiring.
In
the Spring framework, everything is given a name. Bean properties are given a
name and the beans that are wired to those properties, too.
The
name of a property happens to match the names of the bean that is to be wired
to that property. Spring framework that the bean should be automatically wired
into the property.
Autowired
a bean by property name. In this case, since the name of the "author"
bean is the same name of the “book” bean’s property (“Author”), Spring
will be autowired to it via the setter method – “setAuthor (Author
author)”.
Autowiring using byType
works similarly to byName. When attempting to autowire a property byType,
Spring will look T beans whose type is assigned to the property’s type.
Autowire a bean by data
type. In this case, the data type of the “author” bean is the same as the
data type of the “book” bean’s property (Author object), so, Spring will
autowire it via the setter method – “setAuthor (Author author)“.
If your bean is
configured using a constructor injection, you may choose to put the
<constructor-arg> elements.constructor arguments from beans in the Spring
context.
Autowire
a bean by property data type in constructor arguments. Since the data type
of “author” bean is same as the constructor argument data type in “book”
bean’s property (Author object), Spring autowired it using the constructor
method – “public Book(Author author)“.
If you want to autowire
beans, but you can’t decide which type of autowiring to use, have no fear.
We can set the autowire attribute to autodetect.
If a default constructor
is found, it first tries to autowire by “constructor”; otherwise, if it
doesn't work but fails, then it tries to autowire using “byType”. In
this case, since there is a default constructor in the “Book”
class, Spring autowired it via the constructor method – “public Book
(Author author) “.
You
just learned about autowiring and how to use it in Java web
development (Spring).
Don’t forget to give credit to the Java development team that worked hard to
help you understand the advantages, limitations, and disadvantages of
autowiring.
Autowiring in Spring Autowiring feature of spring framework enables you to inject the
object dependency implicitly. It internally uses setter or constructor
injection. Autowiring can't be used to inject primitive and string values. It
works with reference only.
Advantage of Autowiring It requires the less code because we don't need to
write the code to inject the dependency explicitly.
The
default scope of Spring bean is singleton, so there will be only one instance
per context. That means that all the having a class level variable that any
thread can update will lead to inconsistent data. Hence in default mode spring
beans are not thread-safe.
However
we can change spring bean scope to request, prototype or session to achieve
thread-safety at the cost of performance. It’s a design decision and based on
the project requirements.
1.What do you understand by Dependency
Injection?
Dependency
Injection design pattern allows us to remove the hard-coded dependencies and
make our application loosely coupled, extendable and maintainable. We can
implement dependency injection pattern to move the dependency resolution from
compile-time to runtime.
Some
of the benefits of using Dependency Injection are: Separation of Concerns,
Boilerplate Code reduction, Configurable components and easy unit testing.
Read
more atDependency
Injection Tutorial. We can also useGoogle
Guide for Dependency Injectionto automate the process of dependency injection. But in
most of the cases we are looking for more than just dependency injection and
that’s why Spring is the top choice for this.
2.How do we implement DI in Spring
Framework?
We
can use Spring XML based as well as Annotation based configuration to implement
DI in spring applications. For better understanding, please readSpring
Dependency Injectionexample
where you can learn both the ways with JUnit test case. The post also contains
sample project zip file, that you can download and play around to learn more.
2Spring -
Bean Scopes
The Spring Framework supports following five
scopes, three of which are available only if you use a web-aware
ApplicationContext.
Scope
Description
Singleton
This scopes the bean definition to a single
instance per Spring IoC container (default).
Prototype
This scopes a single bean definition to have any
number of object instances.
Request
This scopes a bean definition to an HTTP request.
Only valid in the context of a web-aware Spring ApplicationContext.
Session
This scopes a bean definition to an HTTP session.
Only valid in the context of a web-aware Spring ApplicationContext.
global-session
This scopes a bean definition to a global HTTP
session. Only valid in the context of a web-aware Spring ApplicationContext.
The singleton
scope:
If scope is set to singleton, the Spring IoC
container creates exactly one instance of the object defined by that bean
definition. This single instance is stored in a cache of such singleton beans,
and all subsequent requests and references for that named bean return the
cached object.
The default scope is always singleton however, when
you need one and only one instance of a bean, you can set the scope
property to singleton in the bean configuration file, as shown below:
<!-- A bean definition with singleton scope -->
<bean id="..." class="..."
scope="singleton">
<!-- collaborators and configuration for this bean go here -->
If scope is set to
prototype, the Spring IoC container creates new bean instance of the object
every time a request for that specific bean is made. As a rule, use the
prototype scope for all state-full beans and the singleton scope for stateless
beans. To define a
prototype scope, you can set the scope property to prototype in
the bean configuration file, as shown below:
<!-- A bean definition with singleton scope -->
<beanid="..."class="..."scope="prototype">
<!-- collaborators and configuration for this bean go here -->
</bean>
difference between session and global session
in spring
globalSession is something which is
connected to Portlet applications. When your application works in Portlet
container it is built of some amount of portlets. Each portlet has its own
session, but if your want to store variables global for all portlets in your
application than you should store them in globalSession. This scope doesn't have any
special effect different from session scope in Servlet based applications.
session - Scopes a single bean definition to the lifecycle
of an HTTP Session. Only valid in the context of a web-aware Spring
ApplicationContext.
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.
A Portlet
container runs portlets and provides
them with the required runtime environment.
A portlet container contains
portlets and manages their life cycles. It also provides persistent storage
mechanisms for the portlet preferences. A portlet container receives requests
from the portal to execute requests on the portlets hosted by it. A portlet
container is not responsible for aggregating the content produced by the
portlets; the portal itself handles aggregation. A portal and a portlet
container can be built together as a single component of an application suite
or as two separate components of a portal application.
Portlets produce
fragments of markup (HTML, XHTML, WML) code that are aggregated into a portal. Typically, following the desktop metaphor, a portal page is displayed as a
collection of non-overlapping portlet windows, where each portlet window
displays a portlet. Hence a portlet (or collection of portlets) resembles
a web-based
application that is
hosted in a portal.
Life of traditional java objects starts on calling new operator which
instantiates the object and finalize() method is getting called when the object
is eligible for garbage collection. Life cycle of Spring beans are different as
compared to traditional java objects.
Spring framework provides the following ways which can be used
to control the lifecycle of bean:
1.InitializingBean and DisposableBean callback
interfaces
2.Bean Name, bean factory and Application Context
Aware interfaces for specific behavior
3.custom init() and destroy() methods in bean
configuration file
For annotation based configurations -
@PostConstruct and @PreDestroy annotations
Below diagram shows the complete lifecycle methods (from
instantiate to Ready To use )
Following diagram shows the method calling at the time of
destruction.
--------------------------------
The life cycle of
a Spring bean is easy to understand. When a bean is instantiated, it may be
required to perform some initialization to get it into a usable state.
Similarly, when the bean is no longer required and is removed from the container,
some cleanup may be required. Though, there is
lists of the activities that take place behind the scenes between the time of
bean Instantiation and its destruction, but this chapter will discuss only two
important bean lifecycle callback methods which are required at the time of
bean initialization and its destruction. To define setup
and teardown for a bean, we simply declare the <bean> with init-method
and/or destroy-method parameters. The init-method attribute specifies a
method that is to be called on the bean immediately upon instantiation.
Similarly, destroy-method specifies a method that is called just before a bean
is removed from the container.
2.3Initialization
callbacks:
The org.springframework.beans.factory.InitializingBean interface
specifies a single method:
voidafterPropertiesSet()throwsException;
So you can simply implement above interface and initialization work can
be done inside afterPropertiesSet()
method as follows:
publicclassExampleBeanimplementsInitializingBean{
publicvoidafterPropertiesSet(){
// do some initialization work
}
}
In the case of XML-based configuration metadata, you can use the init-method
attribute to specify the name of the method that has a void no-argument
signature. For example:
<beanid="exampleBean"
class="examples.ExampleBean"init-method="init"/>
Following is the class definition:
publicclassExampleBean{
publicvoidinit(){
// do some initialization work
}
}
2.4
2.5Destruction callbacks
The org.springframework.beans.factory.DisposableBean
interface specifies a single method:
void destroy()throwsException;
So you can simply implement above interface and finalization work can be
done inside destroy() method as follows:
publicclassExampleBeanimplementsDisposableBean{
publicvoid destroy(){
// do some destruction work
}
}
In the case of XML-based configuration metadata, you can use the destroy-method
attribute to specify the name of the method that has a void no-argument
signature. For example:
Every java based application has a few objects that
work together to present what the end-user sees as a working application. When
writing a complex Java application, application classes should be as
independent as possible of other Java classes to increase the possibility to
reuse these classes and to test them independently of other classes while doing
unit testing. Dependency Injection (or sometime called wiring) helps in gluing
these classes together and same time keeping them independent.
Consider you have an application which has a text
editor component and you want to provide spell checking. Your standard code
would look something like this:
public class TextEditor {
privateSpellCheckerspellChecker;
publicTextEditor() {
spellChecker = new
SpellChecker();
}
}
What we've done here is create a dependency between
the TextEditor and the SpellChecker. In an inversion of control scenario we
would instead do something like this:
public class TextEditor {
privateSpellCheckerspellChecker;
publicTextEditor(SpellCheckerspellChecker)
{
this.spellChecker = spellChecker;
}
}
Here TextEditor should not worry about SpellChecker
implementation. The SpellChecker will be implemented independently and will be
provided to TextEditor at the time of TextEditor instantiation and this entire
procedure is controlled by the Spring Framework.
Here, we have removed the total control from
TextEditor and kept it somewhere else (ie. XML configuration file) and the
dependency ( ie. class SpellChecker) is being injected into the class
TextEditor through a Class Constructor. Thus flow of control has been
"inverted" by Dependency Injection (DI) because you have effectively
delegated dependence’s to some external system.
Second method of injecting dependency is through Setter
Methods of TextEditor class where we will create SpellChecker instance and
this instance will be used to call setter methods to initialize TextEditor's
properties.
Thus, DI exists in two major variants and following
two sub-chapters will cover both of them with examples:
Constructor-based DI is
accomplished when the container invokes a class constructor with a number of
arguments, each representing a dependency on other class.
Setter-based DI is accomplished
by the container calling setter methods on your beans after invoking a
no-argument constructor or no-argument static factory method to instantiate
your bean.
You can mix both, Constructor-based and
Setter-based DI but it is a good rule of thumb to use constructor arguments for
mandatory dependencies and setters for optional dependencies.
Code is cleaner with the DI principle and
decoupling is more effective when objects are provided with their dependencies.
The object does not look up its dependencies, and does not know the location or
class of the dependencies rather everything is taken care by the Spring Framework.
4Spring
Constructor-based Dependency Injection
Constructor-based
DI is accomplished when the container invokes a class constructor with a number
of arguments, each representing a dependency on other class.
Setter-based
DI is accomplished by the container calling setter methods on your beans after
invoking a no-argument constructor or no-argument static factory method to
instantiate your bean.
TextEditor.java
packagecom.tutorialspoint;
public class TextEditor {
privateSpellCheckerspellChecker;
// a
setter method to inject the dependency.
public void setSpellChecker(SpellCheckerspellChecker)
{
In Spring Web MVC, DispatcherServlet class
works as the front controller. It is responsible to manage the flow of the
spring mvc application.
The @Controller annotation is used to mark
the class as the controller in Spring 3.
The @RequestMapping annotation is used to
map the request url. It is applied on the method.
Understanding the flow of Spring
Web MVC
1)
Create the request page (optional)
This is the simple
jsp page containing a link. It is optional page. You may direct invoke the
action class instead.
index.jsp
<a href="hello.html">click</a>
2)
Create the controller class
To create the
controller class, we are using two annotations @Controller and @RequestMapping. The @Controller
annotation marks this class as Controller. The @Requestmapping
annotation is used to map the class with the specified name. This class returns
the instance of ModelAndView controller with the mapped name, message name and
message value. The message value will be displayed in the jsp page.
3)
Provide the entry of controller in the web.xml file
In this xml file,
we are specifying the servlet class DispatcherServlet that acts as the front
controller in Spring Web MVC. All the incoming request for the html file will
be forwarded to the DispatcherServlet.
This is the
important configuration file where we need to specify the ViewResolver and View
components. The context:component-scan
element defines the base-package where DispatcherServlet will search the
controller class. Here, the InternalResourceViewResolver
class is used for the ViewResolver. The prefix+string
returned by controller+suffix page will be invoked for the view component. This xml file
should be located inside the WEB-INF directory.
3) What are the steps to connect to the database in java?
Registering the driver
class
Creating connection
Creating statement
Executing queries
Closing connection
ApplicationContext.
BeanFactory
Here we can have more than one config files possible
In this only one config file or .xml file
Application contexts can publish events to beans that are
registered as listeners
Doesn’t support.
Support internationalization (I18N) messages
It’s not
Support application life-cycle events, and validation.
Doesn’t support.
Support many enterprise services such JNDI access,
EJB integration, remoting
Doesn’t support.
Question 7: What type of transaction
Management Spring support?
Ans: This spring interview questions is little difficult as
compared to previous questions just because transaction management is a
complex concept and not every developer familiar with it. Transaction
management is critical in any applications that will interact with the
database. The application has to ensure that the data is consistent and the
integrity of the data is maintained. Two type of transaction management
is supported by spring
1.
Programmatic transaction management
2.
Declarative transaction management.
In Spring, the Inversion of Control (IoC) principle is
implemented using the Dependency Injection (DI) design
pattern. Let's understand dependency injection with the help of an example.
First we will see a java version of the example and later we will add spring
functionalities to it. As far as the example go, its pretty simple. The QuizMater interface
exposes the popQuestion() method. To keep things simple, our QuizMaster will
generate only one question.
QuizMaster.java
----------------
packagecom.vaannila;
public
interface QuizMaster {
public String popQuestion();
}
The StrutsQuizMaster and the SpringQuizMaster class
implements QuizMaster interface and they generate questions
related to struts and spring respectively.
StrutsQuizMaster.java
----------------------
packagecom.vaannila;
public
class StrutsQuizMaster implements QuizMaster {
@Override
public
String popQuestion() {
return
"Are you new to Struts?";
}
}
SpringQuizMaster.java
----------------------
packagecom.vaannila;
public
class SpringQuizMaster implements QuizMaster {
@Override
public
String popQuestion() {
return
"Are you new to Spring?";
}
}
We have a QuizMasterService class that displays the
question to the user. TheQuizMasterService class holds reference to
the QuizMaster.
QuizMasterService.java
-----------------------
packagecom.vaannila;
public
class QuizMasterService {
privateQuizMasterquizMaster
= new SpringQuizMaster();
public
void askQuestion()
{
System.out.println(quizMaster.popQuestion());
}
}
Finally we create the QuizProgram class to conduct
quiz.
QuizProgram.java
----------------
packagecom.vaannila;
public
class QuizProgram {
public
static void main(String[] args) {
QuizMasterServicequizMasterService
= new QuizMasterService();
quizMasterService.askQuestion();
}
}
As you can see it is pretty simple, here we create an instance of
the QuizMasterService class and call the askQuestion() method.
When you run the program as expected "Are you new to Spring?"
gets printed in the console.
Let's have a look at the class diagram of this example. The green arrows
indicate generalization and the blue arrows indicates association.
As you can see this architecture is tightly coupled. We create an
instance of the QuizMaster in theQuizMasterService class
in the following way.
privateQuizMasterquizMaster
= new SpringQuizMaster();
To make our quiz master Struts genius we need to make modifications to
the QuizMasterServiceclass like this.
privateQuizMasterquizMaster
= new StrutsQuizMaster();
So it is tightly coupled. Now lets see how we can avoid this by using
the Dependency Injectiondesign pattern. The Spring framework
provides prowerful container to manage the components. The container is based
on the Inversion of Control (IoC) principle and can be implemented by using the
Dependency Injection (DI) design pattern. Here the component only needs to
choose a way to accept the resources and the container will deliver the
resource to the components.
In this example instead of we, directly creating an object of the QuizMaster bean
in theQuizMasterService class, we make use of the container to do this
job for us. Instead of hard coding any values we will allow the container to
inject the required dependancies.
We can inject the dependancies using the setter or constructor
injection. Here we will see how we can do this using the setter injection.
QuizMasterService.java
-----------------------
packagecom.vaannila;
public
class QuizMasterService {
QuizMasterquizMaster;
public
void setQuizMaster(QuizMasterquizMaster) {
this.quizMaster
= quizMaster;
}
public
void askQuestion()
{
System.out.println(quizMaster.popQuestion());
}
}
The value for the QuizMaster will be set using
the setQuizMaster() method. The QuizMaster object is never
instantiated in the QuizMasterService class, but still we
access it. Usually this will throw a NullPointerException, but
here the container will instantiate the object for us, so it works fine.
After making all the changes, the class diagram of the example look like
this.
The container comes into picture and it helps in injecting the
dependancies.
The bean configuration is done in the beans.xml file.
We define each bean using the bean tag. The id attribute
of the bean tag gives a logical name to the bean and the class attribute
represents the actual bean class. The property tag is used to
refer the property of the bean. To inject a bean using the setter injection you
need to use the ref tag.
Here a reference of SpringQuizMaster is injected to
the QuizMaster bean. When we execute this example, "Are
you new to Spring?" gets printed in the console.
To make our QuizMaster ask questions related to Struts,
the only change we need to do is, to change the bean reference in the ref tag.
SimpleJdbcCall class can be used
to call Stored Procedures in spring. ------------------------------------------------------------------------------------------------------ Spring MVC Exception Handling
