microprofile-config.properties ConfigSource question

116 views
Skip to first unread message

Laird Nelson

unread,
Mar 23, 2018, 2:21:17 AM3/23/18
to Eclipse MicroProfile
Hello; I had several questions related to implementing the MicroProfile Config specification.

(Disclaimer up front: in my day job, I work for Oracle, but this question and in general any interaction with this list under my personal email, like this one, is completely dissociated from my employer.)

First, I'm glad I looked at https://static.javadoc.io/org.eclipse.microprofile.config/microprofile-config-api/1.2.1/org/eclipse/microprofile/config/spi/ConfigSource.html#getOrdinal--, since it let me know that microprofile-config.properties is a default ConfigSource.  Assuming that it is represented somehow by a ConfigSource implementation, what should be the return value from such an implementation's getName() method?

Next, there could, of course, be several such resources on the classpath.  I see that "[f]or the config sources with the same ordinal value, the config source names will be used for sorting according to string sorting criteria", which makes me think that the implied return value of a ConfigSource representing such a properties file should also take into consideration the name of the jar file that it is part of, which seems distinctly weird to me.  Is that a correct assumption?

Best,
Laird

Laird Nelson

unread,
Mar 23, 2018, 2:40:05 AM3/23/18
to Eclipse MicroProfile
On Thursday, March 22, 2018 at 11:21:17 PM UTC-7, Laird Nelson wrote:
Hello; I had several questions related to implementing the MicroProfile Config specification.

I realize now that another of my questions is: was it intended that there be one ConfigSource representation of all classpath resources named /META-INF/microprofile-config.properties (and, if so, what should the return value of its getName() method be?), or was it intended that there be n ConfigSource representations (one per classpath resource named /META-INF/microprofile-config.properties)?

Is there some other document other than serendipitous method Javadocs where I can read more about this area of the MicroProfile effort?  I know only of http://microprofile.io/project/eclipse/microprofile-config, which is composited from the raw materials in http://microprofile.io/project/eclipse/microprofile-config, which don't really answer this question.

Mind you, I am not throwing tomatoes here; I am just looking for implementor guidance.  Thanks!

Best,
Laird

Laird Nelson

unread,
Mar 23, 2018, 3:04:05 AM3/23/18
to Eclipse MicroProfile
On Thursday, March 22, 2018 at 11:40:05 PM UTC-7, Laird Nelson wrote:
was it intended that there be one ConfigSource representation of all classpath resources named /META-INF/microprofile-config.properties (and, if so, what should the return value of its getName() method be?), or was it intended that there be n ConfigSource representations (one per classpath resource named /META-INF/microprofile-config.properties)?

I see from the specification text (the Javadocs, in this case, on the ConfigSource class) that any given properties file (or presumably classpath resource, which might not be a file) is supposed to have its own ConfigSource representation: "A ConfigSource provides configuration values from a specific place, like JNDI configuration, a properties file, etc."

So I suppose that it follows that every MicroProfile Config implementation must have at least n + 2 ConfigSources, where n is equal to the number of /META-INF/microprofile-config.properties resources on the classpath, and the "+ 2" part is to account for system properties and environment variables.  So the number of ConfigSource instances is directly proportional to the number of /META-INF/microprofile-config.properties classpath resources, and there is no other possibility of representing them while remaining within the bounds of the specification.  Is that right, assuming that the "sort-by-name" implication sketched out by the Javadocs on the getOrdinal() method is also valid?

So I would also suppose that it must follow that for a ConfigSource that wants to represent a particular occurrence on the classpath of a /META-INF/microprofile-config.properties classpath resource it must have a name that includes the URI locating that classpath resource (to ensure sorting uniqueness).  That still seems mighty weird to me but I don't think there's any wiggle room here unless I've misread something.

Please let me know if I've read these tea leaves wrongly.

Best,
Laird

Emily Jiang

unread,
Mar 23, 2018, 12:42:48 PM3/23/18
to Eclipse MicroProfile
Hi Larid,

Each microprofile-config.properties represents one config source. As for the name, you can give it any name you want. The name is used for debugging purpose and when a same ordinal used in multiple config sources, the names will be used for sorting the config sources. When sorting config sources, getOrdinal() is used. The getName() is only used to sort the config sources with the same ordinal.

By the way, you can find the spec from https://github.com/eclipse/microprofile-config/releases

You may this article (https://www.eclipse.org/community/eclipse_newsletter/2017/september/article3.php) useful.

Thanks
Emily

Laird Nelson

unread,
Mar 27, 2018, 2:00:08 PM3/27/18
to Eclipse MicroProfile
On Friday, March 23, 2018 at 9:42:48 AM UTC-7, Emily Jiang wrote:
Each microprofile-config.properties represents one config source.

OK; thank you; that wasn't clear from the specification.  (You can see, I hope, that a reader of the specification could conclude that there should be one ConfigSource, named META-INF/microprofile-config.properties, that would represent, say, the merging of all the META-INF/microprofile-config.properties resources found on the classpath.  I see from your post above that this was not the intent.)
 
As for the name, you can give it any name you want.

Thanks; wasn't sure.
 
The name is used for debugging purpose and when a same ordinal used in multiple config sources, the names will be used for sorting the config sources. When sorting config sources, getOrdinal() is used. The getName() is only used to sort the config sources with the same ordinal.

Ah, OK; that wasn't clear from the specification.
 
By the way, you can find the spec from https://github.com/eclipse/microprofile-config/releases

Yep; thanks!

Best,
Laird

Laird Nelson

unread,
Mar 27, 2018, 2:09:15 PM3/27/18
to Eclipse MicroProfile
On Friday, March 23, 2018 at 9:42:48 AM UTC-7, Emily Jiang wrote:
Each microprofile-config.properties represents one config source. As for the name, you can give it any name you want.

Actually, I'm curious here.

Suppose there are two jars on the classpath, a.jar and b.jar.  Each has a META-INF/microprofile-config.properties resource in it.  Suppose further that I am implementing ConfigBuilder.

If I understand you right, in my addDefaultSources() method implementation I will create two ConfigSources here: one for a.jar!/META-INF/microprofile-config.properties and one for b.jar!/META-INF/microprofile-config.properties.  From the specification, the ordinal for META-INF/microprofile-config.properties should be 100.  Should the ordinal be 100 for both the ConfigSource representing a.jar!/META-INF/microprofile-config.properties and the ConfigSource representing b.jar!/META-INF/microprofile-config.properties?  If so, then isn't the name the only thing that distinguishes these two ConfigSources (in terms of sorting/priority)?

Also, the specification refers to 100 as the "default ordinal".  In the implementation of my addDefaultSources() method, must I use this number on all such META-INF/microprofile-config.properties ConfigSource implementations?  If so, aren't their names then quite significant?

Best,
Laird

Laird Nelson

unread,
Mar 27, 2018, 2:37:42 PM3/27/18
to Eclipse MicroProfile
On Friday, March 23, 2018 at 9:42:48 AM UTC-7, Emily Jiang wrote:
Each microprofile-config.properties represents one config source.

Interestingly, I don't think that's how many people have implemented it.  Here are some completely arbitrary references (disclaimer: I have no connection with any of them; just did a Github search).  Note how each of them, I think, defines one ConfigSource representing possibly many classpath resources named META-INF/microprofile-config.properties, rather than, as required, I guess, by the specification, n such ConfigSource implementations:
OpenLiberty, notably, implements it the way you describe:
I guess I'll follow OpenLiberty's lead here, since it seems to be the proper implementation…?  Thanks, and sorry for all the questions!

Best,
Laird

Laird Nelson

unread,
Mar 27, 2018, 2:40:58 PM3/27/18
to Eclipse MicroProfile
On Tuesday, March 27, 2018 at 11:37:42 AM UTC-7, Laird Nelson wrote:
(Strike this one; missed the fact that under the covers it's creating many ConfigSource implementations.) 

Laird Nelson

unread,
Mar 27, 2018, 2:51:54 PM3/27/18
to Eclipse MicroProfile
On Tuesday, March 27, 2018 at 11:09:15 AM UTC-7, Laird Nelson wrote:
Also, the specification refers to 100 as the "default ordinal".  In the implementation of my addDefaultSources() method, must I use this number on all such META-INF/microprofile-config.properties ConfigSource implementations?

Emily Jiang

unread,
Mar 27, 2018, 6:01:22 PM3/27/18
to Eclipse MicroProfile
The default ordinal of 100 is only used if  'config_ordinal' property does not exist in the config source file.

Emily

Laird Nelson

unread,
Mar 27, 2018, 6:15:15 PM3/27/18
to Eclipse MicroProfile
On Tuesday, March 27, 2018 at 3:01:22 PM UTC-7, Emily Jiang wrote:
The default ordinal of 100 is only used if  'config_ordinal' property does not exist in the config source file.

Ah! I see it now in section #_configsource_ordering.  Thank you!  Sorry for the noise!

L

Emily Jiang

unread,
Mar 28, 2018, 5:21:22 AM3/28/18
to Eclipse MicroProfile
No worries. Thanks for your interest in this spec!

Thanks
Emily

Mark Struberg

unread,
Mar 31, 2018, 3:57:21 PM3/31/18
to Eclipse MicroProfile
you missed an important impl ;)


It also creates n ConfigSources, 1 per existing mp-config.properties file on the classpath.

LieGrue,
strub

Mark Struberg

unread,
Mar 31, 2018, 4:00:40 PM3/31/18
to Eclipse MicroProfile
Btw, the reason why each of the microprofile-config.properties files get picked up as own ConfigSource is because each of them can have a different ordinal!

That way it is possible to create a plug-in like structure where you can just drop in an additional jar to your classpath and be done.

I've described this in an old blog post (2010) 

LieGrue,
strub
Reply all
Reply to author
Forward
0 new messages