I'm using Spring Boot and trying use Spring integration (because I want to use its SFTP client). But I got the following error:
Description:
Parameter 0 of constructor in com.example.demo.service.ServiceOne required a single bean, but 2 were found:
- applicationTaskExecutor: defined by method 'applicationTaskExecutor' in class path resource [org/springframework/boot/autoconfigure/task/TaskExecutionAutoConfiguration.class]
- taskScheduler: defined in null
Action:
Consider marking one of the beans as #Primary, updating the consumer to accept multiple beans, or using #Qualifier to identify the bean that should be consumed
I'm sure that the error happens after adding dependencies for spring-integration. I've tried to use #Qualifier("applicationTaskExecutor") and creating a bean with #Primary annotation but still unable to run the application. How to fix it?
As error stated there are two TaskExecutor beans in the application context.
One is auto-configured by the TaskExecutionAutoConfiguration and another by Spring Integration for its pollers features which is essentially a TaskScheduler.
What the error description suggest is to use a #Qualifier("applicationTaskExecutor") on the ServiceOne 's Parameter 0 of constructor. You don't need to have #Primary bean because the story is about beans created outside of your code.
Related
I am new to springboot.
Doing a migration of my service (kotlin)following a guide written at work.
Got this weird exception and cannot find any documentation.
Parameter 3 of method multipleOpenApiResource in org.springdoc.webflux.core.MultipleOpenApiSupportConfiguration required a bean of type 'org.springdoc.core.GenericResponseService' that could not be found.
Action:
Consider defining a bean of type 'org.springdoc.core.GenericResponseService' in your configuration.
Should I define this bean at my #Configuration?
Is this a symptom of dependency missing or bad dependency wiring?
One of my beans was called ResponseBuilder and it conflicted with spring boot.
Sorry for the trouble
In my sample spring boot application, i have added a dependency of a custom jar. My sample application has a support for web and jpa.
The jar which i've created contains a Spring MVC controller. Below is the sample code
#Controller
public class StartStopDefaultMessageListenerContainerController {
#Autowired(required=false)
private Map<String, DefaultMessageListenerContainer> messageListeners;
I haven't manually created a bean instance of this controller anywhere in my code.
Problem - When i start my spring boot application by running the main class, i get an error in console that prob while autowiring DefaultMessageListenerContainer.
My question here is, even though this class StartStopDefaultMessageListenerContainerController is just present in the classpath, it's bean shouldn't be created and autowiring should not happen. But spring boot is scanning the class automatically and then it tries to autowire the fields.
Is this the normal behavior of spring and is there anyway i can avoid this?
If the StartStopDefaultMessageListenerContainerController class is part of component scanning by spring container, Yes spring tries to instantiate and resolve all dependencies.
Here your problem is #Autowired on collection. Spring docs says,
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.
And also Refer inject-empty-map-via-spring
I'm having 1 #Controller bean in my project
and 2 #Service beans that this controller calls.
the services using 2 different #Repository beans for persisting.
My question is :
my server is about to get hundreds of calls simultaniously, isnt it "awkward" that all my beans i described above are of scope="singleton"? should i use "prototype" instead? or maybe spring does it automatically ?
I think in both cases you wil have the same number of objects.
The non-singleton, prototype scope of bean deployment results in the
creation of a new bean instance every time a request for that specific
bean is made (that is, it is injected into another bean or it is
requested via a programmatic getBean() method call on the
container). As a rule of thumb, you should use the prototype scope
for all beans that are stateful, while the singleton scope should be
used for stateless beans.
in Spring by default all beans it is "singleton" and should be in most cases.
In XML file in spring we have two bean with different id but same class. They have the same properties offcourse. Now I have InitializingBean interface and in afterPropertySet() I am just printing the value of properties.
Its printing the values two times for me?
According Spring Documentation:
afterPropertySet()
Invoked by a BeanFactory after it has set all bean properties supplied (and satisfied BeanFactoryAware and ApplicationContextAware).
So the short answer on your question is: yes
Spring doesn't manipulate classes or object. Spring manipulates Bean Entity. It is the simplest object manipulated by Spring IOC. Bean has additional behaivior rules introduced by Spring.
If you create two beans for example with Singleton scope and not Lazy initializated Spring creates two instances of your class.
Probably you are calling this Class also invoking a Test or by launching a Integration test like this . check the breakpoints , if you are using SpringRunner, try to mock the component
I am using a #configurable annotated Vaadin controller together with my Spring context, and it is working fine - except when I need to restart Tomcat, and the sessions are deserialized. Then I get this for my Vaadin app:
org.springframework.beans.factory.wiring.BeanConfigurerSupport BeanFactory has not been set on BeanConfigurerSupport: Make sure this configurer runs in a Spring container. Unable to configure bean of type [web.vaadin.ui.BackOfficeApplication]. Proceeding without injection.
I am thinking that this can be because the vaadin app is reserializing before the spring bean factory has a chance to?
(I am using CTW - aspectj and Spring 3.1.1.RELEASE)
Note:
It seems in the log that these errors come before the "Root WebApplicationContext: initialization started". How can it be that the beans are being autowired before the context initialization is started?
I am not an expert on (de)serialization with Spring and Tomcat, and this is not an answer but might be a workaround.
If BackOfficeApplication is your Vaadin application then there is an alternative to using #Configurable on that class. Instead, create a per-Vaadin Application Spring application context XML file and add this to it to cause your BackOfficeApplication instances to be autowired, etc.:
<bean id="backOfficeApplication"
class="org.dellroad.stuff.vaadin.ContextApplication"
factory-method="get"/>
In general, #Configurable can be more troublesome than normal bean wiring because they require the configuration to occur at object construction rather than allowing the bean factory to do the wiring later on, where it may be better able to detect loops, enforce ordering, etc.
Ideally normal bean wiring should be used for singletons that are initialized once at the beginning of the application and #Configurable should be used for "on the fly" beans created randomly during normal operation.