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.
