[
https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857141#action_12857141
]
Jeff Reichenberg commented on TILES-503:
----------------------------------------
Yes, that works but only because it defeats the entire refresh() call by
calling refreshRequired() on every access of getDefinition()/getDefinitions().
This could be quite a lot -- looks like every single call to getDefinition()
would go through there. Not sure what the extra load would be, especially if
the refreshRequired() check needs to access the file system via URLConnection
to get current last modified dates. Is there some magic I'm not seeing that
makes this light weight?
Are there any other options for a fix to the way refresh() is managed other
than this workaround? Our workaround for now is to use a custom LocaleResolver
to force everything into the default locale, but we are doing localization soon
and this is not where we want to be long term.
> XML definitions for top/default locale can be reloaded without invalidating
> definition maps for locales that share the same definitions
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TILES-503
> URL: https://issues.apache.org/jira/browse/TILES-503
> Project: Tiles
> Issue Type: Bug
> Components: tiles-core
> Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7,
> 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2.0, 2.2.1
> Reporter: Jeff Reichenberg
> Assignee: Antonio Petrelli
> Attachments: tiles-503.zip
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> CachingLocaleUrlDefinitionDAO#refreshRequired() can incorrectly return false
> in certain circumstances, causing refresh to not update Tile definitions even
> though one or more underlying definition XML files have been updated on the
> file system since startup/last refresh.
> Tiles stores an in-memory cache of Tile definitions keyed by locale. These
> definitions are built lazily as requests come in, based on the locale of the
> request. If the locale on the request doesn't yet have definitions
> associated with it, definitions are built for that locale (and parent
> locales) on-the-fly and cached. If the lazy building of definitions for a
> new locale results in an updated XML file loaded from the file system that is
> shared by an existing locale, the definitions already cached for other
> locales that share the same definition file should be invalidated.
> Use Case:
> * Updated Tile definition XML files are pushed onto servers. The servers
> continue to field requests.
> * A request with a previously unseen locale comes in, causing a set of
> definitions to be built for that locale and parent locales. The updated XMLs
> are processed from the file system for the new locale only, which updates the
> global cache of XML file last modified dates
> (BaseLocaleUrlDefinitionDAO#lastModifiedDates)
> * BaseLocaleUrlDefinitionDAO#refreshRequired() compares file system last
> modified dates to the cached ones and returns true if they differ. Since the
> global cache of last modified dates was updated in the previous step, the
> framework doesn't detect that anything has changed. Thus, it still holds
> out-dated definitions for all locales other than new ones that come in after
> the XML file push.
> I don't have test case, unfortunately, but my steps to reproduce using a
> Servlet environment and ResolvingLocaleUrlDefinitionDAO are:
> * Use a Tile definition XML files with no locale suffix, e.g.
> "my-base-tile-defs.xml"
> * Issue a request with the "Accept-Language" HTTP header "en-us". Tile
> definitions are built for locales "en-us", "en" and "" all using the same
> base XML file
> * Update one of the tile definitions in the XML, save to the file system
> * Issue a request with the "Accept-Language" HTTP header "fr-fr". Tile
> definitions are built for locales "fr-fr", "fr" and rebuilt for "" all using
> the updated XML file. Cached definitions for "en-us" and "en" are not
> invalidated, even though the underlying XML file used to build both of them
> are now changed. This is because
> BaseLocaleUrlDefinitionDAO#lastModifiedDates now has the updated last mod
> date found when the definitions were built for "fr-fr", even though the
> updated definitions are not reflected in the definitions for "en-us"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
