In spring why the interface is injected rather than the class implementing the interface?
In fact even if you use interface a class is injected. Spring looks for a bean - class which implements the interface.
In some cases like e.g. Spring Data dynamic proxy is created for the interfaces which in fact a class to listen interface's methods calls and do some logic on the calls.
If you set a breakpoint and check what is really injected you will find a class (either your class or some Proxy object)
Related
I think I have a good idea of how spring uses proxy concept with #Transactional annotation but I can't find anything about "default" implementation. Basically what I'm looking for is the code which wraps the invocation of original method (method from wrapped object).
There is no such thing as a default implementation because it all depends on the class implementing the method where you add the #Transactional annotation to.
If that class inherits from an interface then JDK Dynamic Proxy will be used.
If not, then an external library called CGLIB will be used to create the proxy.
Dynamic proxy will create a proxy that implements all interfaces your target class also implements while CGLIB will create a proxy that extends your target class.
Also make sure to read this SO question concerning the difference between Dynamic Proxy and CGLIB proxy as it contains valuable information as well.
i am new to spring
in my spring web project DAO and service they created the interface and implementing it created class. can we liminate interface.
The whole point of using interface is to create abstraction. When you call you DAO from Service, your service is not aware of the actual implementation of DAO/ cases in which you have multiple implementations of your DAO interface, your service is not aware of the actual impl being used.
With spring you will use - Autowire to inject the dependency. You will refer your Dependency using interface.
#Component/#Service
class ServiceImpl {
#Autowired
private DAOInterface dao;
// Rest of code
}
Spring knows - to create the instance of this ServiceImpl it needs to inject a concrete impl of DAOInterface type. In case you have concrete implementation, it does so. In case you have multiple impls - you need to define by bean name which implementation you need using #Qualifier.
Interface is kind of a contract for your impl classes. Other than abstracting the actual impl, it helps you decoupling the layers by not directly having a dependency on the concrete classes. This is a good design pattern
I noticed multiple ways in which developers create an Apache Felix Service. Each of the attached snippets seem to work. Would need some help to understand, which syntax is best for which scenario
Sample 1: Service created without interface
Declaration of Service
D
#Component
#Service(ServiceViaClass.class)
public class ServiceViaClass{
}
Using service via #Reference annotation
private ServiceViaClass serviceViaClass;
Sample 2:Service implementing interface. No value attribute for #Service annotation
- Declaration of Service
#Component
#Service
public class ServiceViaInterfaceImpl implements ServiceViaInterface{
}
Using service via #Reference annotation
private ServiceViaInterface serviceViaInterface;
Sample 3: Service implementing interface with value attribute for #Service annotation
- Declaration of Service
#Component
#Service(ServiceViaInterface.class)
public class ServiceViaInterfaceImpl implements ServiceViaInterface{
}
Using service via #Reference annotation
private ServiceViaInterface serviceViaInterface;
A component implements an interface and publishes itself as a service under that interface, so that clients can find the component using only the interface.
Sample 1 — publishing a service using the concrete type of the component — is nearly always useless. The service can only be found using the concrete type, and if clients can see the concrete type then why not just instantiate it directly rather than get an instance from the service registry??
Sample 2 — publishing a service by implementing an interface and then just adding the #Service annotation — is what you should usually do. When you use #Service and the component directly implements an interface, the build tooling infers that your component wants to be published as a service under that interface.
Sample 3 has the exact same effect at runtime as sample 2, it's just a bit more explicit in the code. Some people prefer this because it's explicit, others (including me) dislike it because it is redundant.
I can not find any reason why every autowired bean are not autowired by proxy. I know that becasue #Transactional annotations do not work and I checked autowired component during debugging in eclipse. Of course every component implements some interface and I use #Autowired annotations in relation to the interface.
I have only one configuration of aop:
<tx:annotation-driven transaction-manager="transactionManager" />
I use JPA with hibernate, spring-mvc,spring-webflow, spring-security and spring-data. Interfaces which extends org.springframework.data.repository.CrudRepository are autowired by proxy. But my components are not. For example I have class MyClass which implement MyInterface:
#Service
public class MyClass implements MyInterface {
#Autowired
MyCrudReposiotry reposiotry;
....
}
If I autowire MyInterface somewhere:
#Autowired
MyInterface mi;
then mi is just reference to MyClass object, repository is refrence to proxy org.springframework.aop.framework.JdkDynamicAopProxy. Very interesting is that in testing mi is reference to proxy. My test's context does not contain web-flow and mvc configuration.
Maybe there is some indirect aop configuration which I should check. What can switch the autowiring by proxy off?
My guess is that you are scanning for the same components twice. You probably have a in your root context (for the ContextLoaderListener) and one for the DispatcherServlet. NO if the both scan for the same classes you end up with duplicated (and one proxied and one non proxied instance).
Proxying and auto wiring are independent of each other. When you use #AutoWired it finds another bean that implements the required interface and injects it. The bean instance it finds might be a normal object or a proxy - it doesn't matter to Autowired.
Proxies are created for certain beans automatically by spring. As you have noticed one scenario in which this happens is when you use #Transactional. When the spring container instantiates a bean which has the #Transactional annotation the object gets wrapped in a proxy. The actual object is replaced by the proxy in the context. This is done so that spring can intercept calls to those methods and add the begin / commit transaction calls before and after the method call. This is implemented by the spring-aop module. Any feature that relies on AOP (#Transactional, #Secured) will result in creation of a proxy.
The other case where proxies are used is to create an implementation on the fly. In case of the CRUDRepository you are required to only implement the interface. The implementation of that is created on the fly using the same proxy infrastructure.
I am reading the Spring Hibernate CRUD tutorial from this url
http://viralpatel.net/blogs/spring3-mvc-hibernate-maven-tutorial-eclipse-example/
Please can anyone tell me why in ContactController.java, ContactService interface is autowired instead of the class ContactServiceImpl.
Similarly in ContactServiceImpl ContactDAO interface is injected. Shouldn't we supposed to inject class instead of an interface?
When your code is dependent on interface and its implementation is injected by Spring, your code becomes decoupled with the implementation. This has an advantage that now you can swap in a different implementation without having to change the code that makes use of interface.
Spring is smart. It will find the implementation of the interface and inject it appropriately (or a proxy thereof.)
You should be programming to interfaces, not implementations.