I have a legacy grails app running grails v3.2.9. We are currently using properties files for setting the dataSource configuration.
We have an internal system that stores our configurations that is loaded as a spring bean. I need to use this to hook it into our configuration system for compliance reasons. Is there any way to configure the dataSource from these at startup?
Related
Im trying to connect to Pivotal Cloud Cache server Regions.
I'm using #EnableClusterAware and trying to configure the client Regions via ClientRegionFactoryBean as below:
#Bean("clientRegion")
ClientRegionFactoryBean someClientRegion(GemFireCache gemfire) {
// ...
}
Either GemFireCache or ClientCache beans are not available with the annotation #EnableClusterAware. It's available only with #ClientCacheApplication.
Is there any annotations that needs to be used in conjunction with #EnableClusterAware so that GemFireCache gets injected?
Please help.
When Spring Boot for Apache Geode, or alternatively GemFire, (SBDG) is on the classpath of your Spring Boot application (see here), then SBDG auto-configuration will automatically create and configure a ClientCache instance for you (see here).
TIP: You can also review the Getting Stated Sample Guide and Source to see this behavior in action, for yourself. The Guide also talks about the use of the #EnableClusterAware annotation, here.
The #EnableClusterAware annotation is simply a development-time, SBDG annotation that enables you to switch between environments (e.g. local vs. managed, such as when pushing your Spring Boot application up to run in PCF, connected to PCC, and then testing locally in your IDE) without having to change any configuration (hence the goals).
The #EnableClusterAware annotation does not create any GemFire/Geode cache instances for you. Only SBDG's auto-configuration, or declaring an explicit SDG annotation (e.g. #ClientCacheApplication) will do that for you. Still, when using SBDG auto-configuration, you do not need an explicit SDG cache application annotation, like #ClientCacheApplication, since SBDG auto-configuration (again) creates and configures a ClientCache instance by default.
TIP: See the documentation on the #EnableClusterAware annotation for more details.
If ClientCache is not provided (auto-configured), then you are not:
Using SBDG, or rather do not have SBDG on the Spring Boot application classpath (see here)
Have not bootstrapped or configured and ran your Spring application with Spring Boot
Your Spring Boot application configuration is incorrect
You have explicitly disabled or overrode the SBDG auto-configuration
Etc.
One or more of these have to be true.
Following other links I have tried all configurations including enabling jndi of embedded tomcat container. (A very good detailed like is: https://www.roytuts.com/spring-boot-jndi-datasource/) But the problem is that the DataSource is looked up against JNDI and I get follwoing exception:
Please note that From Spring 2.0.x Embedded configuration classes have changed.
Get:
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial.
As for the question of JNDI lookup in Embedded tomcat is rare use case I am trying to simulate and reproduce a Database Connection Pooling Error in production and for that I have to use JavaConfig settings for Resource and DataSource both.
I have a spring cloud application, which under the covers uses spring boot.
In the bootstrap phase of the app I am using some classes from the apache commons config library under: org.apache.commons.configuration
My application is started with this flag per the spring docs:
-Dlogging.level.org.apache.commons.configuration=INFO
Despite this, i am still getting DEBUG level logs emitted during the bootstrap phase of spring....
I am lost as to how to properly specify the log level of INFO specified for the bootstrap phase of spring boot.
Ensure you are not setting debug=true in application properties or not passing --debug flag to the application.
In application.properties set:
debug=false
The configuration of spring boot has a specific order, so probably somewhere in the application or bootstrap configuration files the logging level is configured to DEBUG.
Source:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
I have spring boot application and it's basically a gradle project, so, I have below dependency added in my gradle file:
org.springframework.boot:spring-boot-gradle-plugin:1.5.1.RELEASE
Application gets deployed in embedded jetty server. I have following set of properties in application.properties for db connection polling:
spring.datasource.driver-class-name
spring.datasource.max-active
spring.datasource.max-idle
spring.datasource.min-idle
spring.datasource.validation-query
spring.datasource.name
I was referring to below two links:
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.4-Configuration-Changelog
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-1.5-Configuration-Changelog
I came to know that some of the datasource properties which used in application.properties file in my application are removed starting sprint boot version 1.4 but issue they haven't mentioned what are the new properties to use. Like for tomcat server they have provided all set of properties but not for jetty server. I am facing some db related errors like 'too many connections' after my application run for sometime, my assumption is that datasource props I am currently using are not correct and should be replaced with correct values, but unfortunately I am unable to find correct property names.
Jetty doesn't have its own Pooling DataSource implementation. You can include HikariCP in your project and customise using the spring.datasource.hikari.* properties. With each property matching the bean properties that can be set on Hikari's datasource implementation.
I have a java service created using JHipster Generator ver 3.4.0 using the monolith approach. How can I use #RefreshScope? Is it just a matter of brining in spring-cloud as dependency and annotating with bean #RefreshScope?
Does the JHipster Configuration UI support updating configuration values?
Is it just a matter of brining in spring-cloud as dependency and annotating with bean #RefreshScope?
You can add spring cloud dependencies partially, so yes. You can generate a microservice application to see how this should be configured properly by taking a look at bootstrap.yml
Does the JHipster Configuration UI support updating configuration values?
I believe you are talking about the JHipster Registry. The purpose of this UI is to show you an aggregated configuration, which is efficiently loaded for some application. This is not really part of spring cloud config. The only 2 ways are filesystem or git repository.
But we are currently working on integrating consul as config solution as well. Consul itself does provide an UI to change config on the fly