I am looking at externalizing certain configuration parameters for ehcache in our Grails application and I am running into something not working that the documentation claims ought to.
Likely there is something I am missing.
I am using the grails ehcache plugin version 1.0.1 with Grails 2.4.0 and grails cache plugin 1.1.7. I am using hibernate plugin 3.6.10.16.
Here's what I have in my CacheConfig.groovy configuration...
...
cacheManagerPeerProviderFactory {
peerDiscovery 'automatic'
factoryType 'rmi'
multicastGroupAddress '${ehcacheMulticastGroupAddress}'
multicastGroupPort '${ehcacheMulticastGroupPort}'
timeToLive 'site'
}
I've turned on debug-level logging so I can see what XML it generates. Here's the relevant snippet:
<cacheManagerPeerProviderFactory class='net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory'
properties="peerDiscovery=automatic,multicastGroupAddress=${ehcacheMulticastGroupAddress},multicastGroupPort=${ehcacheMulticastGroupPort},timeToLive=32"
propertySeparator=','
/>
The grails ehcache plugin documentation has the following note, which I was hoping to "prove out"...
(note that ${ehcacheMulticastGroupAddress} and ${ehcacheMulticastGroupPort} are an Ehcache feature that lets you use system property names as variables to be resolved at runtime)
Great. Except that it doesn't work when I start the application. It fails to create CacheManagerPeerProvider due to the following
...
Caused by UnknownHostException: ${ehcacheMulticastGroupAddress}
->> 901 | lookupAllHostAddr in java.net.InetAddress$1
...
I have a myApplication-config.groovy file living in an accessible area that I point to when assigning a value to grails.config.locations in Config.groovy. But I am not sure it is making any effort to really interpolate that value at all.
I tried double quotes but they were a bad idea as well -- at the time of interpreting CacheConfig.groovy it doesn't see the configuration I put into myApplication-config.groovy. I do know it reads that file in successfully at some point because I successfully use it to drive some Quartz job logic, so the placement of that config file is probably not the issue.
The answer is that I need to set SYSTEM PROPERTIES for ehcache to find. Using Grails configuration files such as myApplication-config.groovy is completely incorrect.
The CacheConfig.groovy file is correct, as is the XML it generates. So the question becomes, how do the properties it looks for get set correctly in the first place?
I am deploying to Tomcat. For Tomcat, setting system properties makes the most sense in a setenv.bat file (or setenv.sh on *nix).
I created setenv.bat, put the following into it
set CATALINA_OPTS=%CATALINA_OPTS% -DehcacheMulticastGroupAddress=230.0.0.1 -DehcacheMulticastGroupPort=4446 -DehcachePeerListenerPort=40001
...And it worked. Ehcache was able to find the system properties and start everything appropriately.
tl;dr: system properties != grails application config
Related
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
Summary: I'm trying to access project properties (such as the version) in Java, and everywhere I've read says I need to expand properties in my build.gradle file. That's all fine and dandy, but I'm using LDAP and am configuring it in my properties file. Whenever I try to expand properties, I get the LDAP error 49 52e (Invalid Credentials), so it seems that whatever Gradle does to process the properties warps the LDAP properties so they are no longer usable.
Project Info:
I've outlined what I've thought to be the applicable project info below. If there are further details needed to determine the issue, comment and I'll add them.
Language:
Groovy 2.4
Java 8
Framework:
Spring Boot version: 1.3.1.RELEASE with starter POM
spring-boot-starter-security included
spring-security-ldap included
Build Tool: Gradle
Version 2.3
Spring Boot Gradle Plugin 1.3.1.RELEASE
Applied Plugins:
groovy
spring-boot
Build Info: I've tried a few different configurations in my build.gradle file to acess the version, but the moment I add the 'processResources' block, I can no longer access LDAP when running the application. The application runs and authenticates just fine without a 'processResources' block, but as soon as I add it, it will run, but I can't access anything due to LDAP complaining about invalid credentials. I tried 3 different expand configurations and all behaved this way.
Build Config Attempt 1:
processResources {
expand(project.properties)
}
Build Config Attempt 2:
processResources {
filesMatching('**/*.properties') { expand(project.properties) }
}
At this point it occurred to me that I'm configuring my LDAP login in a properties file, so maybe the solution was to avoid properties files altogether. I found out that you can supposedly just expand the properties you need, so I tried the following.
Build Config Attempt 3:
processResources {
expand projectVersion: project.version
}
As stated before, all of the above attempts failed and I still got LDAP authentication errors for each of them. A build.gradle file without a 'procesResources' block seems to be the only way to keep LDAP happy.
Properties Info: As stated before, I configured LDAP information in my properties files. Below are the relevant properties.
application.properties
spring.profiles.active=localdev
ldap.securitygroup=DEV
logout.path=
host.securePort=
As you can see, I'm using a localdev profile, so I've included the applicable properties from it below. Since it included sensitive information, I've only specified the property names and not their values. I've used a star (*) to indicate that there was a non-empty value provided. (in the above application.properties file the values were indeed empty for a couple of the properties listed):
application-localdev.properties
host.securePort=*
ldap.username=*
ldap.password=*
ldap.base=DC=*,DC=*,DC=*
ldap.roleSearchBase=OU=*,DC=*,DC=*,DC=*
ldap.defaultUrl=ldap://*
ldap.urls=ldap://* ldap://*
The properties didn't change at all, it just all worked without the processResources block in the build.gradle file, and then didn't when I added any of those 3 versions of it.
Any assistance to help figure this help would be greatly appreciated, and if any further information is needed, let me know and I'll update this.
So a co-worker gave me a great tip and said I could check the properties in the JAR file to see if there were different from what was originally specified.
Long story short, when I don't have a processResources block in the build.gradle file, the properties don't change and everything's happy. However, when processResources is added, ESCAPE CHARACTERS ARE REMOVED, causing the username to change, since I had an escape character in it.
The workaround I'm now using is to double up on the escape characters, which seems like a hack to me, so if there's a better way to configure this, please reply!
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.
I'm using Spring 2.5.6. I have a bean whose properties are being assign from a property file via a PropertyPlaceholderConfigurer. I'm wondering whether its possible to have the property of the bean updated when the property file is modified. There would be for example some periodic process which checks the last modified date of the property file, and if it has changed, reload the bean.
I'm wondering if there is already something that satisfies my requirements. If not, what would be the best approach to solving this problem?
Thanks for your help.
Might also look into useing Spring's PropertyOverrideConfigurer. Could re-read the properties and re-apply it in some polling/schedular bean.
It does depend on how the actual configured beans use these properties. They might, for example, indirectly cache them somewhere themself.
If you want dynamic properties at runtime, perhaps another way to do it is JMX.
One way to do this is to embed a groovy console in your application. Here's some instructions. They were very simple to do, btw - took me very little time even though I'm not that familiar with groovy.
Once you do that you can simply go into the console and change values inside the live application on the fly.
You might try to use a custom scope for the bean that recreates beans on changes of the properties file. See my more extensive answer here.
Spring Cloud Config has facilities to change configuration properties at runtime via the Spring Cloud Bus and using a Cloud Config Server. The configuration or .properties or .yml files are "externalized" from the Spring app and instead retrieved from a Spring Cloud Config Server that the app connects to on startup. That Cloud Config Server retrieves the appropriate configuration .properties or .yml files from a GIT repo (there are other storage solutions, but GIT is the most common). You can then change configuration at runtime by changing the contents of the GIT repo's configuration files--The Cloud Config Server broadcasts the changes to any Client Spring applications via the Spring Cloud Bus, and those applications' configuration is updated without needing a restart of the app. You can find a working simple example here: https://github.com/ldojo/spring-cloud-config-examples