Please note: this question is not a dupe, and I even reference the other similar question below. I assert that my situation is categorically different than the other question referenced.
I am standing up a Spring Boot web service that is not backed by any database, JDBC or RDBMS data source.
At startup I get and error:
Cannot determine embedded database driver class for database type NONE
Here on SO I see a very similar question here where the accepted answer states:
"You haven't provided Spring Boot with enough information to auto-configure a DataSource"
...and goes on to explain how to set the appropriate values in the app config file:
spring.datasource.url = ...
spring.datasource.driver-class-name = ...
But what if I don't want any data sources?! In the other question, the user was connecting to NoSQL via DataNucleus. In my case, I'm not interested (at least at the present moment) in connecting to any type of data source (all data for this service will come from other cloud-based REST services).
What's the fix here?
According to the documentation, you can turn this behavior off by excluding DataSourceAutoConfiguration from the auto-configuration that Spring Boot does for you.
#Configuration
#EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
public class MyConfiguration {
// ...
}
Update To Answer Questions: By using #SpringBootApplication, it automatically pulls in #EnableAutoConfiguration, and if it sees the jdbc jars on the classpath, will add/execute DataSourceAutoConfiguration. The code above turns off this behavior.
If you are using #SpringBootApplication decorator you can exclude by using the DataSourceAutoConfiguration as done in the #EnableAutoConfiguration decorator as well. Documentation ref
#Configuration
#SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
public class MyApplication {
// ...
}
Related
I am working with spring batch. I needed to add some jpa repositories. So previously i was using JDBCTemplate which was working fine.
But when I started working with JPA, the spring boot application could not find the repos. Which were there.
#Autowired
ClassLevelConfigRepo clcr;
I checked these things as the best practices.
Added #EnableJpaRepositories in springBoot application class.
Added #Repostiories to the repository interfaces.
extended the interfaces with JpaRepository<Account, String>
Added #Entity to the entity classes and defined the #Table and # Column annotations properly.
But I am still getting below error.
Field clcr in com.cloudtask.batchconfig.util.LhmUtility required a bean of type 'com.cloudtask.batchconfig.repo.ClassLevelConfigRepo' that could not be found.
I tried checking all the dependencies in pom.xml it was as per recommended. And I have all the tables defined properly in data base.
I was expecting the application to return the Autowired clcr object propely.
Edit 1 : spring boot application annotations
#SpringBootApplication
#ComponentScan({"com.cloudtask"})
#EnableAsync
#IntegrationComponentScan({"com.cloudtask"})
#EnableIntegrationManagement(defaultLoggingEnabled = "true")
#EnableJpaRepositories
#EntityScan
public class imclassApplication ```
When you work with Spring Data Jpa with those basic points you should also keep track of below points.
you have added spring-boot-starter-data-jpa in your pom.xml
you have added the entity and repo package below one level of the application package.
If you the package is at same level you should specify the exact package details in the annotation. in your case it should be like :
#EnableJpaRepositories("com.cloudtask.batchconfig.repo")
#EntityScan(basePackages = {"com.cloudtask.batchconfig.entity"})
Happy programming!
In spring boot, application.yml takes in the Spring oauth2 client config. How do I configure it for the non-boot application. By configuration I mean giving client ID, secret, scopes and redirect URI.
You could find an example here:
https://www.baeldung.com/spring-security-5-oauth2-login#non-boot
You need to:
Build your ClientRegistration.
A ClientRegistrationRepository.
Register your repository on WebSecurityConfigurerAdapter.
If you don't use SpringBoot : there is no application.yml and even if you can add the support of yml files. It won't handle your oauth2 client config.
Anyway you can use Spring security to implement your custom Authorization Service, a User service and implement a Token Store of your choice (JBDCTokenStore or JWTTokenStore for example). But It's a very wide question depending on your business logic.
You can find some well documented samples on :
https://github.com/spring-projects/spring-security-oauth/tree/master/spring-security-oauth2
Of course you can handle both XML and javaConfig even mixed Spring confugurations.
Create a #Configuration class with a #ComponentScan on the packages containing components or bean definitions.
#Configuration
#ComponentScan({ "com.firm.product.config.xml","com.firm.product.config.java" })
public class SpringConfig {
}
You can also set properties with #PropertySource() ans #Value annotations. It's very well documented.
Upgrading an existing system to Spring Boot with Auto config. Currently the system is all Java config. I'm confused over whether to continue the use of #Profile. Is this annotation no longer needed? I searched extensively about upgrading and found only references to non-Spring Java migration and creating new projects.
Typical #Profile usage in our configuration classes looks something like:
#Bean
#Profile("is-standalone")
public Service unsecuredService(SomeApi someApi) {
return new ...
}
I inferred from the Spring Boot examples that using one of the #Conditional annotations is recommended like this:
#Bean
#ConditionalOnProperty("unsecured.enabled")
public Service unsecuredService(SomeApi someApi) {
return new ...
}
Then in a YAML file the is-standalone Profile enables or disables all the various properties for that Profile. Is this the proper way to upgrade? To repeat a question from above differently, can the #Profile usage be left as is? This is for a fairly large project, the upgrade is non-trivial, so I would like to do this only once!
Depends where your previous #Profile annotation is coming from. If you're using Spring's #Profile, the functionality is as follows:
Annotating a class with #Profile("dev") will load the class and register it in the Spring context only when the dev profile is active
Annotating a class with #Profile("!dev") will load the class and register it in the Spring context only when the dev profile is inactive
If this sounds like what you have already, no change is needed.
I'm trying to use the new #JdbcTest annotation in Spring boot 1.5.0.RC1.
My app uses Eureka discovery ie I have
compile('org.springframework.cloud:spring-cloud-starter-eureka')
in my build.gradle and
#EnableDiscoveryClient
on my main Spring Boot class
When I try to use #JdbcTest to test a JdbcTemplate based DAO I get this error:
***************************
APPLICATION FAILED TO START
***************************
Description:
Parameter 0 of method eurekaHealthIndicator in org.springframework.cloud.netflix.eureka.EurekaDiscoveryClientConfiguration$EurekaHealthIndicatorConfiguration required a bean of type 'com.netflix.discovery.EurekaClient' that could not be found.
Action:
Consider defining a bean of type 'com.netflix.discovery.EurekaClient' in your configuration.
It looks like the auto configuration is loading part of the Eureka configuration when it should only load JDBC related beans.
If I add
#TestPropertySource(properties={"eureka.client.enabled=false"})
to the test the problem goes away, but I think #JdbcTest should be making sure already that only relevant beans are loaded.
Am I missing something or is this a problem with the new #JdbcTest, or maybe Spring Cloud Eureka?
Your #SpringBootApplication has # EnableDiscoveryClient on it. When you use a slice annotation (such as #JdbcTest), Spring Boot finds the context to use by looking at the package of your test for a #SpringBootConfiguration. If it does not find one, it looks in the parent package, etc. With a sensible package structure and no further customization, your tests use your #SpringBootApplication as the root context.
So, that configuration class (and only that one) is processed an #EnableDiscoveryClient is also obviously processed. In your case, this has an additional side effect: every single test now requires the Eureka Client.
TL;DR never put such annotation on your application. And only put it if you actually need it. You could define a #Configuration class next to your Spring Boot app for those.
#David
I had similar issue and fixed by adding the following to my application.yml file
eureka:
client:
enabled: false
I am using Spring Boot V 1.4.1 for a new application.
My app requires two JDBC data sources and I was following the example at http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-two-datasources how to set it up.
My Spring beans configuration class is annotated with #EnableConfigurationProperties and my first bean is defined as
#Primary
#Bean
#ConfigurationProperties(prefix = "first.database")
DataSource qivsDB() {
return DataSourceBuilder.create().build();
}
, the second one accordingly. My application.properties file has properties defined like
first.database.url=jdbc:[redacted]
first.database.username=[redacted]
first.database.password=[redacted]
For reasons I not transparent to me during debugging this is failing to initialize: Cannot determine embedded database driver class for database type NONE - debug showed me that the builder does not have any properties set when calling build().
What did I miss here?
Before you do all the debugging part, you should have a look to the auto-configuration report. If you define your own DataSource there's no reason for Spring Boot to start looking at what it can do for your app. So, for some reasons, that definition of yours is not applied in your app and the default in Spring Boot still applies, doesn't find any JDBC url in the default namespace and attempt to start an embedded database. You should see in the auto-config report that the DataSourceAutoConfiguration still matches.
I am not sure the public keyword has anything to do with it, though you won't get custom meta-data for that key since we only scan for public methods.