[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066657#comment-16066657
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
------------------------------------------------
Hi Alexander,
patch looks good to me (just wonder if signature should ve TypeResolver
refresh() instead of void forceRefresh() but we are really at the detail level)
Now I have to admit i like the other propose and even more if wired to a
deltaspike service (understand a CDI bean) since it would allow for instance to
have a /evict endpoint not requiring to track all resolver instances which
pollutes (today) the code for a technical concern. We already have a storage
"by application" for the sources/config so it seems not hard to have a cache
storage mapped on it. Only trick will be to have a nice key preventing conflict
between resolver (string key doesnt work right?) but nothing we can't solve.
Hope it helps a bit to move forward
Romain
> 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: 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)
