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.
>
> Regarding ConfigResolver. The whol
> 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.
The
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 (do
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)?
config.unwrap(SnapshotService.class)
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.
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 same object type
but "frozen"
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.
>
> What about ImmutableConfig
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. 2018 21:38, "Thomas Andras
Between the 3 createSnapshot or snapshot.
What about ImmutableConfig and Config.toImmutable(keys)?
Not a big deal though.
Le 5 avr. 2018 21:38, "Thomas Andraschko" a
écrit :
+1 for ConfigSnapshot and Config#snapshot
2018-04-05 21:32 GMT+02:00 Mark Struberg :
> Had a long discussion with Tom
+1 for ConfigSnapshot and Config#snapshot
2018-04-05 21:32 GMT+02:00 Mark Struberg :
> Had a long discussion with Tomas Langer about atomic access this afternoon.
>
> What we came up with is probably better than 'ConfigTransaction', because
> the 'Transaction' term really creates the wrong impres
Had a long discussion with Tomas Langer about atomic access this afternoon.
What we came up with is probably better than 'ConfigTransaction', because the
'Transaction' term really creates the wrong impression.
So what about
* renaming ConfigTransaction to ConfigSnapshot and
* Config#createTra
Yes, you are right, in all cases the source must send an event to the
aggregator (config) to notify it to update its state (timestamp or not).
Thought we could support it transparently but seems there always have
border cases in advanced impl we sadly often rely on in prod ;).
It cant be a config a
But the writeLock would need to be performed by the ConfigSources.
So we need to change them anyway.
In the current solution any ConfigSource which performans an update would just
need to call the reportAttributeChange callback.
LieGrue,
strub
> Am 05.04.2018 um 09:39 schrieb Romain Manni-Buc
2018-04-05 9:31 GMT+02:00 Mark Struberg :
> Romain, your mail client is pretty broken. All my original content and
> your reply looks exactly the same.
> Please try to fix your reply-to rules ;)
>
>
> > This doesnt work for at least two reasons:
> >
> > 1. You assume you have request scoped
>
> Th
Romain, your mail client is pretty broken. All my original content and your
reply looks exactly the same.
Please try to fix your reply-to rules ;)
> This doesnt work for at least two reasons:
>
> 1. You assume you have request scoped
Thus the fallback to native resolving in case there is no ac
Le 4 avr. 2018 19:37, "Mark Struberg" a écrit :
But that's still problematic.
you have request1 ongoing and call in the following order:
ftpConfig.host();ftpConfig.port();// <- and here some config update happens
ftpConfig.username();
So even if we update the whole ftpConfig 'at once' you will
But that's still problematic.
you have request1 ongoing and call in the following order:
ftpConfig.host();ftpConfig.port();// <- and here some config update happens
ftpConfig.username();
So even if we update the whole ftpConfig 'at once' you will end up with mixed
up information in this request
Since the cache is per instance we should just clear it on eviction at once
IMHO
the issue is: do you want to populate it at once too? tempted to say yes
this means it can always be active but requires to be able to copy the
current config state or prevent *any* update while populating such "cache
We should also enhance the support to include @Configuration.
e.g. if you have some class like
@Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES)
public class FtpConfigation { String host(); Integer port(); String
username(); String encryptedPwd();}
Then you will likely resolve all thos
19 matches
Mail list logo
