I want to understand what is the exact meaning of term "autowiring" and AOP in Spring Framework.
From the official Spring Framework Reference:
The Spring container can autowire relationships between collaborating
beans. You can allow Spring to resolve collaborators (other beans)
automatically for your bean by inspecting the contents of the
ApplicationContext.
Which basically means you can leave it up to the Spring Framework to initialize your beans and ensure they're there when you need them. For example, lets say I have a number of Things in my app. Now, if I want to get all the Things and have them placed in a List<Thing>, in Spring (assuming I've configured it properly), I can simply use this code:
#Autowired
private List<Thing> things;
With no additional effort on my part I have the list I needed.
The question concerning Aspect Oriented Programming (AOP) as it relates to Spring would be quite a bit to put in a post. The simple explanation can be seen in the official Spring Framework Reference:
Aspect-Oriented Programming (AOP) complements Object-Oriented
Programming (OOP) by providing another way of thinking about program
structure. The key unit of modularity in OOP is the class, whereas in
AOP the unit of modularity is the aspect. Aspects enable the
modularization of concerns such as transaction management that cut
across multiple types and objects. (Such concerns are often termed
crosscutting concerns in AOP literature.)
One of the key components of Spring is the AOP framework. While the
Spring IoC container does not depend on AOP, meaning you do not need
to use AOP if you don’t want to, AOP complements Spring IoC to provide
a very capable middleware solution.
That section is very detailed and worth a read if you're interested in AOP.
Autowiring is a mechanism of resolving dependencies in Spring IoC container, as per Spring Reference. So instead of directly specifying the dependency (in XML or in Java configuration), you can depend on container itself to provide you with candidate(s). Spring itself should abort if you find more than one matching dependency (unless you are looking for a collection of beans).
Related
I am learning AOP and came to know that is useful for separation of concern, for example, logging, transaction management, security etc.
So far good to know AOP.
Now, I read about Spring transaction management in Spring framework we can have annotation #Transactional.
It is this point which is make me confused why should we use AOP in which we have to create Aspects rather than using the annotation which Spring provides.
For example:
#Transactional
public void dataAccessTrans() {
}
When Spring is already having transaction related functionality, then why should we use AOP to do transaction management?
If we use AOP, then don't we have to create Aspect and create advice which would act on the method; does't this make us to do manual work, rather than handling it by spring framework itself by its own annotations.
Can anyone help me understand this which I am not able to understand clearly.
Spring relies on AOP to implement declarative transactions.
The Spring Framework’s declarative transaction management is made
possible with Spring aspect-oriented programming (AOP), although, as
the transactional aspects code comes with the Spring Framework
distribution and may be used in a boilerplate fashion, AOP concepts do
not generally have to be understood to make effective use of this
code.
So as you use the #Transactional annotation :
#Transactional
public void dataAccessTrans() {
...
}
you use indirectly AOP.
So in the very most of cases, you never need to declare any custom aspects to handle the transaction management.
I am implementing a REST service from scratch. I am using Spring + ibatis for the same.
Now, spring offers REST support using annotations. However, online, I find many tutorials to integrate Jersey with Spring.
My question: Why would one want to introduce extra dependencies by including another framework, that is Jersey JAX-RS, when Spring itself is good?
You assume that there's a problem with introducing "another" dependency, which, unless you're developing for some tiny embedded system, there isn't. The added memory footprint, complexity etc would generally be irrelevant.
The decision to use Spring or Jersey for RESTv implementation should be one of personal preference and suitability. Pick the one that satisfies your requirements and you're most comfortable with.
Also, using Spring for REST will require additional dependencies itself. If you're only using Spring for dependency injection, you won't require spring-web or spring-webmvc, whereas these will be required for REST.
Hope this helps
EJB 3.0 comes with the concept of Interceptors, but then again they are applicable to EJBs only. My project requires developing Interceptors for POJO classes. One option for this is to use Spring AOP. I want to know if it's worth the overhead of including the libraries such as commons-logging, spring-aop, cglib that are required for Spring AOP.
Spring is much more than Spring AOP, and you can not use Spring AOP without Spring, and I am talking not only to the Spring libs, but to the Spring programming model too!
So if you think Spring is useful for your application (believe me, it is very useful to many application), then you can use it. - But it is a complete programming model, like EJB, not only a lib or a simple framework.
But I think every modern not trivial application should have a ICO container, so Spring is one of the choices you have.
Sure, it's worth, but be aware it won't be enough if you need to have interceptors for you POJOs : You will also need a "spring agent" to be passed as an argument to your jvm ("Load-Time Weaving"), or you won't be able to intercept your pojos methods, or you will have to use "Compile-Time Weaving".
In short : POJOs have to be created via Spring for them to be "interceptable".
CTW (or LTW) makes compilation (or startup) quite slower.
I was reading a Wikipedia article about Java EE application servers here:
http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Java_EE_5_certified
It says that 2 APIs that Java App Services implement are:
javax.enterprise.inject
javax.enterprise.context
These both relate to application context and dependency injection JSR-299. I had never heard of these APIs before. Does Spring implement these APIs? Would it matter to anyone if they did?
JSR-330 defines a set of annotations (javax.inject) that are to be used across different dependency injection frameworks. The specification was lead by Rod Johnson (from Spring), and Bob Lea from (Google Guice)
(partly) because of the spec leads, spring and guice support this set of annotations
This is the part of JavaEE that is used by spring.
The same set is used by JSR-299, which is lead by Gavin King from JBoss. However, JSR-299 (also known as CDI) uses javax.enterprise.inejct/context and is a whole new dependency-injection framework. It is based on ideas of spring, guice and seam, but is specified formally as a JSR and aims at covering many corner cases as well as smooth integration with other JavaEE parts.
JSR-299 defines both an API and SPI so that concrete implementations can be developed. Current implementations are JBoss Weld, Apache OpenWebBeans and Resin CanDI.
So, to answer your question - there is no direct relation between javax.enterprise.inject and spring.
Spring does support JSR-330's #Inject - it can be used in place of #Autowired (except that it doesn't have a required property).
You also need to have the JSR 330 jar on the classpath.
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-autowired-annotation
Is implementing the Abstract Factory pattern for a spring-based project with AOP should be any different than in a normal project?
It should be simpler, all things considered; technically, Spring acts like an Abstract Factory itself, and that pattern deeply informs most things that Spring "wants" you to do with it.
Without a more concrete example, I'd have to say "no". Spring AOP is pretty good at working around your code, whatever structure it's in.
Depends on your AOP. If you're using AspectJ with load time or compile time weaving, then you don't have an issue. If you're using the spring based AOP, then you have an issue because spring will only put aspects onto beans it creates. Meaning that if your factory makes the bean, it won't have any AOP instrumentation