PROCEDURE TO GUIDE YOU THROUGH HARD ISSUES ... MYSTERIOUS ONES
IN THE CONTEXT DESCRIBED HERE, AND POSSIBLY EXTENSIBLE TO OTHERS
>PROBLEM
Attempt of injecting a bean using Spring Boot and Maven fails with the following message:
Parameter 0 of method setStrongEncryptor in br.com.adr.thylab2.service.security.EncryptionSvcImpl required a bean of type 'org.jasypt.util.password.StrongPasswordEncryptor' that could not be found.
Action:
Consider defining a bean of type 'org.jasypt.util.password.StrongPasswordEncryptor' in your configuration.
>SOLUTION
1. First check your scan configuration.
Go to the class that it is used to start the app.
At @SpringBootApplication annotation check value offered to "scanBasePackages" if it contains a parent path for the class where the problem happens. Sometimes, a class becomes out of the subdirectory tree referenced by the scan value. If there isn't a parent path to the complaining class, add it.
Go to the class that it is used to start the app.
At @SpringBootApplication annotation check value offered to "scanBasePackages" if it contains a parent path for the class where the problem happens. Sometimes, a class becomes out of the subdirectory tree referenced by the scan value. If there isn't a parent path to the complaining class, add it.
@SpringBootApplication(scanBasePackages={"br.com.adr.thylab2", "my another package here"})
Example:
@SpringBootApplication(scanBasePackages={"br.com.adr.thylab2"})
public class Thylab2App extends SpringBootServletInitializer {
public static final String VERSION = "2.0.0-RELEASE";
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(Thylab2App.class);
}
public static void main(String[] args) {
SpringApplication.run(Thylab2App.class, args);
}
}
2. Check your @Service or @Component annotations in the related classes, those with relationships concerned to the issue.
Is it missing an annotation?
Is it annotated as it should be?
Is it missing an annotation?
Is it annotated as it should be?
3. Is the missing bean defined?
An alternative is to supply the missing bean using a common class.
For instance:
@Configuration
public class CommonBeans {
@Bean
public StrongPasswordEncryptor strongEncryptor(){
StrongPasswordEncryptor encryptor = new StrongPasswordEncryptor();
return encryptor;
}
}
4. Check the library versions.
For instance, if using Maven, go to pom.xml and try to update the version of the related packages, or yet, try to downgrade.
Sometimes, one library causes issues with certain versions of another ones.
5. Eventually, rollback and proceed a step-by-step checking.
If the problem still persists, the issue may be caused by more than one issue, which exception thrown on the stack may interfere with the final results to help finding the solution.
This approach is radical but very effective.
First, you make the famous "backup" of the current project. Just do it, please!
A simple copy of it is enough.
If using versioning, for instance Git or SVN, you may get a previous point prior to the introduction of the new stuff related to the issue. This is the whole point, no matter which version control system you are working with!
5a. Check if your classpath contains the necessary references.
A simple way of doing this is including some testing code that references it.
For instance, if using Spring Boot, you could simply do, like below, in a straight manner in order to skip another possible setbacks to check if your classpath is properly configured.
@SpringBootApplication(scanBasePackages={"br.com.adr.thylab2"})
This approach is radical but very effective.
First, you make the famous "backup" of the current project. Just do it, please!
A simple copy of it is enough.
If using versioning, for instance Git or SVN, you may get a previous point prior to the introduction of the new stuff related to the issue. This is the whole point, no matter which version control system you are working with!
5a. Check if your classpath contains the necessary references.
A simple way of doing this is including some testing code that references it.
For instance, if using Spring Boot, you could simply do, like below, in a straight manner in order to skip another possible setbacks to check if your classpath is properly configured.
@SpringBootApplication(scanBasePackages={"br.com.adr.thylab2"})
public class Thylab2App extends SpringBootServletInitializer {
public static final String VERSION = "2.0.0-RELEASE";
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(Thylab2App.class);
}
public static void main(String[] args) {
StrongPasswordEncryptor passwordEncryptor = new StrongPasswordEncryptor();
String encryptedPassword = passwordEncryptor.encryptPassword("");
SpringApplication.run(Thylab2App.class, args);
}
}
5b. Bring to the code one interface/class set at a time.
Begin with the simplest classes, bringing just one interface/class set, and testing.
Test one after the other, never more than one by its turn.
You'll probably note that this procedure will show more than one issue, but working one by one, helps the compiler to guide you to the solution.
I do sincerely hope that this "laborious and boring" procedure may help you, but surely helped me when I was desperately lost, more than once, trying to find out a mysterious issue. :-)
Begin with the simplest classes, bringing just one interface/class set, and testing.
Test one after the other, never more than one by its turn.
You'll probably note that this procedure will show more than one issue, but working one by one, helps the compiler to guide you to the solution.
I do sincerely hope that this "laborious and boring" procedure may help you, but surely helped me when I was desperately lost, more than once, trying to find out a mysterious issue. :-)
>ENV
spring boot 1.5.4.RELEASE
java 8
maven
eclipse
I fixed it with adding concrete annotation @org.springframework.stereotype.Service
ReplyDelete