I am getting an error while trying to up my application
Description:
Field conversionService in com.profectus.dashboard.service.impl.DashBoardSettingsServiceimpl required a single bean, but 2 were found:
- mvcConversionService: defined by method 'mvcConversionService' in class path resource [org/springframework/web/servlet/config/annotation/DelegatingWebMvcConfiguration.class]
- defaultConversionService: defined by method 'defaultConversionService' in class path resource [org/springframework/data/rest/webmvc/config/RepositoryRestMvcConfiguration.class]
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
Why 2 beans are created and how to keep only one converter, I just want only spring core converter who can convert entity to pojo or pojo to entity.
I am stuck because of this issue, any lead would be helpful.
Service class code:-
import org.springframework.core.convert.ConversionService;
//other imports
#Service
public class DashBoardSettingsServiceimpl implements DashBoardSettingsService {
#Autowired
private DashBoardSettingJpaRepository dashBoardSettingRepo;
#Autowired
private ConversionService conversionService;
#Override
public DashBoardSettingResponse save(UserInfo userInfo, DashBoardSettingRequest request) {
//other coded
DashBoardSettigEntity entity = conversionService.convert(request.getDashBoardSetting(),
DashBoardSettigEntity.class);
DashBoardSettigEntity entityRetrieve = dashBoardSettingRepo.save(entity);
DashBoardSetting setting = conversionService.convert(entityRetrieve, DashBoardSetting.class);
DashBoardSettingResponse response = new DashBoardSettingResponse();
response.addDashBoardSetting(setting);
return response;
}
}
Autowire type DefaultConversionService instead of ConversionService
Seems like it has something to do with spring data rest having its own ConversionService instance.
Can you try this:
#Autowired #Qualifier("mvcConversionService") ConversionService conversionService;
It worked for me.
Don't forget to add your converters to a WebMvcConfigurer implementation.
Related
I am learning spring and i have a problem that i do not know how to solve.
#Service
#Transactional
public class SchoolService {
#Autowired
private CourseDao courseDao;
#Autowired
private EducationDao educationDao;
#Autowired
private StudentDao studentDao;
#Autowired
private TeacherDao teacherDao;
#Autowired
private StatisticsDao statisticsDao;
............
}
This code is injecting my DAOS into this service class but then i need to inject the class above into two controllers.
One way i have tried was with this code but that did not work.
#Autowired
SchoolService sm;
How would i inject it into my controller class. I have tried making the controller class a #Component but nothing seems to work.
ClassPathXmlApplicationContext container = new ClassPathXmlApplicationContext("application.xml");
SchoolService sm = container.getBean(SchoolService.class);
This way works but i do not want to create a new applicationcontext for each time i want to get that bean.
Yes i am using xml at the moment, please don't shoot me :D
Thanks.
Try creating the controller bean in the application.xml file instead of annotating the controller.
Since its obviously an educational question, I'll try to provide a very detailed answer as much as I can:
Once basic thing about spring that all the auto-wiring magic happens only with beans that are managed by spring.
So:
Your controllers must be managed by spring
Your service must be managed by spring
Your DAOs must be managed by spring
Otherwise, autowiring won't work, I can't stress it more.
Now, Think about the Application Context as about the one global registry of all the beans. By default the beans are singletons (singleton scope in terms of spring) which means that there is only one object (instance) of that bean "retained" in the Application Context.
The act of autowiring means basically that the bean (managed by spring) - controller in your case has dependencies that spring can inject by looking in that global registry, getting the matching bean and setting to the data field on which the #Autowired annotation is called.
So, if you have two controllers (again, both managed by spring), you can:
#Controller
public class ControllerA {
#Autowired
private SchoolService sm;
}
#Controller
public class ControllerB {
#Autowired
private SchoolService sm;
}
In this case, the same instance of school service will be injected into two different controllers, so you should good to go.
I have the following structure:
WebService
#Autowired
public FooService(#Qualifier("fooMapper1") FooBO fooBO1,
#Qualifier("fooMapper2") FooBO fooBO2,
#Qualifier("fooMapper3") FooBO fooBO3) {
this.fooBO1= fooBO1;
this.fooBO2= fooBO2;
this.fooBO3= fooBO3;
}
Configuration
#Configuration
public class MapperConfig {
#Bean("fooMapper1")
public FooBO oneMapper(FooOneMapper mapper) {
return new FooBO(mapper);
}
#Bean("fooMapper2")
public FooBO twoMapper(FooTwoMapper mapper) {
return new FooBO(mapper);
}
#Bean("fooMapper3")
public FooBO threeMapper(FooThreeMapper mapper) {
return new FooBO(mapper);
}
}
FooBO
#Autowired
public FooBO(IFooMapper mapper) {
this.mapper = mapper;
}
IFooMapper is and interface that is extended by FooOneMapper, FooTwoMapper and FooThreeMapper.
When I try to run the project the following message is throwing:
Description:
Parameter 0 of constructor in ...FooBO required a single bean, but 4 were found:
- FooOneMapper: defined in file [C:...\mapper\FooOneMapper.class]
- FooTwoMapper: defined in file [C:...\mapper\FooTwoMapper.class]
- FooThreeMapper: defined in file [C:...\mapper\FooThreeMapper.class]
- IFooMapper: defined in file [C:...\mapper\IFooMapper.class]
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 don't understand why spring have this conflict with the beans being that all seems to be well configured.
I am guessing you have annotated FooBO with #Component annotation.
the root package containing Spring Boot main class s is scanned to look for any #Component-annotated classes, and those classes are registered as Spring bean definitions within the container
You are creating beans in the configuration class. Make sure FooBO and IFooMapper are not annotated with #Component or its stereotype annotation.
class FooBO {
private final IFooMapper mapper;
public FooBO(IFooMapper mapper) {
this.mapper = mapper;
}
}
If for some reason you cannot remove #Component. Other ways to fix would be to mark one of the implementation of IFooMapper as primary using #Primary
#Component
#Primary
class FooOneMapper implements IFooMapper{
}
or provide additional data to help spring resolve dependency.
public FooBO(#Qualifier("fooThreeMapper") IFooMapper mapper) {
this.mapper = mapper;
}
First Spring does a scan to find the beans it has in the application context. It finds your #Configuration that creates three beans of type FooBO (and implicitly also of type IFooMapper). It also finds other beans you defined with annotatoins or in your xml - so it finds IFooMapper.
Secondly, Spring finds your #Autowired FooBO constructor and it has to decide what bean you want to inject there. It's default strategy is to inject based on the type of the bean. So it looks what beans of type IFooMapper are there in the current context. It finds the three in your configuration and anything else you declared in other places. It throws an exception because it cannot decide what instance to use. If you annotate one of the beans #Primay then Spring will always use that one in such situations.
Extra reading:
Spring bean lifecycle / Spring autowiring
I am coding both a library and service consuming this library. I want to have a UsernameProvider service, which takes care of extracting the username of the logged in user. I consume the service in the library itself:
class AuditService {
#Autowired
UsernameProvider usernameProvider;
void logChange() {
String username = usernameProvider.getUsername();
...
}
}
I want to have a default implementation of the UsernameProvider interface that extracts the username from the subject claim of a JWT. However, in the service that depends on the library I want to use Basic authentication, therefore I'd create a BasicAuthUsernameProvider that overrides getUsername().
I naturally get an error when there are multiple autowire candidates of the same type (DefaultUsernameProvider in the library, and BasicAuthUsernameProvider in the service), so I'd have to mark the bean in the service as #Primary. But I don't want to have the library clients specify a primary bean, but instead mark a default.
Adding #Order(value = Ordered.LOWEST_PRECEDENCE) on the DefaultUsernameProvider didn't work.
Adding #ConditionalOnMissingBean in a Configuration class in the library didn't work either.
EDIT: Turns out, adding #Component on the UsernameProvider implementation classes renders #ConditionalOnMissingBean useless, as Spring Boot tries to autowire every class annotated as a Component, therefore throwing the "Multiple beans of type found" exception.
You can annotate the method that instantiates your bean with #ConditionalOnMissingBean. This would mean that the method will be used to instantiate your bean only if no other UserProvider is declared as a bean.
In the example below you must not annotate the class DefaultUserProvider as Component, Service or any other bean annotation.
#Configuration
public class UserConfiguration {
#Bean
#ConditionalOnMissingBean
public UserProvider provideUser() {
return new DefaultUserProvider();
}
}
You've not posted the code for DefaultUsernameProvider but I guess its annotated as a #Component so it is a candidate for auto wiring, and the same with the BasicAuthUsernameProvider. If you want to control which of these is used, rather than marking them both as components, add a #Configuration class, and create your UsernameProvider bean there:
#Configuration
public class ProviderConfig {
#Bean
public UsernameProvider() {
return new BasicAuthUsernameProvider();
}
}
This bean will then be auto wired wherever its needed
I am using #ComponentScan and #Component to define my spring beans. What I would like is to declare one of these beans to be autowire-candidate=false.
This could be done with this attribute in xml. Isn't there the equivalent in annotations?
The reason I want this is because I have 2 implementations of the same interface and I don't want to use #Qualifier.
EDIT: Using #Primary is a valid work-around, but autowire-candidate seems to me like a useful feature with its own semantics.
Thanks
Looks like Spring refused autowire-candidate=false concept and it no longer supported. There is no analogue with annotations, so #Primary is the best work-around as you noticed.
Another way is to use custom org.springframework.beans.factory.support.AutowireCandidateResolver, which is used in DefaultListableBeanFactory, with logic that exclude undesirable beans from autowire candidates. In such case, the technology will be similar to that used for autowire-candidate=false in SimpleAutowireCandidateResolver.
Since Spring 5.1 , you can configure autowire-candidate in #Bean through autowireCandidate attribute:
#Bean(autowireCandidate = false)
public FooBean foo() {
return newFooBean();
}
You can also use the bean accessor to tune it's visibiltiy.
see Bean visibility
#Configuration
public abstract class VisibilityConfiguration {
#Bean
public Bean publicBean() {
Bean bean = new Bean();
bean.setDependency(hiddenBean());
return bean;
}
#Bean
protected Bean hiddenBean() {
return new Bean("protected bean");
}
}
You can then #Autowire the Bean class and it will autowire the public bean (without complaining about multiple matching beans)
As a class' definition (unless embedded) does not allow private / protected accessor the work around would be to use an #Configuration class that would instantiate all the beans an publish the public beans while hiding the private/protected (instead of directly annotating the classes #Component \ #Service)
Also package-protected accessor may worth a try to hide #Component annotated classes. I don't know if that may work.
We can do this by using the #Qualifier annotations with name mentioned in the #Component annotations
Bean classes -
#Component("fooFormatter")
public class FooFormatter implements Formatter {
public String format() {
return "foo";
}
}
#Component("barFormatter")
public class BarFormatter implements Formatter {
public String format() {
return "bar";
}
}
Injecting bean in service class -
public class FooService {
#Autowired
#Qualifier("fooFormatter")
private Formatter formatter;
}
For more details please refer - https://www.baeldung.com/spring-autowire#disambiguation. Above example taken from this link.
I'm trying to implement a command-query design pattern into
a MVC spring based application.
I have, for example, some decorated commands using decorator pattern
like bellow:
ICommandHandler handler =
new DeadlockRetryCommandHandlerDecorator<MoveCustomerCommand>(
new TransactionCommandHandlerDecorator<MoveCustomerCommand>(
new MoveCustomerCommandHandler(
new EntityFrameworkUnitOfWork(connectionString),
// Inject other dependencies for the handler here
)
)
);
How can I inject such a handler into a controller constructor? Where should
I instantiate this handler? A place where this can be instantiated can be
the controller constructor, but this isn't the best solution. Any other ideeas?
Thanks
If you're using PropertyPlaceholderConfigurer (old) or PropertySourcesPlaceholderConfigurer (new), and your connection string is in a .properties file or environment variable you can do the following for the connection string. You can also autowire objects into a configuration class and annotate a method with #Bean to do what the Spring context xml does. With this approach you can create your beans as you wish and they're available to autowire just like you defined them in xml.
#Configuration
public class MyAppConfig {
#Autowired private MyType somethingToAutowire;
#Bean
public ICommandHandler iCommandHandler(#Value("${datasource.connectionString}")
final String connectionString) {
return new DeadlockRetryCommandHandlerDecorator<MoveCustomerCommand>();
// You obviously have access to anything autowired in your configuration
// class. Then you can #Autowire a ICommandHandler type into one of your
// beans and this method will be called to create the ICommandHandler (depending on bean scope)
}
}