Is the return value of Config#getConfigSources() specified to be immutable and unchanging?

[ljnelson]

In #370 @struberg notes that "Config infra is basically immutable". Is there a note somewhere in the specification that indicates that, for example, Config#getConfigSources() must return an unchanging Set of ConfigSources when invoked? Should there be?

Similarly, what is the contract for ConfigSourceProvider#getConfigSources(ClassLoader)? Is it required or prohibited or undefined for a ConfigSourceProvider implementation to return a dynamic Set?

[struberg]

The specification describes all the setup and discovery which happens at startup. And that's it.
So from that you can assume that those parts are not intended to get altered later.

[ljnelson]

Well, the specification doesn't actually say anything about how ConfigSources and Config are linked together. As you say, I assume that once ConfigSources are discovered by the service provider mechanism, then they're supposed to be used by Config and should? must? be returned by Config#getConfigSources() but I didn't see anything that says they must be.

Also, the specification has a section on dynamic ConfigSource providers. I don't think I can make any assumptions about what they can do. Or are you saying, yes, I can, they must be called once and must produce immutable unchanging Sets themselves?

[struberg]

Indeed that might be good to clarify.

[Emily-Jiang]

@struberg and I talked this a bit more in today's hangout. We think it is best left unspecified so that implementations can have freedom to decide whether they want to support dynamically reloaded config sources.

[ljnelson]

Thanks; in that case, I suppose that it must be specified that the return value must be safe for concurrent use by multiple threads? What must I synchronize on when iterating over it? Itself?

[Emily-Jiang]

@ljnelson it is best for you to join our MP Config weekly hangout to discuss your use case. Can you join next week? Please let me know on gitter if you need help with the meeting calendar.

[ljnelson]

I'll try to make it.

(For background, this isn't really connected with a use case: this is me simply trying to understand how I should iterate through the return value returned by getConfigSources(). Either it is safe for concurrent use by multiple threads or it is not; you can't leave this unspecified.)

[ljnelson]

Related: #369, #370, #395, #431, #457

[dmlloyd]

I'll note that it's always possible to provide a ConfigSource that itself delegates to a dynamically changing list of ConfigSources. So, requiring that the set of config sources be immutable with the idea that the configuration would be immutable as a result as a matter of principle is a bit of a shaky premise, unless such a requirement is also imposed on the ConfigSource itself.

That said, it should definitely be specified that the config sources iterable returned from getConfigSources() can be iterated in a thread-safe manner, including allowing concurrent iteration. This relates also to #369 for this reason: the specifications should (IMO) be similar.

[Emily-Jiang]

As today's hangout, the spec will not enforce whether the list is immutable or not. However, we would like to clarify the method getConfigSources() can be iterated in a thread-safe manner as per #371 (comment)

[Emily-Jiang]

@carlosdlr I'll take this one and add one line on the javadoc so that it can be in the release of Config 1.4.

[carlosdlr]

Thank you @Emily-Jiang

[kenfinnigan]

Why was this issue closed?

There was a lengthy discussion on the merged PR with @ljnelson and @radcortez that I believe impacts the closure of this issue

[radcortez]

Yes, I believe #510 should be clarified before closing #371.

[ljnelson]

I would like to kindly request that this issue be reopened as (a) it was not resolved and (b) no reason was given for its closing.

[emattheis]

At the risk of derailing this thread, can someone point me to any background on why config sources are exposed by Config in the first place? The inherently stateful nature of a ConfigSource makes this part of the spec problematic for specifiers and implementors alike. For instance, the fact that someone could obtain the source and close it. Do we need to consider proxying sources to avoid that?