[
https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Petrelli updated TILES-503:
-----------------------------------
Fix Version/s: (was: 2.2.2)
Remaining Estimate: 0h
Original Estimate: 0h
I am sorry, I cannot reproduce the problem. I tried exactly what you said in
tiles-test webapp but the problem does not show up.
I close it as "cannot reproduce". However feel free to attach a test case.
> 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
> 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.
-
You can reply to this email to add a comment to the issue online.
