[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16083879#comment-16083879
]
Alexander Falb commented on DELTASPIKE-1277:
--------------------------------------------
Thanks for the feedback!
* Yes we need to write to some sort of cache, even if caching is disabled. If
not we could not log changes. Ofc we could use the internal cache for this (the
{{T lastValue}} i removed) but I dont see the pro for this. But the cached
value is only returned if {{cacheTimeMs > 0}} otherwise it gets reloaded.
* No particular reason. I just didn't want to clutter the commit with a
refactoring. But I totally agree, the 1200+ lines of ConfigResolver is way to
much, it really needs a refactoring.
I like the ConfigCacheManager idea! Although Deltaspike currently compiles
against Java 6 (afair), so we would need to update that first.
> 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)
