I am using
#Service
public class Service{
#Autowired
private CacheManager cacheManager;
}
I included org.ehcache:ehcache and spring-boot-starter-cache library in the build.gradle file.
on running the application I am getting the error:
Field cacheManager required a bean of type org.springframework.cache.CacheManager that could not be found.
I am not sure how to go about resolving this error
My Thoughts:
Looks like I need to declare a class annotated with #Configuration and with methods #Bean which returns an object of type CacheManager. I am using EhCache here. Not sure exactly how to do this.
Related
I've an interface with two implementations. Which implementaton is to be used depends of the environment (production, development, test, ...). I therefore use Spring profiles. I'm using a configuration file to instantiate the correct implementation.
#Configuration
public class BeanConfiguration {
#Profile({"develop","test-unit"})
#Bean(name = "customerEmailSender")
public CustomerEmailSender emailSenderImpl_1(){
return new EmailSenderImpl_1();
}
#Profile({"prod"})
#Bean(name = "customerEmailSender")
public CustomerEmailSender emailSenderImpl_2(){
return new EmailSenderImpl_2();
}
}
When the Spring container starts (with a specific profile), the correct bean is autowired into the class, and all works fine.
#Component
public class CustomerEmailProcessor {
#Autowire
private CustomerEmailSender customerEmailSender;
...
}
I also have a test class in which I want to autowire the bean. I'm using #Mock for autowiring.
The profile is set to "test-unit" in the test class. So, I'm expecting the spring container to lookup in the config class for the correct bean to be instantiated. But this doesn't happen.
Instead, an Exception is thrown :
Caused by: java.lang.IllegalStateException: Unable to register mock bean .... expected a single matching bean to replace but found [customerEmailSender, emailSenderImpl_1, emailSenderImpl_2]
When using #Autowire annotation, all goes fine. But of course the bean is not mocked anymore and that's what I need to have.
#RunWith(SpringRunner.class)
#ActiveProfiles(profiles = {"test-unit"})
#Import(BeanConfiguration.class)
public class CustomerEmailResourceTest {
#MockBean
private CustomerEmailSender customerEmailSender;
}
I've put a breakpoint in the config class, and I can see that when using #Autowire in the test class, the correct bean is instantiated (breaks at the line "return new EmailSenderImpl_1();".
When using #Mock, no bean at all is instantiated. Spring doesn't break at the line "return new EmailSenderImpl_1();"
Why is it that Spring can find the correct bean when using the #Mock annotation.
The #Mock annotation must be the reason that Spring doesn't use the config class "BeanConfiguration.java". That makes sence after all.
There are spring boot 2.0.2 configuration
#Configuration
public class ApiConfig {
#Bean
#Profile("!tests")
#ConditionalOnProperty(name = "enabled", havingValue = "true")
public MyService service() {
return new MyServiceImpl();
}
}
... and some controller which should be created and added to application context only if MyService bean is initialized.
#RestController
#ConditionalOnBean(MyService.class)
public class MyController {
#Autowired
private MyService service;
}
It works Ok. But occasionally spring boot skips MyController creating. According to the logs MyService is created, but after any other beans(including all controllers), at the end.
Why boot does not process #Configuration beans prior to #RestController?
Thanks.
Why boot does not process #Configuration beans prior to #Controller?
Thanks.
Because Spring doesn't guarantee that.
As well as #ConditionalOnBean warns about this kind of issue in this specification :
The condition can only match the bean definitions that have been
processed by the application context so far and, as such, it is
strongly recommended to use this condition on auto-configuration
classes only. If a candidate bean may be created by another
auto-configuration, make sure that the one using this condition runs
after.
And you don't use the annotation in an auto-configuration class. You indeed specified it in a class annotated with #RestController.
I think that to achieve your requirement you should move the #RestController bean declaration in a #Configuration class that's imported via an EnableAutoConfiguration entry in spring.factories.
I am developing OAuth implementation with Jwt tokens.
It's kind of weird but for class TokenAuthenticationService When I try to Autowired this class in a different package, I get
Consider defining a bean of type 'com.company.security.TokenAuthenticationService' in your configuration.
I did a workaround and added #Bean TokenAuthenticationService in that class.Now when I am trying to initialize an interface in the TokenAuthenticationService class, it gives the same type of error for that interface.
Consider defining a bean of type 'com.company.security.UserService' in your configuration.
ComponentScan annotation is configured like #ComponentScan({"com.company"})
What I am missing here and why?
You have two ways to define beans for autowiring in your project.
With classes defined by you, you can use the #Component annotation (or, for service classes, #Service annotation) this way:
#Service
public class TokenAuthenticationService { ... }
If you are using third party classes, you can configure them in a configuration class:
#Configuration
public MyProjectConfig {
#Bean
public ThirdPartyClass serviceClass() { new ThirdPartyClass(); }
}
(Using #Bean annotation is not a workround. You just need to understand its purpose...)
This way autowiring should work...
Pay attention to difference between #Component and #Bean annotations.
When I start my application as Spring Boot application, ServiceEndpointConfig gets autowired properly. But when I run as Junit test, I get the following exception. I am using application.yml file and different profiles.
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(classes = MyServiceContextConfig.class,
loader = SpringApplicationContextLoader.class)
#ActiveProfiles({"unit", "statsd-none"})
public class MyServiceTest
{
}
#Configuration
public class MyServiceContextConfig {
#Bean
public MyService myServiceImpl(){
return new MyServiceImpl();
}
}
#Configuration
#Component
#EnableConfigurationProperties
#ComponentScan("com.myservice")
#Import({ServiceEndpointConfig.class})
public class MyServiceImpl implements MyService {
#Autowired
ServiceEndpointConfig serviceEndpointConfig;
}
#Configuration
#Component
#ConfigurationProperties(prefix="service")
public class ServiceEndpointConfig
{
}
Error:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'myServiceImpl':
Unsatisfied dependency expressed through field 'serviceEndpointConfig': No qualifying bean of type [com.myservice.config.ServiceEndpointConfig] found
You're handling MyServiceImpl inconsistently: On the one hand, you're using scanning annotations, and on the other, you're explicitly creating an #Bean in a configuration class. The import directive is only processed when Spring picks MyServiceImpl up via scanning; otherwise, it's not treated as a configuration.
Your relationships between the classes are tangled up; the whole point of dependency injection is that MyServiceImpl should say what sort of thing it needs but not create it itself. This organization is no better than manually creating dependencies internally.
Instead,
eliminate the #Configuration and #Import directives from MyServiceImpl,
use constructor injection on MyServiceImpl, and
change your test configuration to include all the necessary configuration classes.
With constructor injection, you may be able to bypass the Spring context entirely and run this as an actual unit test by simply creating a new MyServiceImpl(testServiceConfig).
I am studying for Spring Core certification.
I know that in Spring I can configure the dependency injection using 3 way:
Java Configuration
Classes annotations
XML Configuration
I have some doubt related to how to use the first kind of dependency injection configuration.
For example I have something like this:
1) A class named TransferServiceImpl:
public class TransferServiceImpl implements TransferService {
public TransferServiceImpl(AccountRepository ar) {
this.accountRepository = ar;
}
...
...
...
}
This class contain the TransferServiceImpl() constructor that take an AccountRepository object as input paramether, so AccountRepository is a dependency that have to be injected into TransferServiceImpl().
2) This is the implementation of the previous AccountRepository class:
public class JdbcAccountRepository implements AccountRepository {
public JdbcAccountRepository(DataSource ds) {
this.dataSource = ds;
}
...
...
...
}
So the constructor of this class thake a DataSource object that have to be injected into the JdbcAccountRepository class.
Then I have a configurations class that contains the dependency injection configuration:
#Configuration
public class ApplicationConfig{
#Bean public TransferService transferService(){
return new TransferServiceImpl(accountRepository());
}
#Bean public AccountRepository accountRepository(){
return JdbcAccountRepository(dataSoruce());
}
#Bean public DataSource dataSource(){
DataSource dataSource = new BasicDataSource();
dataSource.setDriverClassName("org.postgresql.Driver");
...................................
...................................
...................................
}
}
So it seems to me that it work in the following way:
I have my 2 implemented beans named TransferServiceImpl and JdbcAccountRepository and the configuration class named ApplicationConfig.
Into the configuration class I say that when someone ask to the factory to create a TransferService object it automatically build its implementation TransferServiceImpl creating and injecting automatically a JdbcAccountRepository into the TransferServiceImpl constructor.
In the same way when a JdbcAccountRepository is created it is injected a DataSource object into its constructor.
Is it right?
If it is right I have the following doubts:
1) Into the ApplicationConfig class I also declare the DataSource bean but I don't implement this class. Is it a class provided by Spring and I have only to set its properties values?
2) When are created the bean definied into the ApplicationConfig class? At the application startup? I think that, in the previous example, if I annotate a constructor using #Bean it is created as singleton at the application startup. Is it right or am I missing something?
Tnx
1) Into the ApplicationConfig class I also declare the DataSource bean
but I don't implement this class. Is it a class provided by Spring and
I have only to set its properties values?
Yes. There are a number of DataSource implementations provided by Spring. For example: DriverManagerDataSource, SingleConnectionDataSource, and more.
2) When are created the bean definied into the ApplicationConfig
class? At the application startup? I think that, in the previous
example, if I annotate a constructor using #Bean it is created as
singleton at the application startup. Is it right or am I missing
something?
By default beans are created when Spring container is instantiated (usually at startup if the app is wired as such). You can change this behavior, however, by using the #Lazy annotation where the bean will only be created when explicitly requested.
#Bean #Lazy public TransferService transferService(){
return new TransferServiceImpl(accountRepository());
}