[ 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)