[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080333#comment-16080333
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Hi Alexander,
yes this map would be a good entry point. We can't use a cdi bean yet because
1. it must work in extensions themself so no bean yet, 2. there are some
workarounds for ears and some containers so even if less elegant the map is
more reliable for now. The type resolvers always being contextual you should be
able to use this map to get the "current" tracker/storage. ConfigResolver has
the role of storage today, I'm not sure it fully fit the perf requirements
since you can get a slow config source but adding a light cache with eviction
on top of it would be easy. In term of internal refactoring it would just
require to store a ConfigContext per classloader instead of just
sources/converters etc to be able to add more contextual data to it IMO. I'm
sure there are other solution but I don't see any blocker to do it.
wdyt?
> 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)