Spring:
1. What is IOC (or Dependency Injection)?
The basic concept of the Inversion of Control pattern (also
known as dependency injection) is that you do not create your objects but
describe how they should be created. You don't directly connect your components
and services together in code but describe which services are needed by which
components in a configuration file. A container (in the case of the Spring
framework, the IOC container) is then responsible for hooking it all up.
i.e., Applying IoC, objects are given their dependencies at
creation time by some external entity that coordinates each object in the
system. That is, dependencies are injected into objects. So, IoC means an
inversion of responsibility with regard to how an object obtains references to
collaborating objects.
2. What are the
different types of IOC (dependency injection) ?
There are three types of dependency injection:
Constructor Injection
(e.g. Pico container, Spring etc): Dependencies are provided as constructor
parameters.
Setter Injection
(e.g. Spring): Dependencies are assigned through JavaBeans properties (ex:
setter methods).
Interface Injection (e.g.
Avalon): Injection is done through an interface.
Note: Spring supports only Constructor and Setter Injection
3. What are the
benefits of IOC (Dependency Injection)?
Benefits of IOC (Dependency Injection) are as follows:
Minimizes the amount of code in your application. With IOC
containers you do not care about how services are created and how you get
references to the ones you need. You can also easily add additional services by
adding a new constructor or a setter method with little or no extra
configuration.
Make your application more testable by not requiring any
singletons or JNDI lookup mechanisms in your unit test cases. IOC containers
make unit testing and switching implementations very easy by manually allowing
you to inject your own objects into the object under test.
Loose coupling is promoted with minimal effort and least
intrusive mechanism. The factory design pattern is more intrusive because
components or services need to be requested explicitly whereas in IOC the
dependency is injected into requesting piece of code. Also some containers
promote the design to interfaces not to implementations design concept by
encouraging managed objects to implement a well-defined service interface of
your own.
IOC containers support eager instantiation and lazy loading
of services. Containers also provide support for instantiation of managed
objects, cyclical dependencies, life cycles management, and dependency
resolution between managed objects etc.
4. What is Spring ?
Spring is an open source framework created to address the
complexity of enterprise application development. One of the chief advantages
of the Spring framework is its layered architecture, which allows you to be
selective about which of its components you use while also providing a cohesive
framework for J2EE application development.
5. What are the
advantages of Spring framework?
The advantages of Spring are as follows:
Spring has layered architecture. Use what you need and leave
you don't need now.
Spring Enables POJO Programming. There is no behind the
scene magic here. POJO programming enables continuous integration and
testability.
Dependency Injection and Inversion of Control Simplifies
JDBC
Open source and no vendor lock-in.
6. What are features
of Spring ?
Lightweight:
spring is lightweight when it comes to size and
transparency. The basic version of spring framework is around 1MB. And the
processing overhead is also very negligible.
Inversion of control
(IOC):
Loose coupling is achieved in spring using the technique
Inversion of Control. The objects give their dependencies instead of creating
or looking for dependent objects.
Aspect oriented (AOP):
Spring supports Aspect oriented programming and enables
cohesive development by separating application business logic from system
services.
Container:
Spring contains and manages the life cycle and configuration
of application objects.
MVC Framework:
Spring comes with MVC web application framework, built on
core Spring functionality. This framework is highly configurable via strategy
interfaces, and accommodates multiple view technologies like JSP, Velocity,
Tiles, iText, and POI. But other frameworks can be easily used instead of
Spring MVC Framework.
Transaction
Management:
Spring framework provides a generic abstraction layer for
transaction management. This allowing the developer to add the pluggable
transaction managers, and making it easy to demarcate transactions without
dealing with low-level issues. Spring's transaction support is not tied to J2EE
environments and it can be also used in container less environments.
JDBC Exception
Handling:
The JDBC abstraction layer of the Spring offers a meaningful
exception hierarchy, which simplifies the error handling strategy. Integration
with Hibernate, JDO, and iBATIS: Spring provides best Integration services with
Hibernate, JDO and iBATIS
7. How many modules
are there in Spring? What are they?
Spring comprises of seven modules. They are..
The core container:
The core container provides the essential functionality of
the Spring framework. A primary component of the core container is the
BeanFactory, an implementation of the Factory pattern. The BeanFactory applies
the Inversion of Control (IOC) pattern to separate an application's
configuration and dependency specification from the actual application code.
Spring context:
The Spring context is a configuration file that provides
context information to the Spring framework. The Spring context includes
enterprise services such as JNDI, EJB, e-mail, internalization, validation, and
scheduling functionality.
Spring AOP:
The Spring AOP module integrates aspect-oriented programming
functionality directly into the Spring framework, through its configuration
management feature. As a result you can easily AOP-enable any object managed by
the Spring framework. The Spring AOP module provides transaction management
services for objects in any Spring-based application. With Spring AOP you can
incorporate declarative transaction management into your applications without
relying on EJB components.
Spring DAO:
The Spring JDBC DAO abstraction layer offers a meaningful
exception hierarchy for managing the exception handling and error messages
thrown by different database vendors. The exception hierarchy simplifies error
handling and greatly reduces the amount of exception code you need to write,
such as opening and closing connections. Spring DAO's JDBC-oriented exceptions
comply to its generic DAO exception hierarchy.
Spring ORM:
The Spring framework plugs into several ORM frameworks to
provide its Object Relational tool, including JDO, Hibernate, and iBatis SQL
Maps. All of these comply to Spring's generic transaction and DAO exception
hierarchies.
Spring Web module:
The Web context module builds on top of the application
context module, providing contexts for Web-based applications. As a result, the
Spring framework supports integration with Jakarta Struts. The Web module also
eases the tasks of handling multi-part requests and binding request parameters
to domain objects.
Spring MVC framework:
The Model-View-Controller (MVC) framework is a full-featured
MVC implementation for building Web applications. The MVC framework is highly
configurable via strategy interfaces and accommodates numerous view
technologies including JSP, Velocity, Tiles, iText, and POI.
8. What are the types
of Dependency Injection Spring supports?
Setter Injection:
Setter-based DI is realized by calling setter methods on
your beans after invoking a no-argument constructor or no-argument static
factory method to instantiate your bean.
Constructor
Injection:
Constructor-based DI is realized by invoking a constructor with
a number of arguments, each representing a collaborator.
9. What is Bean
Factory ?
A BeanFactory is like a factory class that contains a
collection of beans. The BeanFactory holds Bean Definitions of multiple beans
within itself and then instantiates the bean whenever asked for by clients.
BeanFactory is able to create associations between
collaborating objects as they are instantiated. This removes the burden of
configuration from bean itself and the beans client.
BeanFactory also takes part in the life cycle of a bean,
making calls to custom initialization and destruction methods.
10. What is
Application Context?
A bean factory is fine to simple applications, but to take
advantage of the full power of the Spring framework, you may want to move up to
Springs more advanced container, the application context. On the surface, an
application context is same as a bean factory.Both load bean definitions, wire
beans together, and dispense beans upon request. But it also provides:
A means for resolving text messages, including support for
internationalization.
A generic way to load file resources.
Events to beans that are registered as listeners.
11. What is the
difference between Bean Factory and Application Context ?
On the surface, an application context is same as a bean
factory. But application context offers much more..
Application contexts provide a means for resolving text
messages, including support for i18n of those messages.
Application contexts provide a generic way to load file
resources, such as images.
Application contexts can publish events to beans that are
registered as listeners.
Certain operations on the container or beans in the
container, which have to be handled in a programmatic fashion with a bean
factory, can be handled declaratively in an application context.
ResourceLoader
support: Spring’s Resource interface us a flexible generic abstraction for
handling low-level resources. An application context itself is a
ResourceLoader, Hence provides an application with access to deployment-specific
Resource instances.
MessageSource support:
The application context implements MessageSource, an interface used to obtain
localized messages, with the actual implementation being pluggable
What are the Core
container module and Application context module?
Core Container Module: This module is the fundamental module
of spring framework. For a spring-based application, BeanFactory is the core.
The Spring framework was developed on top of this module.
What is a BeanFactory
and XMLBeanFactory?
BeanFactory: Bean factory is a container. It configures,
instantiates and manages a set of beans. These beans are collaborated with one
another and have dependencies among themselves.
What is AOP Alliance?
AOP Alliance: AOP Alliance is an open source project.
Promoting adoption of AOP and interoperability among different AOP
implementations with the help of interfaces.
Explain the concepts
and purpose of Spring configuration file.
A spring
configuration file is an XML file which contains the information about classes
and describes the process of configuration.
What does a simple
spring application contain?
A spring application
is like any other Java application. The applications contain classes, each of
them perform a specific task with the application. All these classes are.
Explain Bean
lifecycle in Spring framework.
The bean’s definition
is found by the spring container from the XML file and instantiates the bean.
All the properties specified in the bean definition are populated by spring
using dependency injection.
What is bean wiring?
Bean wiring is the
process of combining beans with Spring container. The required beans are to be
informed to the container.
Explain how to add a
bean in spring application.
The id attribute of
the bean tag specifies the name of the bean and the fully qualified class name
is specified by the class attribute.
What are singleton
beans and how can you create prototype beans?
All beans defined in
the spring framework are singleton beans. The bean tag has an attribute by name
‘singleton’.
What are Inner Beans?
A bean inside another
bean is known as Inner Bean. They are created and used on the fly, and can not
be used outside the enclosing beans.
What is Auto wiring?
What are different types of Autowire types?
Searching for objects
with the same name of object property is called auto wiring in Spring. By
default, Spring framework enables the auto wiring.
What is meant by
Weaving? What are the different points where weaving can be applied?
The process of
applying aspects to a target object for creating a new proxy object is referred
to as weaving. These aspects are woven at the following specified join points.
Explain the different
types of AutoProxying.
BeanNameAutoProxyCreator: This proxy is used
to identify beans to proxy through a list of names. It checks the matches that
are direct, “xxx” and “*xxx”.
What is
DataAccessException?
DataAccessException
is an unchecked RuntimeException. These type of exceptions are unforced by
users to handle.
Explain about
PreparedStatementCreator.
To write data to
database, PreparedStatementCreator is the most commonly used interface. The
interface contains one method by name createPreparedStatement().
Explain about
BatchPreparedStatementSetter.
Updating more than
one row at a time, the BatchPreparedStatementSetter is used. This interface has
setValues() and getBatchSize() exceptions.
Explain about
RowCallbackHandler and why it is used.
ResultSet is
generally used to navigate the records. The spring framework is provided with
RowCallbackHandler interface.
Spring beanfactory :
Heart of spring core
Bean autowiring:
Collection of bean
Spring mvc:
ModelAndView(hello,"msgName",new
String("hihello"))
web.xml---servlet class--->SpringDispatcher
Servlet name---spring
spring xml name====
spring-servlet.xml
Reqeust=/save
Spring life cycle:
init
Destroy
Spring Flow:
1.HttpRequest à Handler Mapping i.e web.xml
Org.springframework.DispatcherServlet
2.àWeb_app_name-servlet.xml
Bean namespace
3.View
4.View
@Controller
Class SpringController{
@RequestMapping(value=/listurl)
Public String method(ModelMap model){
Model.addAttribute(“hello”,”message to be displayed”);
Return “listurl”;
}
MVC Annotation Driven:
RequestMapping, Controller, RequestBody, ResponseBody etc.,
Context Annotation
Driven:
Configured for Autowired, Required etc.,
@PathVariable(“url/{variable}”) – Query Params in the
browser url.
@Autowired
byName, byType, byMethod
byName, byType, byMethod
Autowired can be set to field, constructor
@Autowired(required=false)
private ObjectType objectType;
@Autowired and @Inject
works similar for 100% without any differentiation.These two annotations using
AutowiredAnnotationBeanPostProcessor to inject dependencies. But,@Resource uses
CommonAnnotationBeanPostProcessor to inject dependencies and there is
difference in the order of checking.
@Autowired and @Inject
1.
Matches by Type
2.
Restricts by
Qualifiers
3.
Matches by Name
@Resource
1.
Matches by Name
2.
Matches by Type
3.
Restricts by
Qualifiers (ignored if match is found by name)
-
See more at: http://www.javabeat.net/difference-resource-autowired-inject-spring-injection/#sthash.hpMtkV1k.dpuf
@Required
Can be set true or false while bean configuration
If @Required is not then it will give Bean Initialization
Exception
Ex: @Autowired(required = false | true)
SpringBatch
Spring batch Overview:
Job
JobLauncher
JobParameters
joblauncher.run(job,params)
JobLauncher
JobRepository
Itemreader
Spring-DAO
Spring-DAO is not stricto senso a spring module, but rather conventions that should dictate you to write DAO, and to write them well. As such, it does neither provide interfaces nor implementations nor templates to access your data. When writing a DAO, you should annotate them with
@Repository
so that exceptions linked to the underlying technology (JDBC, Hibernate, JPA, etc.) are consistently translated into the proper DataAccessException
subclass.
As an example, suppose you're now using Hibernate, and your service layer catches
HibernateException
in order to react to it. If you change to JPA, your DAOs interfaces should not change, and the service layer will still compile with blocks that catches HibernateException
, but you will never enter these blocks as your DAOs are now throwing JPA PersistenceException
. By using @Repository
on your DAO, the exceptions linked to the underlying technology are translated to Spring DataAccessException
; your service layer catches these exceptions and if you decide to change the persistence technology, the same Spring DataAccessExceptions
will still be thrown as spring have translated native exceptions.
Note however that this has limited usage for the following reasons:
- Your should usually not catch persistence exceptions, as the provider may have rolled back the transaction (depending on the exact exception subtype), and thus you should not continue the execution with an alternative path.
- The hierarchy of exceptions is usually richer in your provider than what Spring provides, and there's no definitive mapping from one provider to the other. Relying on this is hazardous. This is however a good idea to annotate your DAOs with
@Repository
, as the beans will be automatically added by the scan procedure. Further, Spring may add other useful features to the annotation.
Spring-JDBC
Spring-JDBC provides the JdbcTemplate class, that removes plumbing code and helps you concentrate on the SQL query and parameters. You just need to configure it with a
DataSource
, and you can then write code like this:int nbRows = jdbcTemplate.queryForObject("select count(1) from person", Integer.class);
Person p = jdbcTemplate.queryForObject("select first, last from person where id=?",
rs -> new Person(rs.getString(1), rs.getString(2)),
134561351656L);
Spring-JDBC also provides a JdbcDaoSupport, that you can extend to develop your DAO. It basically defines 2 properties: a DataSource and a JdbcTemplate that both can be used to implement the DAO methods. It also provides an exceptions translator from SQL exceptions to spring DataAccessExceptions.
If you plan to use plain jdbc, this is the module you will need to use.
Spring-ORM
Spring-ORM is an umbrella module that covers many persistence technologies, namely JPA, JDO, Hibernate and iBatis. For each of these technologies, Spring provides integration classes so that each technology can be used following Spring principles of configuration, and smoothly integrates with Spring transaction management.
For each technology, the configuration basically consists in injecting a
DataSource
bean into some kind of SessionFactory
or EntityManagerFactory
etc. bean. For pure JDBC, there's no need for such integration classes (apart from JdbcTemplate), as JDBC only relies on a DataSource.
If you plan to use an ORM like JPA or Hibernate, you will not need spring-jdbc, but only this module.
Spring-Data
Spring-Data is an umbrella project that provides a common API to define how to access data (DAO + annotations) in a more generic way, covering both SQL and NOSQL data sources.
The initial idea is to provide a technology so that the developer writes the interface for a DAO (finder methods) and the entity classes in a technology-agnostic way and, based on configuration only (annotations on DAOs & entities + spring configuration, be it xml- or java-based), decides the implementation technology, be it JPA (SQL) or redis, hadoop, etc. (NOSQL).
If you follow the naming conventions defined by spring for the finder method names, you don't even need to provide the query strings corresponding to finder methods for the most simple cases. For other situations, you have to provide the query string inside annotations on the finder methods.
When the application context is loaded, spring provides proxies for the DAO interfaces, that contain all the boilerplate code related to the data access technology, and invokes the configured queries.
Spring-Data concentrates on non-SQL technologies, but still provides a module for JPA (the only SQL technology).
What's next
Knowing all this, you have now to decide what to pick. The good news here is that you don't need to make a definitive final choice for the technology. This is actually where Spring power resides : as a developer, you concentrate on the business when you write code, and if you do it well, changing the underlying technology is an implementation or configuration detail.
- Define a data model with POJO classes for the entities, and get/set methods to represent the entity attributes and the relationships to other entities. You will certainly need to annotate the entity classes and fields based on the technology, but for now, POJOs are enough to start with. Just concentrate on the business requirements for now.
- Define interfaces for your DAOs. 1 DAO covers exactly 1 entity, but you will certainly not need a DAO for each of them, as you should be able to load additional entities by navigating the relationships. Define the finder methods following strict naming conventions.
- Based on this, someone else can start working on the services layer, with mocks for your DAOs.
- You learn the different persistence technologies (sql, no-sql) to find the best fit for your needs, and choose one of them. Based on this, you annotate the entities and implement the DAOs (or let spring implement them for you if you choose to use spring-data).
- If the business requirements evolve and your data access technology is not sufficient to support it (say, you started with JDBC and a few entities, but now need a richer data model and JPA is a better choice), you will have to change the implementation of your DAOs, add a few annotations on your entities and change the spring configuration (add an EntityManagerFactory definition). The rest of your business code should not see other impacts from your change.
Note : Transaction Management
Spring provides an API for transaction management. If you plan to use spring for the data access, you should also use spring for transaction management, as they integrate together really well. For each data access technology supported by spring, there is a matching transaction manager for local transactions, or you can choose JTA if you need distributed transactions. All of them implement the same API, so that (once again) the technology choice is just a matter a configuration that can be changed without further impact on the business code.
- The Web module provides basic web-oriented integration features such as multipart file-upload functionality and the initialization of the IoC container using servlet listeners and a web-oriented application context.
- The Web-Servlet module contains Spring's model-view-controller (MVC) implementation for web applications.
Difference between spring modules
pring-DAO
Spring-DAO is not stricto senso a spring module, but rather conventions that should dictate you to write DAO, and to write them well. As such, it does neither provide interfaces nor implementations nor templates to access your data. When writing a DAO, you should annotate them with
@Repository
so that exceptions linked to the underlying technology (JDBC, Hibernate, JPA, etc.) are consistently translated into the proper DataAccessException
subclass.
As an example, suppose you're now using Hibernate, and your service layer catches
HibernateException
in order to react to it. If you change to JPA, your DAOs interfaces should not change, and the service layer will still compile with blocks that catches HibernateException
, but you will never enter these blocks as your DAOs are now throwing JPA PersistenceException
. By using @Repository
on your DAO, the exceptions linked to the underlying technology are translated to Spring DataAccessException
; your service layer catches these exceptions and if you decide to change the persistence technology, the same Spring DataAccessExceptions
will still be thrown as spring have translated native exceptions.
Note however that this has limited usage for the following reasons:
- Your should usually not catch persistence exceptions, as the provider may have rolled back the transaction (depending on the exact exception subtype), and thus you should not continue the execution with an alternative path.
- The hierarchy of exceptions is usually richer in your provider than what Spring provides, and there's no definitive mapping from one provider to the other. Relying on this is hazardous. This is however a good idea to annotate your DAOs with
@Repository
, as the beans will be automatically added by the scan procedure. Further, Spring may add other useful features to the annotation.
Spring-JDBC
Spring-JDBC provides the JdbcTemplate class, that removes plumbing code and helps you concentrate on the SQL query and parameters. You just need to configure it with a
DataSource
, and you can then write code like this:int nbRows = jdbcTemplate.queryForObject("select count(1) from person", Integer.class);
Person p = jdbcTemplate.queryForObject("select first, last from person where id=?",
rs -> new Person(rs.getString(1), rs.getString(2)),
134561351656L);
Spring-JDBC also provides a JdbcDaoSupport, that you can extend to develop your DAO. It basically defines 2 properties: a DataSource and a JdbcTemplate that both can be used to implement the DAO methods. It also provides an exceptions translator from SQL exceptions to spring DataAccessExceptions.
If you plan to use plain jdbc, this is the module you will need to use.
Spring-ORM
Spring-ORM is an umbrella module that covers many persistence technologies, namely JPA, JDO, Hibernate and iBatis. For each of these technologies, Spring provides integration classes so that each technology can be used following Spring principles of configuration, and smoothly integrates with Spring transaction management.
For each technology, the configuration basically consists in injecting a
DataSource
bean into some kind of SessionFactory
or EntityManagerFactory
etc. bean. For pure JDBC, there's no need for such integration classes (apart from JdbcTemplate), as JDBC only relies on a DataSource.
If you plan to use an ORM like JPA or Hibernate, you will not need spring-jdbc, but only this module.
Spring-Data
Spring-Data is an umbrella project that provides a common API to define how to access data (DAO + annotations) in a more generic way, covering both SQL and NOSQL data sources.
The initial idea is to provide a technology so that the developer writes the interface for a DAO (finder methods) and the entity classes in a technology-agnostic way and, based on configuration only (annotations on DAOs & entities + spring configuration, be it xml- or java-based), decides the implementation technology, be it JPA (SQL) or redis, hadoop, etc. (NOSQL).
If you follow the naming conventions defined by spring for the finder method names, you don't even need to provide the query strings corresponding to finder methods for the most simple cases. For other situations, you have to provide the query string inside annotations on the finder methods.
When the application context is loaded, spring provides proxies for the DAO interfaces, that contain all the boilerplate code related to the data access technology, and invokes the configured queries.
Spring-Data concentrates on non-SQL technologies, but still provides a module for JPA (the only SQL technology).
What's next
Knowing all this, you have now to decide what to pick. The good news here is that you don't need to make a definitive final choice for the technology. This is actually where Spring power resides : as a developer, you concentrate on the business when you write code, and if you do it well, changing the underlying technology is an implementation or configuration detail.
- Define a data model with POJO classes for the entities, and get/set methods to represent the entity attributes and the relationships to other entities. You will certainly need to annotate the entity classes and fields based on the technology, but for now, POJOs are enough to start with. Just concentrate on the business requirements for now.
- Define interfaces for your DAOs. 1 DAO covers exactly 1 entity, but you will certainly not need a DAO for each of them, as you should be able to load additional entities by navigating the relationships. Define the finder methods following strict naming conventions.
- Based on this, someone else can start working on the services layer, with mocks for your DAOs.
- You learn the different persistence technologies (sql, no-sql) to find the best fit for your needs, and choose one of them. Based on this, you annotate the entities and implement the DAOs (or let spring implement them for you if you choose to use spring-data).
- If the business requirements evolve and your data access technology is not sufficient to support it (say, you started with JDBC and a few entities, but now need a richer data model and JPA is a better choice), you will have to change the implementation of your DAOs, add a few annotations on your entities and change the spring configuration (add an EntityManagerFactory definition). The rest of your business code should not see other impacts from your change.
Note : Transaction Management
Spring provides an API for transaction management. If you plan to use spring for the data access, you should also use spring for transaction management, as they integrate together really well. For each data access technology supported by spring, there is a matching transaction manager for local transactions, or you can choose JTA if you need distributed transactions. All of them implement the same API, so that (once again) the technology choice is just a matter a configuration that can be changed without further impact on the business code.
SpringBatch
Spring batch Overview:
Job
JobLauncher
JobParameters
joblauncher.run(job,params)
JobLauncher
JobRepository
Itemreader
Itemwriter
It represents the name of the item reader bean. It accepts the value of the type org.springframework.batch.item.ItemWriter.
Itemprocessor
It represents the name of the item reader bean. It accepts the value of the type org.springframework.batch.item.ItemProcessor.
commit-interval
It is used to specify the number of items to be processed before committing the transaction.
processor = "itemProcessor" commit-interval = "10">
MongoItemReader To read data from MongoDB.
FlatFIleItemReader To read data from flat files.
JDBCPagingItemReader To read data from relational databases database.
MongoItemWriter To write data into MongoDB.
To run the application, we need to use @SpringBootApplication annotation. Behind the scenes, that’s equivalent to @Configuration, @EnableAutoConfiguration, and @ComponentScan together.
@Reposoitory- used to handle unchecked SQL Exception called DataAccessException
Spring ResponseBody:
---------------------
if you put @ResponseBody annotation in the method level, Spring will convert the return object in to the http response body.
ResponseEntity
---------------
ResponseEntity works similar as @ResponseBody annotation. But when you create ResponseEntity object, you can add the response header to the http response as well.
Spring Life cycle
Initializing Bean
Disposable Bean
No comments:
Post a Comment