[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082443#comment-16082443
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
------------------------------------------------
Really looks close to what I have in mind. I have however some questions after
the patch review (some unclear area):
- if not using caching do we still "cache" in the shared cache? If not we can
try to do it I think otherwise if you read twice the same key the behavior is
now different from what it is today (you can get a corrupted data)
- any reason to not move to a ConfigContext and add another Map (tried to write
it in previous comment but re-reading it was maybe not clear): I think it would
be beneficial to store all config contextual (per classloader) data in a single
structure (I called it ConfigContext but any other name is good). It would
allow to have all the data you can need in all related places and avoid to
clear cache in config source method for instance ;)
Once these small tech-y details "fixed"/"discussed" I'd like to have a small
iteration on the API. Maybe having a "ConfigCacheManager" can be beneficial
instead of polluting the ConfigResolver itself (even if it delegates, it is
purely in term of API here) and we should surely embrace more java 8 - just
providing functional interface but not having any strong adherance):
{code}
// surely added as a bean but also accessible from the ConfigContext for
extensions?
public interface ConfigCacheLManager {
void clear();
void remove(String key);
void removeIf(BiPredicate<String, Object> predicate); // for all cached
values, if the predicate matches then remove
}
{code}
Nice thing about the removeIf is it allows to manage easily
(startsWith/endsWith) groups of keys (startsWith("app.database.")).
Hope it makes sense
> Force refresh of cached config values
> -------------------------------------
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
> Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
