ConfigJSR
ConfigJSR copied to clipboard
eclipse
discussion of name and location of default property file
Based on https://github.com/eclipse/ConfigJSR/issues/26 I had a look at the spec and saw that we currently define the default config properties file as META-INF/javaconfig.properties. Actually I'm not really happy with the name and the place. I think that the META-INF folder is a valid option but would prefer to add support for a properties file in the root folder (conflicts can be handled by ordinal). Next to this I ask myself if javaconfig.properties as a name really makes sense? Why not using something like application.properties (as spring does)?
I'm rather -1 as this would mean we would accidentally pick up spring config files which have different semantics than we do. META-INF is also perfectly fine imo.
If one wants to pick them up he can simply define an own ConfigSource for it anyway
META-INF is fine, yes. But I think it would make sense to support root folder, too.
ok, application is already used by spring. Actually I ask myself what different semantics a spring config file has? Isn’t that the same property file format that we support?
Am 01.12.2017 um 10:04 schrieb Mark Struberg [email protected]:
I'm rather -1 as this would mean we would accidentally pick up spring config files which have different semantics than we do. META-INF is also perfectly fine imo.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eclipse/ConfigJSR/issues/31#issuecomment-348440739, or mute the thread https://github.com/notifications/unsubscribe-auth/AJAaB3Qzx8HzRMZUyG4W85rK7uc1lEtpks5s78EjgaJpZM4Qx-D6.
I also prefer application.properties over javaconfig.properties TBH. I would argue you are configuring the application, not the JavaConfig functionality :-) I also don't think that it is a problem to put in into the root classpath folder. I mean it's the goal of this JSR to become the single point of configuration that accesses properties files.
I prefer using META-INF. Here is a extract from guide jar :
The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services
For application.properties, i am fear that confusion with spring config We can use a generic term from javaconfig.properties to configuration.properties.
+1 to load files from root. META-INF is a valid location but we can consider these two locations as a hierarchy structure for properties
+1 to application.properties or configuration properties although i would prefer application.properties. Is there any problem if we load the Spring properties?
-1 to pick up from root. You can write your own config source to parse this file. The default one on the classpath which means META-INF for jar, WEB-INF\classes\META-INF for war. It is nice and clean. Also it is very similar to CDI's beans.xml location.
ack to what Emily writes. Also -1 to pick up from root. Basically all EE config files are located in META-INF/ or WEB-INF/
Btw, we explicitly left out WEB-INF/javaconfig.properties btw. Don't want to repeat the merge nonsense we had to do in CDI.
Also ack to not using application.properties as this would create a big mess with Spring.
@sdaschner suggests to change the file name javaConfig.propertie to application.properties. The properties can be loaded by either Spring or JavaEE config impl. I think it is a good idea.
If the Spring folks are not offended, why not, but doing a bit with Spring Boot and different types of clouds myself, the concept of profiles would probably exceed this JSR, so a multi-profile Spring configuration or overrides just won't be picked up correctly?
Sorry @sdaschner @Emily-Jiang , but name change is not sufficient. Spring loads property file in root folder (doc) Personnaly, i prefer META-INF location. It's common on Java EE config file.
We must decide if we support spring model or not. In ConfigJSR, we are concept of priority. It's very interessing. I agree with @struberg if we mix our approach and spring model, its big mess.
A implementation can define an specific PropertySource that he use Spring model
@keilw concept of profile an another issue #26
I'm not passionate about the location, the META-INF / WEB-INF combination sounds reasonable to me. However I just argue that application.properties is a very good choice for what this file is supposed to do.
I also don't see the collision with Spring -- even if that file were in the root folder. These are just two different technologies loading the same properties file -- if developers for some reason would like to choose between technology A loading configuration or technology B, that doesn't collide. They could even use both at the same time...
Having that said, the discussion whether we use the properties location together with a ProjectStage / profile is also another discussion. This one is just a name :-)
If it was WEB-INF, too then for an EAR it had to be APP-INF as well.
I know we spoke about possible stages or other variations (including the "tennant ID" Oracle and Java EE had in mind earlier) in at least one call.
yes, good point about APP-INF.
But as written above I tried to avoid all that by explicitly only targeting classpath entries. So no WEB-INF or APP-INF at all. Just add your config into a jar or WEB-INF/classes/META-INF/javaconfig.properties
PS: yes I basically like the name application.properties, but I really fear it will become a mess because Spring uses it already. So I prefer to stick with META-INF/javaconfig.properties.
One can add custom ConfigSources for any other name anyway!
APP-INF is bad because that's do reference at EAR. Several container don't support this type of module. (ex: tomcat)
META-INF is more neutral. It's valid for classic JAR (META-INF), WAR (WEB-INF/classes/META-INF) and EAR (_META-INF)
Tallying this now: So far we seem to have a clear preference for sticking the information to META-INF/xxxx and not into the root of each jar.
There is still a discussion about the actual file name. We now have the following candidates
- javaconfig.properties
- javaxconfig.properties
- application.properties
- configuration.properties
- config.properties
application.properties would be compatible with Spring Boot, so I would use that at least as one of the options. Should we just pick one or multiple we prefer?
Agree with @keilw about application.properties. It's clear and direct. About pick multiple files, i think we should focus in only one and if the developer wants others he/she can create a configSource.
@jeyvison @keilw While application.properties is the same file name as spring, it's content is totally different. Spring has some nested syntax while we basically have old-style property files. That means we would accidentally pick up files which are not intended for us. And then we would likely crash... And the same is true for the other way around. That's why I recommend against using application.properties.
@struberg
Spring has some nested syntax while we basically have old-style property files
That's true about YAML files(What spring can read by default) but i don't know if it happens for plain property files. Would you have an example ?
When you say nested, you say something like this?
spring.datasource.driverClassName=com.mysql.jdbc.Driver
I vote for javaxconfig.properties.
It unambiguously specifies that this properties file is about javax.config.
application.properties, configuration.properties or config.properties are generic, non-descriptive names that could conflict with other libraries or implementations.
I'm more leaning towards configuration.properties or config,properties.
In my mind when looking from afar, javaxconfig.properties or javaconfig.properties look like something that is used to configure Java itself and not the application/service/tool.
+1 for configuration.properties or config.properties.
The whole ticket are a thing from the past, by the time this spec might be finished it won't be allowed to use javax.config any more. I'm not sure what is available outside the Spec Committee before we finish the resolution for the namespace, but I can share as much as "javax" will only be allowed for Jakarta EE 8 and after that for a "legacy" mode or profile with unchanged Java EE 8/Jakarta EE 8 specs. Neither of them is applicable for JSR 382, so "javax.config" is out of the question. Unless we're discussing the "SE only" option @aalmiray proposed?
javaconfig.properties is equally wrong, because neither "java" nor "javax" should be used from now on in active (Jakarta EE) specs.
Besides application.properties would also work, in fact that could even be of use for a Java SE only variant of this JSR should that be the way everyone wants to go and forget about Jakarta EE, which would of course be a shame, but minus CDI support JSR 382 could in theory continue in the JCP while something else maybe based on MicroProfile Config might graduate to Jakarta EE at some point.