Taking as reference the post Spring #Autowired and #Qualifier
We have this example to fix the autowiring conflict :
public interface Vehicle {
public void start();
public void stop();
}
There are two beans, Car and Bike implements Vehicle interface.
#Component(value="car")
public class Car implements Vehicle {
#Override
public void start() {
System.out.println("Car started");
}
#Override
public void stop() {
System.out.println("Car stopped");
}
}
#Component(value="bike")
public class Bike implements Vehicle {
#Override
public void start() {
System.out.println("Bike started");
}
#Override
public void stop() {
System.out.println("Bike stopped");
}
}
#Component
public class VehicleService {
#Autowired
#Qualifier("bike")
private Vehicle vehicle;
public void service() {
vehicle.start();
vehicle.stop();
}
}
That's a very good example to fix this problem.
But when I have the same problem but without those balises in the application context:
<context:component-scan></context:component-scan>
<context:annotation-config></context:annotation-config>
All the issues are solved by using the #Qualifier annotation, but in my case we don't use the balise that permit to use annotation.
The question is :
How can I fix this issue just using the configuration in application context, that's it, without using annotations?
I searched a lot and I found people talking about autowire attribute in the bean declaration <bean id="dao" class="package.IDao" autowire="byName"></bean> and I need more explanation about it.
How can I fix this issue just using the configuration in application
context?
You could use the qualifier tag like below (see https://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/beans.html#beans-autowired-annotation-qualifiers)
<context:annotation-config/>
<beans>
<bean class="your_pkg_route.Vehicle">
<qualifier value="bike"/>
</bean>
</beans>
</context:annotation-config>
I found people talking about autowire attribute in the bean
declaration and I need more explanation about it
Using Annotation
#Autowired used on a bean declaration method injects the defined dependencies by (another) declared beans. Now, if your dependencies are in the same context of your application, you don't need to use the #Autowired annotation at all because Spring is able to figure them out by itself. So, if your dependencies are outside your applicatoin context then you can use it.
For example, take as reference the below code:
#Autowired
#Bean
public MyBean getMybean(Dependency1 depdency1, Dependency2 depdency2) {
return new MyBean(depdency1.getSomeStuff(), depdency2.getSomeOtherStuff());
}
Here, #Autowired will find an instance of Dependency1 and Dependency2 and will provide them for the creation of an instance of MyBean.
Using xml configuration
From Pro Spring 5... Spring supports five modes for autowiring.
byName: When using byName autowiring, Spring attempts to wire each property to a bean of the same name. So, if the target bean has a property named foo and a foo bean is defined in ApplicationContext, the foo bean is assigned to the foo property of the target.
byType: When using byType autowiring, Spring attempts to wire each of the
properties on the target bean by automatically using a bean of the same type in
ApplicationContext.
constructor: This functions just like byType wiring, except that it uses constructors rather than setters to perform the injection. Spring attempts to match the greatest numbers of arguments it can in the constructor. So, if your bean has two constructors, one that accepts a String and one that accepts String and an Integer, and you have both a String and an Integer bean in your ApplicationContext, Spring uses the two-argument constructor.
default: Spring will choose between the constructor and byType modes
automatically. If your bean has a default (no-arguments) constructor, Spring uses
byType; otherwise, it uses constructor.
no: This is the default
So, in your case you would need to do something like this (BUT, I would NOT recommend it. Why?, you would need to declare Vehicle class as a bean and a component which is not correct, see Spring: #Component versus #Bean. On the other hand I'm not sure if you could use it just declaring it as a bean):
// xml config
<context:annotation-config/>
<beans>
// use the primary tag here too! in order to say this the primary bean
// this only works when there are only two implementations of the same interface
<bean id="bike" primary="true" class="your_pkg_route.Bike"/>
<bean id="car" class="your_pkg_route.Car"/>
<bean autowire="byName" class="your_pkg_route.VehicleService"/>
<beans>
</context:annotation-config>
// VehicleService
#Component
public class VehicleService {
private Vehicle bike; // call attribute 'bike' so it is autowired by its name
public void service() {
//...
}
}
As you can see there is a lot of complications trying to do this using xml config, so I would recommend you to use the annotation option if possible.
Related posts:
Why do I not need #Autowired on #Bean methods in a Spring configuration class?
Difference between #Bean and #Autowired
PS: I have not tested any of the posted codes.
You can use #Primary instead of #Qualifier
#Primary
#Component(value="bike")
public class Bike implements Vehicle {
we use #Primary to give higher preference to a bean when there are multiple beans of the same type.
We can use #Primary directly on the beans
You can also set primary attribute in XML:
property has primary attribute:
<bean primary="true|false"/>
If a #Primary-annotated class is declared via XML, #Primary annotation metadata is ignored, and is respected instead.
Related
What is the programatic equivalane to defining a bean like this in xml:
<bean id="foo" class="com.bizz.Foo" />
Ideally I would like to be able to have spring create that bean, without using XML and without calling new and for this to happen within a #Configuration type class. For example:
#Configuration
public ConfigBar {
#Bean
public com.bizz.Foo foo() {
return /* Programmatic equivalent of <bean id="foo" class="com.bizz.Foo" /> here*/;
}
}
I don't think new Foo() is equivalent:
as spring is able to pick which constructor to use which may not be the no args constructor.
and spring is able to inject dependencies, which I don't think will be done here.
I know that spring is doing some reflection to achieve this, however simply stating that is not the answer to this question.
so how can we let spring create the Foo bean programmatically letting spring inject dependencies, pick the constructor and perhaps other tasks that spring would normally do when defined in XML?
The equivalent is #Component or any variant thereof such as #Controller or #Service. So long as your bean is in a package included in the component scan Spring will be able to find your bean at runtime and inject it into other beans.
As an example:
#Component
public class Foo {
//...
}
#Service
public class Bar {
// Spring will find and inject Foo bean creating it if necessary when
// creating the Bar "service" bean
#Autowired
private Foo foo;
//...
}
I have worked it out:
#Bean
#Autowired
public Foo foo(AutowireCapableBeanFactory autowireCapableBeanFactory) {
return autowireCapableBeanFactory.createBean(Foo.class);
}
I have a hobby-project which I would like to migrate to Spring.
As an example I have the following classes:
public class OtherBean {
public void printMessage() {
System.out.println("Message from OtherBean");
}
}
public class InjectInMe {
#Inject OtherBean otherBean;
public void callMethodInOtherBean() {
otherBean.printMessage();
}
}
However as I read the documentation, I must annotate all classes to be managed by Spring with an annotation like #Component (or others that are similar).
Running it with the following code:
public class SpringTest {
public static void main(String[] args) {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
context.refresh();
InjectInMe bean = context.getBean(InjectInMe.class);
bean.callMethodInOtherBean();
}
}
Gives me the error:
Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [somepackage.InjectInMe] is defined
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:371)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:331)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:968)
at somepackage.SpringTest.main(SpringTest.java:10)
My question is: is there a way to make Spring manage any class I ask the ApplicationContext to instantiate without me having to register them in an Annotated Config (or XML config)?
In Guice I can just inject into the class
public class GuiceTest {
static public class GuiceConfig extends AbstractModule {
#Override
protected void configure() {}
}
public static void main(String[] args) {
Injector injector = Guice.createInjector(new GuiceConfig());
InjectInMe bean = injector.getInstance(InjectInMe.class);
bean.callMethodInOtherBean();
}
}
Gives me the output:
Message from OtherBean
Is there anyway I can make Spring work like Guice? As in make Spring inject my beans without me having to register or scan packages for classes annotated with #Component-like annotations?
Any Spring gurus have a way to solve this problem?
My question is: is there a way to make Spring manage any class I ask
the ApplicationContext to instantiate without me having to register
them in an Annotated Config (or XML config)?
No, it's not possible. This is simply not how Spring is designed. You must either implicitly (e.g. scan + annotation) or explicitly (e.g. XML bean definition) register your beans.
The least you can do is something like:
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
context.register(OtherBean.class);
context.register(InjectInMe.class);
context.refresh();
There are a few ways to provide bean definitions for Spring's ApplicationContext:
Use component scanning and annotate your types with #Component or one of its meta annotations (#Service, #Controller, etc.)
Define a <bean> in XML configuration or a #Bean in Java configuration (or whatever other type of explicit configuration).
Use a BeanDefinitionRegistryPostProcessor to register beans directly on a BeanDefinitionRegistry.
Some ApplicationContext subtypes implement BeanDefinitionRegistry, so you can register bean definitions with them directly.
The beans generated from these bean definitions will be available when injection is required. You wouldn't want (at least IMO) your container to instantiate a type without you telling it somehow that it is OK.
You must either declare the class as a #Component, or whatever it may be, or you must provide an xml definition. If you don't define the bean, how is Spring supposed to know what to do? For the properties of a class, e.g. MyController has a private service MyService. If you put the #Autowired tag above the service instantiation, Spring will automatically inject this server into your controller, which is what your comment about #Inject seems to hint at. However, in order to autowire, you must define a bean for that class, which means you must use either the #Component/#Controller, etc annotation configuration or an xml bean configuration.
I would like to autowire a component (still using the #Autowired annotation), but not require it to have the #Component (or other similar annotations) on it. How would I do this?
public class A {
#Autowired
private class B b;
}
#Component
public class B {
}
This would be convenient in order to allow autowiring of class A without requiring the creation of A, unless we needed it (in otherwise on the fly by reflection using the class name).
Injection and autowiring do not require #Component. They require beans. #Component states that the annotated type should have a bean generated for it. You can define beans in other ways: with a <bean> declaration in an XML context configuration, with a #Bean method in a #Configuration class, etc.
Your last sentence doesn't make much sense. You can't process injection targets in a bean without creating a bean. You also can't inject a bean without creating it. (Applied to scopes, bean may refer to the target source/proxy and not the actual instance.) Perhaps you want #Lazy.
I don't sure, If I correctly understood to your question. But if you want inject bean B without marking bean A via some annotation, or xml definition, you can use SpringBeanAutowiringSupport
public class A {
#Autowired
private class B b;
public A{
SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext(this);
}
}
I found the following unorthodox configuration in my code base the other day and it made me wonder. What is the expected Spring Context behavior when I use an interface name also as the name of a bean? Would it make a difference if I was using #Autowiring in my Controller? The following snippet illustrates this setup:
interface MyAppService {...}
class InfrastructureService implements MyAppService {...}
class AdministrationService implements MyAppService {...}
class InfrastructureController {
// some code
public void setMyAppService(MyAppService svc){...}
}
<bean id="myAppService" class="InfrastructureService"/>
<bean id="administrationService" class="AdministrationService"/>
<bean id="infrastructureController" class="InfrastructureController">
<property name="myAppService" ref="myAppService"/>
</bean>
Alternatively, what would be the expected behaviour if only the controller was defined as:
class InfrastructureController {
#Autowired
public void setMyAppService(MyAppService svc){...}
}
Why should it matter here? You reference beans by id in the xml, not by interface type.
<property name="myAppService" ref="myAppService"/>
This means that the property named myAppService will have the bean with id myAppService injected. Nothing about interfaces.
Edit: If you use autowiring with annotations and you have many different implementations of the same interface registered as components, then you have to use qualifiers to tell Spring which implementation you gonna use. If you have only one implementation registered, no action is needed.
If you put #AutoWired alone it search dependency by Type (In your case it is MyAppService).If you want to narrow down dependecy seaching you can use #Qualifier as below :
class InfrastructureController {
#Autowired
#Qualifier("NAME_OF_BEAN")
public void setMyAppService(MyAppService svc){...}
}
I'm using annotations-based wiring (ie #Configurable(autowire=Autowire.BY_TYPE)) for a given class, and I'd like to wire all beans of a given type into it as a list:
application context:
<beans>
<bean class="com.my.class.FirstConfigurer"/>
<bean class="com.my.class.SecondConfigurer"/>
</beans>
class to autowire into:
#Configurable(autowire=Autowire.BY_TYPE) public class Target {
...
public void setConfigurers(List<Configurer> configurers) { ... }
}
All dependencies implement a common interface called Configurer
Is there a way to make this work to have all dependencies of a type wired together in a collection and injected where necessary, or should I define a <list> in XML or something?
Yes,
#Inject
private List<Configurer> configurers;
works, and you get a list of all beans implementing the interface. (multiple variations - #Inject or #Autowired, field, setter or constructor injection - all work)
This should work:
#Configurable(autowire=Autowire.BY_TYPE)
public class Target {
#Autowired
public void setConfigurers(List<Configurer> configurers) { ... }
}
This is described in section 3.9.2 of the Spring manual:
It is also possible to provide all beans of a particular type from the ApplicationContext by adding the annotation to a field or method that expects an array of that type [...] The same applies for typed collections.