I'm a beginner with spring boot and java. My question is what is recommended to store Environment configuration details such as bigquery database name, aws service unqiue ids which are used in my project.
So, It is better to store in a class which is in core project or it is better to store in application.yml file
Because spring boot is so lightweight, a lot of projects use Spring boot for microservices. and in a microservice world, it's best and almost needed to store your configs in a centralized and secure place, so you can change any of them when you want.it's hard to save them in Java classes but you can easily save them with .yml or properties. in almost all cases .yml files will be better.
I think there are some options to save the information of the configurations in an application. One of them is use a *.yml to save all the information because you can have different configurations each of them per environment
Related
I checked a lot of answers but I didn't understand most of them, so please bear in mind that I'm very new to programming and Java.
So, I was following this tutorial: https://medium.com/#fsonmezay/restful-issue-tracking-application-with-spring-boot-and-angularjs-61b69537b10e
But as noted in that, everything I do on the UI while the app is running disappears when I close the app.
It uses HSQLDB as the database manager, and I need the app to write on the database everything that I add while it is running.
Also, don't know if it's worth mentioning but instead of using maven, I'm using Gradle.
By default, Spring Boot autoconfigures in-memory HSQLDB connection, so all data obviously will be lost. You need to provide spring.datasource.url configuration property to override automatic configuration and use persistent data connection, for example spring.datasource.url=jdbc:hsqldb:file:~/mydb property will store your data into ~/mydb file. Take a look at Spring Boot documentation for more information on data source autoconfiguration and HSQLDB documentation for more information about HSQLDB configuration properties.
Background
I have built a console java application using kotlin and gradle.
The gradle file creates a fat jar which I can run from the command line using
java -jar <project>.jar
The jar contains the application.properties file from which properties are read.
Problem
I would like to specify on the command line that the application.properties file should be read from some external path.
When using spring boot, I have used
java -jar -Dspring.config.location=somepath/application.properties <project>.jar
and this works.
But it does not seem to be working in the non-spring boot application
Question
Is it possible to specify external configuration on the command line for non spring boot applications?
Spring boot has a whole chapter in the documentation which deals with various ways of configuration.
Obviously if you don't have spring boot you should implement something similar to it by yourself.
First thing you should decide - at which level you need the configuration to be integrated into your application:
Do you only want to read the key/values from command line or maybe rely on environment variables or system properties?
In general, what is the source of your configuration: Yaml? Properties file? maybe consul or etc.d?
Do you want to create a java object that reflects the configurations that you've read (like classes annotated with #ConfigurationProperties in spring boot do?
Do you want to support only one source of configuration or you want the various sources of configurations to be supported?
If you ware using Spring, do you want configuration properties to be automatically injected into beans?
If you're planning to use properties/yaml (like application.properties in spring boot) - where do you want to place them? Non spring boot application won't read them "auto-magically", you'll have to implement this logic.
Are you planning to deal with profiles (non-spring-boot application still supports flavors of loading different beans depending on specified profile).
Spring boot has answered all these questions and more.
Here are some options that you might want to give a try to if you're running outside the spring boot context but still have spring application:
Since spring 3.1, I guess, there is a#PropertySource annotation that you can use to make spring load properties from the file in the classpath or some "place" in the filesystem. This article summarizes the usage of this method as well as compares what spring boot has up on its sleeves as opposed to regular spring application. This is also a nice tutorial that covers regular spring features.
Something out of spring eco-system but still can be useful: apache common configuration project. There are some workarounds to integrate it with spring application, see here
Considering all the answers here I concluded that though it is possible to enable external configuration in applications that are not spring boot, it does require some effort.
Therefore I decided to use Spring Boot in the container.
What is the best procedure for storing configuration data?
I have several classes that require some configuration data that is only needed in their class.
Should I load all this data from a configuration file or should I hardcode it into the classes?
Many thanks in advance
To address your question:
Should I load all this data from a configuration file or should I hardcode it into the classes?
Basically if you hard code some value into the class, you don't intend to change that value in different environments. Each such a change would require re-compilation of the project.
For example if you have a constant for PI=3.14 it doesn't make sense to use different values for different environments.
Alternatively if you go with configuration files, the update of such a file that can be supplied with a deployment script is much easier.
An example of this can be a host/port of the database. Development might use one host, production might use another.
So you should decide what works for you best.
This is common for all types of applications (not only spring boot driven).
Now its true that in spring boot you can create a configuration file (properties or yaml) and place it into the artifact (by putting it into src/resources/ or src/resources/config).
For some situations its good enough, for others you might use another way of configuration.
I don't refer managing secrets here, this is a more advanced stuff, but in general you won't want to manage things like passwords neither in the source code (hard coded) nor in the configuration file.
We have a java web project with initial configuration in Spring applicationContext.xml. Please don't write that it is old style, I know.
Part of this configurations can be change vs admin panel of the application and we need to backup it from time to time.
Does spring have something like applicationContext.saveBean() or any any other way to save configuration objects into XML using Spring beans?
You can use Spring caching with Ehcache:
https://github.com/eugenp/tutorials/tree/master/spring-all
You are getting the option of caching on disk stores.
You also can persist your beans as java serialized objects.
Of course this doesn't generate an xml readable output.
I created a java web application using Spring Roo as the persistence layer and MySQL as the database.
I'll have several customers using that application but it has to be one database per customer. I mean, the same database structure for everyone but having one database(schema) per customer. So how to do that using the current technologies in my application?
I was thinking of something like a URL parameter indicating what schema to use, for example:
Customer 1 should use: http://www.myapp.com/?schema=dbcustomer1
Customer 2 should use: http://www.myapp.com/?schema=dbcustomer2
So now I'm wondering how to pass that schema param value to the Spring Roo's database connection at runtime. Currently it's hard coded in the database.properties file generated by Roo?
Please, also let me know if you think there is a better approach to achieve that.
Thank you,
Gyo
You can customize your Spring Roo application just the way you approach multi-tenancy in a traditional Spring based application.