I am doing a authorization in Spring Boot. I need a config file to save allowed group for each service. When Spring run, these data will be loaded in cache. Saved in things like
Map<String_serviceName,Set<String_allowedGroup>>
I have a naive method in mind, create a config.properties. Save these in format like:
my.service.service_1=group_1,group_2,group_3...
my.service.service_2=group_1,group_2,group_3...
...
Is there any better way? Or it's enough for this need.
This will work no doubt.
For better readability of your config you may consider using a yaml.
Although, below are my suggestions if you haven't tried them already
user application-.yaml for have env specific configs Use
spring's #ConfigurationProperties to map the entries directly to the objects
(if possible) Use a DB table to store the configs
Related
I was reading baeldungs article on configuring datasource programmatically. There is a particular comment which confused me. Can someone please explain with an example what the author meant here. Thanks in advance.
It is in context of Externalization not Datasource specifc. In which you put your application related parameters outside the code files using .properties, .xml or .yml config files. It allows you to configure your application without compiling. If you want to change, you just have to change the values in config file and application will behave as per provided values no need to recompile.
We normally externalized properties for Datasource, Connection Pool, Logging configuration, Endpoints and many more.
For example in case of Datasource configuration you can pass DB url, username, password in external configuration file instead of code and refer those values through keys. So in future if the datasource url changes you just have to make change in config file. Otherwise you would have to make changes in code which would need recompile and rebuild your application for changes to be effective.
But also take into consideration of sensitivity of values too for which there are some techniques which i believe outside the scope of this question.
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 need a why to change the JPA catalog element in my java class? We have many database environments which we need to be able to deploy our application too. Example: In your dev environment we have a database for new development, and production support. All database live on the same server so we have the following database names: am_web_dd and am_web_ps. So we need to be able to change the catalog at build time or start up time. We've thought of using Maven to do a search and replace during build but I was wondering if there is a way of doing this with a parameter?
Here is one of our #RooJpaActiceRecord statements:
#RooJpaActiveRecord(catalog = "am_web_t4", schema = "dbo", table = "user_t")
I would like to be able to make catalog a parameter. Is this possible? if not what would be the best approach?
Thank you for your time!
I know it is possible from a JPA standpoint, but I don't think you will be able to using straight Roo. This might help.
There may also be a way to use a Java Configuration object in Spring to build your JPA Entity Manager. I think that's were you want to set it.
The approach you suggest of making catalog dynamic would be suitable if you wanted to let the user choose/change the schema on demand, however, it looks like this is not your requirements, so I would steer away from this path as it more difficult than you need.
You can use spring profiles to define different database connections and use an environment variable to define which one is active. Spring profiles can be set in XML or java configuration classes.
I have a spring based web-application that needs to get data from ActiveMQ via a JMX connection.
I am using MBeanServerConnectionFactoryBean (in Spring) to get various MBean attributes from ActiveMQ.
I have only one MBeanServerConnectionFactoryBean as a member variable, which is used to get the data. If multiple requests/threads come concurrently will there be any issues? Will there be any race conditions?
Please suggest the best way to keep the code thread-safe.
Spring FactoryBean objects are not intended to be used directly from your code, they're supposed to be used in your Spring config. As such, they are designed to be executed once and once only.
If you want to use them, including MBeanServerConnectionFactoryBean, then you need to create them, configure them, use them and discard them each and every time you want to get the object they create. They are most definitely not thread-safe.
Better yet, do it as the design intended and use them in your Spring config.
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