Property in IntelliJ: driver-class-name or driverClassName? - java

I use IntelliJ IDEA, the IntelliSense suggests the usage of assigning jdbc driver in application.properties file as
spring.datasource.driver-class-name=com.microsoft.jdbc.sqlserver.SQLServerDriver
See the image when I typing
But by the answer, that is wrong. It should be
spring.datasource.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
However a web site related to JetBrains seems indicate that using driver-class-name might be correct.
https://youtrack.jetbrains.com/issue/IDEA-202820?_ga=2.207495315.1822682194.1613252382-718343134.1609267918
So I am confused. Which one is right? Is it a bug of IntelliJ IDEA?

Spring Boot supports both formats for properties, and they can be used interchangeably for properties defined by property binding (#ConfigurationProperties beans).
See also Relaxed Binding in the Spring Boot Features documentation:
Spring Boot uses some relaxed rules for binding Environment
properties to #ConfigurationProperties beans, so there does not need
to be an exact match between the Environment property name and the
bean property name. Common examples where this is useful include
dash-separated environment properties (for example, context-path
binds to contextPath), and capitalized environment properties (for
example, PORT binds to port).
In other words, given spring.datasource.driverClassName is defined through a #ConfigurationProperties bean, you can use both spring.datasource.driver-class-name and spring.datasource.driverClassName. The kebab-case form is the recommended form. The relaxed binding was - AFAIK - introduced in Spring Boot 2, so maybe the question you referenced was still at Spring Boot 1.x.
In any case, IntelliJ's autocomplete cannot be wrong in this case, because it uses information contained in the Spring Boot JAR files, generated by Spring Boot tools, specifically for spring.datasource.driver-class-name, this property name is obtained from META-INF/additional-spring-configuration-metadata.json in the spring-boot-autoconfigure JAR file. It is also the property listed in Common Application properties.
The Youtrack issue you listed seems to be an unrelated problem.

Related

How to Disable Spring Rest Docs

PROBLEM I use Spring Rest Docs in my project. It is useful at development stage, but i don't want it to be available for ordinary users and search engines in production.
RESEARCH I see no robot meta tags with content like "nocache" & "noindex". What is expected actually is maybe a spring application.property field like spring.rest-docs.enabled=false. So that I can configure it in production spring profile.
QUESTION How to disable rest docs for some spring profiles.
There were three ways to do it:
(failed) block a test with test-class annotations (couldn't setup it to work): #IfProfileValue(name = "spring.profiles.active", values = {"prod"}) or #EnabledIf("${spring.restdocs.enabled}")
(failed) configure maven-resources-plugin to work with maven-profiles and spring profiles (looked too cumbersome): https://stackoverflow.com/a/45817386/1112963
(worked) disable /resources/static folder access in application-prod.properties with spring.resources.add-mappings=false
You can add this property to your application.properties
spring.test.restdocs.failOnUndocumentedFields=false
spring.test.restdocs.failOnUndocumentedParams=false
https://scacap.github.io/spring-auto-restdocs/#_configuration
Configuration available during MockMvc setup:
failOnUndocumentedParams - if build should fail on at least one undocumented parameter
failOnUndocumentedFields - if build should fail on at least one undocumented field

Use Spring Boot with explicitly configuration

Is it possible to use Spring Boot so that all configurations are explicitly in the main class?
For example, is it possible to tell spring-boot to print all autoconfigurations make by #SpringBootApplication so that I can copy paste in my main class?
Or is it possible to copy then from somewhere into the main?
You can have Spring Boot create a report (a list of auto configurations) simply by enabling debug mode in your application.properties file:
debug = true
The auto-configuration report contains information about the classes that Spring Boot found on the classpath and configured automatically. It also shows information about classes that are known to Spring Boot but were not found on the classpath.
And, because you've set debug=true in application.properties or application.yml, so you will see it in your output.
There is no way of doing this. Either you embrace the devil and suffer the consequences latter if you need to personalize something unpredictable by spring boot developers or you don't use it's magic.

Disable Redis AutoConfig in spring boot when testing

I am trying to disable Redis when I am testing with spring boot. I have disabled my configuration but the auto config created a default connection and fails because it can't connect to a non-existent service. For testing I am content to just use a basic in-memory cache or a no-op cache. That doesn't work either. Here is what I have tried:
per this issue I added said configuration to my test app properties
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
But. That gets me a bit further. But ultimately I get a NoSuchBeanDefinitionException redisTemplate - this is because redisReferenceResolver is trying to look that up.
Looking at my debugger right now, the bean it's trying to hydrate is:
org.springframework.data.redis.core.convert.ReferenceResolverImpl which is coming from spring-data-redis:1.8.0.RELEASE which is coming from this dependency: compile('org.springframework.boot:spring-boot-starter-data-redis') . I admit, the bean name is a bit misleading. The type it actually resolves to is not
The only other reference to redis is in our hibernate support.
Can someone explain how to turn this off for testing?
Try excluding this two auto-configuration classes in your test properties file:
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
or
exclude
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
and set: spring.data.redis.repositories.enabled=false
With YAML syntax (& Spring Boot):
spring.autoconfigure:
exclude:
- org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
- org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
If you have SystemEnvironmentPropertySource in you app context you can use environment variable SPRING_AUTOCONFIGURE_EXCLUDE separating items with comma:
SPRING_AUTOCONFIGURE_EXCLUDE=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
Also try #EnableAutoConfiguration(exclude = {...}) on a #TestConfiguration annotated class.
If you dont want to change any files/code, you can also do this with an environment variable:
SPRING_AUTOCONFIGURE_EXCLUDE=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration

Adding properties to JHipster Cloud application.yml causes registry configuration to fail

I want to add a custom property to the application.yml of my Cloud Config. The comments in the file say it is for all shared configuration. However, when I do so, it causes the binding of the properties to JHipsters own ApplicationProperties to fail at the class does not have the correct writable property.
application.yml
application:
clients:
- Foo
Stacktrace:
Caused by: org.springframework.boot.bind.RelaxedBindingNotWritablePropertyException: Failed to bind 'application.clients[0]' from 'file:central-config/localhost-config/application.yml' to 'clients[0]' property on 'io.github.jhipster.registry.config.ApplicationProperties'
From JHipster's documentation:
Application-specific properties Your generated application can also
have its own Spring Boot properties. This is highly recommended, as it
allows type-safe configuration of the application, as well as
auto-completion and documentation within an IDE.
JHipster has generated a ApplicationProperties class in the config
package, which is already preconfigured, and it is already documented
at the bottom the application.yml, application-dev.yml and
application-prod.yml files. All you need to do is code your own
specific properties. (emphasis mine)
Have you done that step and added your own properties to ApplicationProperties.java? It looks like you should have a property of type List<String> clients. If you haven't that's why it's failing, because it's attempting to bind a configuration property to the ApplicationProperties class, but the class doesn't contain a property to store it.
Custom Spring boot properties should always be defined in a #ConfigurationProperties class within the app so that their value can be setup in the yml file. This is thoroughly documented in the spring boot documentation:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

Spring Boot application.yml and application.properties

I was trying to understand if I have some properties in application.yml and a few in application.properties will my application read from both these files?
According to Spring documentation - Change the Location of External Properties of an Application:
No matter what you set in the environment, Spring Boot always loads application.properties as described above. By default, if YAML is used, then files with the ‘.yml’ extension are also added to the list.
In which order properties are considered is explained in the chapter Spring documentation - Externalized Configuration.
If in doubt what files have been loaded I recommend to set the log level to DEBUG which shows the loaded configuration files in the log.
There is a good article here, that describes how both of these can be read using the #ConfigurationProperties annotation.
#ConfigurationProperties supports both .properties and .yml files.
#ConfigurationProperties support JSR-303 bean validation – javax.validation
Hope this helps!

Categories

Resources