It actually is not really backward compatible and it also not really a full TREE Solution because it still operates FLAT on String/String in the ConfigSources. Calling it TREE is really misleading, because BOTH proposed solutions support Pojo configuration and single attributes. The only real difference is that the new proposal has a different user facing API. But the restrictions do come from the fact that we have to deal with String/String as least common denominator. Simply because there are ton of Config Sources around which are still only flat:
A pojo
public record ServerEndpoint(String host, Integer port, String path) {}
And
config.access("myapp.endpoint", ServerEndpoint.class).getValue();
can get represented as
{
"myapp":{
"endpoint":{
"host":"myserver",
"port":443,
"path":"/myapp/someendpoint"
}
}
}
or flat as:
myapp.endpoint.host=myserver
myapp.endpoint.port=443
myapp.endpoing.path=/myapp/someendpoint
But also in Thomas' proposal it will *internally* (in the ConfigSources) will be interpreted as the later: FLAT as String/String. Plus you right now need to write an explicit converter for each Pojo.
It it really would be TREE, then also the ConfigSources would reflect this!
What also was not yet answered: if I navigate to a sub config node, how does it behave? When do the values get resolved? Is this resolved subnode mutable or immutable?
If it is immutable, then how do I get changes in values, or does it not support mutability at all?
And if the config node is mutable, then how does it deal with atomicity?
Dmitries example is:
public class EndpointConverter implements Converter<Endpoint> {
Endpoint convert(Config node) {
return new Endpoint(
node.get("host").asString(),
node.get("port").convert(Integer.class),
node.get("path").asString());
}
}
how does it deal with the situation that the underlying values change between resolving host and port?
So basically both solutions suffer / have to deal with the same problems. Just that the one solution has it all sorted out and the other is doing it over from scratch with a different API. Not sure that's worth it tbh.
I also personally dislike that the whole history of the community got ditched, which is not how OSS works to be honest. The original ConfigJSR proposal which was based on mp-config (with all the history for code provenance taken over) can be found here and provides the same functionality and even way more:
A fully working implementation can be found here:
This solution also already deals with mutability (whereas in the so called 'TREE' proposal it is perfectly undefined and thus not portable yet) and also provides atomic access to the underlying configuration (with a kind of optmistic locking approach).
Plus it has already a good bunch of TCK tests (152) and many pages of Spec text.
LieGrue,
strub
I like the idea of tree structures and on the surface this looks like it's backwards compatible with MP Config; basically "full" or "absolute" paths would still work, but now you'd have the ability to refer to new nodes that are now essentially parents.
As I don't immediately see a downside, is there some sort of backwards incompatibility or tradeoff being made with the proposal?
--
David Blevins
http://twitter.com/dblevinshttp://www.tomitribe.comOn Dec 9, 2021, at 11:41 AM, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
Hi,
As we discussed on the meeting today, I am going to create two email threads: one for the subj discussion (this thread) and another one for voting (I’ll do it later). The rule is simple: discuss the subj here and use voting thread only for voting.
To initiate the discussion:
Here is a link to Tomas’ PR for tree structure: https://github.com/eclipse-ee4j/config/pull/22
Here is my private gist with some thoughts: https://gist.github.com/m0mus/1bf0a3f76e3492fa764263b4b180a50a
Thanks,
Dmitry
P.S.
Creating the voting thread now…
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxxTo unsubscribe from this list, visit
https://accounts.eclipse.org
