[
https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844419#action_12844419
]
Antonio Petrelli commented on TILES-503:
----------------------------------------
No: the problem is that the Maps store, for every locale, the base definitions
*and* the locale-specific definitions.
Locale-specific definitions can override the base ones, so simply copying from
the base definitions to the locale-specific definitions map is incorrect.
> 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
> Reporter: Jeff Reichenberg
>
> 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.
-
You can reply to this email to add a comment to the issue online.
