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, right?
The only viable solution is to have a @RequestScoped ConfigTransaction spanning
all those TypedResolvers of the whole @Configuration. At least I could not find
any better solution.
LieGrue,strub
On Wednesday, 4 April 2018, 18:44:13 CEST, Romain Manni-Bucau
<[email protected]> wrote:
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"
+1 to do it without any flag
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
2018-04-04 18:40 GMT+02:00 Mark Struberg <[email protected]>:
> 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 those values in an atomic way. This means
> that the values are basically backed by a @RequestScoped ConfigTransaction
> holder.
> Do we _always_ like to activate this feature?Or do we like to introduce
> another flag in the @Configuration annotation?
> What about threads which have no request Context active?Should it
> automatically fallback to on-demand resolving?
> LieGrue,strub
>
> On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg
> <[email protected]> wrote:
>
> hi folks!
> please review the proposed solution for DELTASPIKE-1335
> https://issues.apache.org/jira/browse/DELTASPIKE-1335
>
> Not quite sure about startTransaction and ConfigTransation are the right
> terms. Happy to get feedback!
>
> txs and LieGrue,strub
>
