In spring boot 2.4, later loaded properties override earlier properties.
But, for my need, I am importing document inside document using spring.config.import. Say, import abc.properties from application.properties.
But, I need to override, later loaded properties with earlier loaded ones.
Say, application.properties should override abc.properties. not the other way arpund.
Please help me on how to do this.
Thanks in advance.
I resolved the issue with EnvironmentPostProcessor, as it seems to be not doable simply with spring.config.import.
As, both yaml (and in terns json) and properties, property source parser is readily available in spring boot, this required very little coding.
Related
I learning Spring boot and found that in some examples use the same properties with the prefix spring.jpa.properties while other do it without prefix.
For instance:
The article explains second level cahche https://www.baeldung.com/hibernate-second-level-cache and autor shows example of needed properties ( example on autor's gitHub):
hibernate.cache.use_second_level_cache=true
hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
But it did not work for me, and I spent few hours loking for the reason, but then i noticed, someone use prefix spring.jpa.properties. to get it working (Exact moment from video lesson):
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
Which perfectly worked for me.
So my questions are:
why are they working in different way?
how to understand which properties in which cases requires this prefix?
is it probably something related to my project settings OR Spring Boot version?
any other suggestions are appreciated :)
Thank you in advance!
There are a couple of things in play here. First the tutorial you use is using plain Spring not Spring Boot. Which means a manually configured EntityManagerFactory on which you directly can set the provider specific properties. Like hibernate.cache.use_second_level_cache.
As you decided to use Spring Boot you don't have a manually configured EntityManagerFactory (although you could!). Which means you are using an autoconfigured EntityManagerFactory. Properties for this reside in the spring.jpa namespace for properties.
As it isn't feasible to specify properties for each and every extension for Hibernate (or other JPA providers) only some commonly used ones are exposed like spring.jpa.generate-ddl and a few provider specific ones in the spring.jpa.hibernate namespace. However to set all the other properties in an autoconfigured way there needed to be something else. Hence the spring.jpa.properties prefix. Anything specified in there will be passed on as is (without the said prefix ofcourse) to the EntityManagerFactory for configuration.
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.
It looks, from the source code, that Katharsis-spring module will only work with spring boot.
My question then, is it possible to configure a spring project in xml and load Katharsis without spring boot?
If so, how would you need to configure katharsis in spring xml?
Has anyone done this before and willing to share an example?
Thanks.
Only work with Spring boot? That doesn't seem possible. Just #Import(KatharsisConfigV2.class) on any configuration in your code and it should work.
As for xml config: By design, if it can be done in code it can be done in config.
Try that and let me know how you make out
With version 2.8.1 of katharsis, it is quite a challege to get this configured just in xml. So I looked at the master branch of the project and found that there are going to be some new features which will make it easier to configure with spring xml. I have created a sample project here you can use as reference for configuration:
Sample Spring/Katharsis Project with XML configuration
In the sample project I added the SpringServiceDiscovery class, and modified the KatharsisBoot class to make the configuration easier. With the next release of this project, I should be able to remove these 2 classes completely, and use the classes that come with katharsis.
The beans I needed to add to my root-context.xml file were the following:
io.katharsis.spring.KatharsisFilterV2
io.katharsis.spring.ErrorHandlerFilter
com.springkatharsisxml.katharsis.boot.KatharsisBoot
io.katharsis.queryParams.QueryParamsBuilder
io.katharsis.resource.registry.ConstantServiceUrlProvider
io.katharsis.queryParams.DefaultQueryParamsParser
io.katharsis.module.CoreModule
io.katharsis.resource.field.ResourceFieldNameTransformer
io.katharsis.spring.boot.KatharsisSpringBootProperties
I also needed to expose the jackson objectMapper bean, as it's not done so by default in xml.
I also used the org.springframework.web.filter.DelegatingFilterProxy for the katharsisFilter and errorHandlerFilter.
My project creates war files that get deployed in different tomcat instances. Instead of using properties files in all of these locations and remembering to update the property values in these files we extended Springs PropertyPlaceholderConfigurer to read properties from a Mongo. This works well for our java/spring based wars. The problem is trying to get our grails applications to use this bean. I have included the bean in the spring/resources.groovy(or xml) but grails does not honor the bean and it gets overridden (or overlooked) with it's own GrialsPlaceholderConfigurer. Is there a way to tell grails to use our own Configurer?
Seems that it's possible from grails 1.0. I never used it but adding the following code in your configuration should work:
beans {
addBeanFactoryPostProcessor(new PropertyPlaceholderConfigurer())
}
See also this test in the grails source code base.
I was able to solve this by just creating a bean. The original developer didn't understand Grails. Once I really looked at it I was able to the custom Configurer to work.
Can anyone tell me what the best strategy to validate a spring configuration file against the spring-beans.xsd that is included with the spring-beans.jar. Can I have the schemaLocation in the XML header reference file:/org/springframework/beans/factory/xml/spring-beans-2.0.xsd?
The best way is to use the Spring IDE and it will perform the validation during dev time. Also, spring auto validates all the config files (from the XSD that comes bundled with the jars) while it is loading them.
ok here is the deal.... Eclipse uses plugins like spring IDE or spring STS that have spring bean validators in them.
There is an issue When the new versions of spring components come out the xsds do not appear to be in the eclipse plugins validators ahead of time. So eventually they create bug or enhancement requests in the projects JIRA system and they are put in in a new release/update. You can vote on these bugs to let them know there is demand to get them in faster.
There is also a work around to use in the interim in this old blog post by Craig Walls
http://www.springone2gx.com/blog/craig_walls/2007/08/fixing_spring_modules_xsd_errors_in_eclipse