[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16083964#comment-16083964
]
Alexander Falb commented on DELTASPIKE-1277:
--------------------------------------------
Yes we could, but then again, we would not be able to log any changes, if we
don't load the last value from the cache. On the other hand, maybe logging
should be done in the not-yet-existing CacheManager (during a put of a new
value into the manager) rather than in the PropertyBuilder? But removing
{{logChanges()}} would change the API of PropertyBuilder.
What do you mean with, we could get corrupted data if we read the same key
twice? I can only think of getting wrong log output. ie when having 2
PropertyBuilder with the same key, both with caching disabled and logging
enabled. If we call getValue on the 1st, changing the value and calling
getValue on the 2nd, the second one would log a change even if it never ever
resolved the value before.
> 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)
