I'm working on a SpringBoot (2) application. I'm looking at our properties files which have become a bit convoluted and I'd like to tidy it a little.
In deployment we have a small main/resources/application.properties file which contains a few defaults and an external property file which contains a lot of other properties. This works well... and I'm trying to replicate this in dev and failing and I'm hoping I'm doing something silly which someone can point out painlessly.
As I understand it by default, Spring Boot will look in various places for the properties, in this order...
classpath root
/config in classpath
in the current directory
/config subdirectory of the current directory
Using Intellij I can't get SpringBoot to pick up 2 locations though. If I put all properties in main\resources\application.properties then that's fine. If I use -Dspring.config.name=dev and add a dev.properties with all properties this works well but I can't seem to configure a split in debug between defaults in main\resources\application.properties and a simulation of the external file somewhere else in the project (so that it won't get packaged in the jar).
Is there a simple way to do this, or any good documentation somewhere that I've missed that would explain it well enough that I might be able to simulate it in the dev environment ?
Related
I am working on building a SpringBoot app with my workmates. We all have different preferred logging levels for the app. We have been battling back and forth with each other's logging changed to application.properties. Is there a way to move all of the logging.level.* stuff out of that application.properties file and into a ~logging.properties file or something? That way we can add that file to the .gitignore and not track that file so we can each leave our logging alone. We are using Java annotations and not xml btw.
I've tried adding #PropertySource("classpath:logging.properties") to the application file, but I read somewhere that the logging gets setup early on in the init process and this won't work. I tried it anyway and it doesn't work (so confirmed I guess).
I can't believe there's isn't more info on this out there.. I'd imagine the members of a dev team each want their own custom level of logging and don't want to keep stepping on each other's toes/commits.
You can just override it using a command line property. The fallback strategy will take command line -D args as the highest overriding priority.
https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-external-config
I would recommend to have logback.xml file inside resources/ with some defaults that works for everyone (more likely to the application in question) and then you can provide --logging.config=/path/to/your/very/custom/logback.xml file whenever you start the application locally.
That should work for everyone.
New to Spring Boot here, long-time Spring Framework user though.
I'm looking for a way to split my externalised configuration into multiple .properties files, for better readability and manageability.
I already saw this SO answer: having the ability to specify a list of configuration file names in spring.config.name (which, by the way, doesn't seem to be mentioned in Boot reference documentation, correct me if I'm wrong) would solve my problem perfectly, however that configuration property can be specified only via system properties or environment variables. If I try to specify it inside my application.properties file, it gets ignored. The same happens for spring.config.additional-location. I understand this happens because, when application.properties is read, it's too late to tell Spring Boot to search for different externalised configuration file names. However this is not a proper solution, because the way I split my configuration should be an "implementation detail" that the consumer of my application shouldn't be aware of, so I don't expect the consumer to specify an external parameter otherwise my application breaks out-of-the-box.
I think that a way to do this should be provided. Perhaps some import mechanism for .properties files or the ability to specify spring.config.name even in application.properties (some known and reasonable limitations would be acceptable).
The best I could find out is to use #PropertySource, but this is not profile aware: unless you use some ugly nested class hack, or you put spring.profiles.active variable in the resource name (which will break if multiple profiles have been activated), you won't get the benefit you have for application.properties profile-specific files.
I was not able to find an "official way" to do this, apart from some statements from Spring Boot devs that say that they're rather promoting the use of a single (possibly giant...) externalised configuration file. It seems like this position is not so popular, judging from the post reactions on GitHub, and IMHO it really seems to be a basic feature missing. I have been working with multiple properties files in Spring Framework (using XML configuration) for years and I never felt that having an only huge file would have been better.
If I understand it right, in Boot 1.x this was in some way possible using the location attribute of #ConfigurationProperties, which is however missing in Boot 2.x.
Any suggestion?
Have you tried with Spring Profile?
What you can do is create application-file1.properties/yml, application-file2.properties/yml and put it in config location and then add spring.profile.active=<your env profiles>,file1,file2.
It will load the files.
This profile entry can be in bootstrap.yml, or JVM args to application, in Manifest-<env>.yml in case of Pivotal Cloud Foundry. Not sure on AWS and other cloud provider.
Hope this will help.
I am using log4j2 in my spring boot application. This works in all respects re: excluding slf4j, including log4j2, etc.
But when the application deploys I need to customize the file for each target host. I have created an ansible role that does this. Ultimately I end up with a log4j2.xml file deployed in another directory e.g. /prod/produsrX/data/log4j2.xml.
I am using the spring-boot-maven-plugin "repackage" goal to generate an executable jar file. It doesn't seem like that should matter but it is a data point in the problem.
This was supposed to be the easiest part of the project. Always before I have just been able to set -Dlog4j.configurationFile - advice which is echoed on about 3,000 web pages and DOES NOT WORK in Spring Boot 2.1.3.
The most useful info I've found is this question. It talks about using -Dlogging.config because logging must be initialized before other properties are read. Unfortunately that didn't help either.
I did find one example that suggested specifying the above directory in a -classpath parameter to java. But that didn't help either.
Does anyone know how to get a spring boot application to read the log4j2.xml file?
The property actually has to be put into the application context (e.g. application.yml). Using a -D property does not work!
logging:
config: /prod/produsrX/data/log4j2.xml #fully qualified name to your log4j.xml
I have a Gradle based Spring Boot application which requires an external properties file. Fortunately, Spring Boot automatically looks for an application.properties file in a /config folder by default, so I put that in the module root and it works fine. However, it seems that IDEA's inspection is marking everything in this file as "Unused Property". If I move the file to /src/main/resources the inspections work properly.
So, what is the best practice when working with these external properties files? Is there something I can set in the build.gradle to get IDEA to recognize the properties or some setting in IDEA? I've tried playing around with the Spring Facets in the project settings, but can't seem to figure it out.
Thanks!
I'm having a stupid configuration issue with Ibatis in my Spring project. Please don't jump on me about how all this was setup, I'm just following the "in house project structure policy".
So here is the structure, we have the "src/main/resources/META-INF/" folder that contains all of our config files used by the application, and then there is a "src/test/resources/META-INF/" that contains only the config files that have different settings to run unit testing.
Well in our case that's only one file, the src/main/resources/META-INF/spring/application-config.xml became the src/test/resources/META-INF/spring/test-application-config.xml. I'm am not going to outline the small differences between the two, because that part works fine.
The test-application-config.xml imports the src/main/resources/META-INF/spring/data-access-config.xml file just fine, which in turns use the src/main/resources/META-INF/ibatis/sqlmap-config.xml successfully... After that is when it goes to Hell.
See up until now we're using Spring to find the next config files in the classpath, but when we hit sqlmap-config.xml we leave the spring framework for the ibatis framework I believe, which loads the resource files defined inside it relative to the classpath (that's taken from the doc, whatever that means).
Inside the sqlmap-config.xml are defined a few resource files we're using that live inside the src/main/resources/META-INF/ibatis/mapping folder.
They are referenced like this:
<sqlMapConfig><sqlMap resource="/META-INF/ibatis/mapping/MyObject.xml"/></sqlMapConfig>
That works fine when I run the app normally, but when I run my JUnit test cases I get an IO exception stating that it can't find the file /META-INF/ibatis/mapping/MyObject.xml.
I've tried to change the path in the sqlmap-config.xml to "mapping/MyObject.xml" but that didn't help. I've also tried to use the Spring classpath prefix "classpath:META-INF/ibatis/mapping/MyObject.xml", didn't work either.
Anyone would have any idea on how to set that Ibatis properly so it works for both the app and the junit?
Thanks.
To solve this problem, I removed all the the Ibatis files and folders from the src/test/resources/META-INF folder.
The sqlmap-config.xml in src/main/resources/META-INF/ibatis/mapping file now maps like this:
<sqlMapConfig><sqlMap resource="META-INF/ibatis/mapping/MyObject.xml"/></sqlMapConfig>
Please note that compared to my initial post the leading "/" is gone... I think that's what made the difference here.
Hopes this helps anyone running into similar issues.
Just to see whether what you are saying is actually the problem.. you might want to place your mappings (MyObject.xml) in the same folder as sqlmap-config.xml. I say this because I've had my fair share of spring + ibatis + unit testing problems. (see resolved question asked by me)
Also, you might be getting IO exception because the mappings file does not exist outside the container (when you run tests).
You should also post definition for bean created from SqlMapClientFactoryBean. This should have configLocation property that contains path to sqlMapConfig xml
I had the same problem and could not find a (quick) solution that explained what exactly could be going wrong. Hence my answer.
As Spring documentation for Ibatis says:
Remember that iBATIS loads resources from the class path, so be sure
to add the 'Account.xml' file to the class path.
In your case by adding META-INF to your webproject build path i.e. if you used Eclipse, set <classpathentry kind="src" path="META-INF"/> in your projects' .classpath (This will be visible under Navigator view in Eclipse)