ConfigJSR
ConfigJSR copied to clipboard
eclipse
Think about how and if to support a ProjectStage
I would vote for other features, such as the change notification instead. Not that I isn't useful, just about priorities. If I think about real-world scenarios, reloads would IMO help more, e.g.
I never used a ProjectStage (https://deltaspike.apache.org/documentation/projectstage.html) but what I find quite useful are the profiles in Spring. From my point of view this is more or less the same (don't hit if I'm wrong). I'm currently use this feature often to have different properties for a spring service in Docker / in IDE. So a +1 from me.
Yes, AFAIK this is more or less the same than Spring profiles.
This is my point, for enterprise environments at least, that profiles are not a best practice (anymore). We don't want to ship applications that include all configuration permutations for all envs and then decide at runtime, within the application / runtime. Instead, we want to define the (few) parts that are different from the outside and inject the proper configuration then, i. e. via Docker environment variables, volumes, Kubernetes config maps, etc. That means the application includes and "sees" only the final set of configuration values, which are then easily usable by our JSR.
This matches the idea of 12-factor applications of "store config in the environment", see https://12factor.net/config
This is why, at least for modern enterprise environments, I discourage the use of profiles, thus I wouldn't support it (initially).
I agree with @sdaschner , a ProjectStage promote internally configuration. But developers use this system. if that can permit that they don't build artifact per environment So a +1 from me
@sdaschner This do not help in non server environments like Java based command line tools or desktop clients ;)
Discussed today in the weekly:
The preferred way is to simply have a key - value pair that defines the currently profile / stage. This one needs to be added as an argument (for example java.config.stage) to the app. Based on this we only need to define the key name and the pattern how the properties file needs to be named. No specific API is needed.
Based on this we only need to define the key name and the pattern how the properties file needs to be named. No specific API is needed
About that, i think spring uses a very nice and clear way to define a Stage(profile) property file that is application-${profile}.properties. So if a dev profile is passed as parameter when the application starts up the application-dev.properties is loaded.
Let's discuss naming:
I would prefer javax.config.stage or javax.config.profile as name for the param key to define the profile.
I really like application-${profile}.properties for the config file. As described in #31 the property file name is currently different. So at the moment it would be META-INF/javaconfig-${profile}
In general I think that profile is a better naming than stage. But maybe this is related to the Spring Boot stuff I did the last 3 years.
@jeyvison and how to tweak those settings via env or -D? This way is not really well thought through I fear. In DeltaSpike we used a postfix
some.server.url vs
some.server.url.Production
As deltaspike, have we a list of stage ? or name is completely free ? it's perhaps the different between stage and profile
I prefer multi-file for stage or profile.
But file javaconfig-${stage or profile}.properties overload properties of file javaconfig.properties We can have only specific properties by this profile or stage
wdyt ?
@struberg We could load the files depending on the pattern(i.e *-dev.properties). If we just use postfix, we may end with a very big file with different configurations for different environments. It may work for small-medium projects, but for large projects this file would be hard to manage.
@lilian-benoit
But file javaconfig-${stage or profile}.properties overload properties of file javaconfig.properties We can have only specific properties by this profile or stage
Totally agree with this approach. This way we can specify even more what are general and enviroment-specific properties
just a bump that the ConfigJSR now has some notion of project stage as mentioned in https://github.com/eclipse/ConfigJSR/blob/25edda2914155ac6b30f821f9ef13e92b7350a3a/api/src/main/java/javax/config/ConfigAccessor.java#L172.
@struberg I'm not sure whether that was intentional to have it with ConfigAccessor API or if that should have been added by a subsequent PR as there are still some disagreement with that feature as discussed in this thread.
