Re: atomic access to config values

2018-04-06 11:11 GMT+02:00 Mark Struberg : > > 1. don't expose the read side of the API, hide it under our impls > > (resolver, @configuration, ...) > > We will add the feature to @Configuration. That's on our list and doable > in a perfectly transparent way. > >

Re: atomic access to config values

> 1. don't expose the read side of the API, hide it under our impls > (resolver, @configuration, ...) We will add the feature to @Configuration. That's on our list and doable in a perfectly transparent way. Regarding ConfigResolver. The whole class mainly exists for backward compat reasons.

Re: atomic access to config values

Mark, I started to play with the API you proposed and I'd like to propose this change: 1. don't expose the read side of the API, hide it under our impls (resolver, @configuration, ...) 2. don't use typeresolvers but keys to consider 3. provide a context handler Here is how I would envision it

cipher service rework?

Hi guys, I have a mix of proposal question on our cipher service: 1. why do we have impl details in the api? salt and setter are impl details no? Also it sounds like a transversal concern of the ciphering by itself so why not removing it from the API (or deprecating it) So proposal is to move

Re: atomic access to config values

ok ok, i'm fine not having it implementing it - just thought it was not a blocker. Can we get an unwrap in Config *api* to be able to plug features like that (which allows us to use it under the hood and when we think it is ready we promote it to the api)?

[jira] [Commented] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values

[ https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428066#comment-16428066 ] ASF subversion and git services commented on DELTASPIKE-1335: - Commit

Re: atomic access to config values

But the ConfigTransaction/ConfigSnapshot has only one functionality: getValue(). But the Config itself is the underlying infrastructure holder and has tons of features. Having ConfigSnapshot extends Config and just being a 'frozen' Config would mean we would also need to implement all features.

Re: atomic access to config values

2018-04-06 8:51 GMT+02:00 Mark Struberg : > Btw, ImmutableConfig would kind of suggest that it extends our Config > interface, isn't? > Didn't think to that but it would be possible since we snapshot a subconfig which can be a config. A snapshot sounds like it is the

Re: atomic access to config values

Btw, ImmutableConfig would kind of suggest that it extends our Config interface, isn't? But that's not the case, it is really something different. LieGrue, strub > Am 05.04.2018 um 22:02 schrieb Romain Manni-Bucau : > > Between the 3 createSnapshot or snapshot. > >

Re: atomic access to config values

hmm what about snapshotFor(TypedResolver...) ? LieGrue, strub > Am 05.04.2018 um 22:02 schrieb Romain Manni-Bucau : > > Between the 3 createSnapshot or snapshot. > > What about ImmutableConfig and Config.toImmutable(keys)? > > Not a big deal though. > > > Le 5 avr.