You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@tiles.apache.org by "Jeff Reichenberg (JIRA)" <ji...@apache.org> on 2010/03/11 20:42:27 UTC
[jira] Created: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
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.
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849392#action_12849392 ]
Antonio Petrelli commented on TILES-503:
----------------------------------------
... thing that already does... wrong again :-D
Then the problem is in lastModifiedDates, probably it suffices to clear it at each refresh.
> 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
> Fix For: 2.2.2
>
>
> 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.
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Jeff Reichenberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856604#action_12856604 ]
Jeff Reichenberg commented on TILES-503:
----------------------------------------
BTW, you'll notice I am using Tiles 2.1.4. Not sure if 2.2.x has this issue or not, as well.
> 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
[jira] Closed: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli closed TILES-503.
----------------------------------
Resolution: Won't Fix
If it works, it works. The autoreload is a development-only feature. It does not make sense to turn it on in production.
If you want to do your own way of managing definition refresh, do it. If you like it, you can even post a patch. Even then, this is not a bug, but a missing feature.
Sorry, but I close it as "won't fix".
> 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
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Jeff Reichenberg (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Jeff Reichenberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Reichenberg updated TILES-503:
-----------------------------------
Comment: was deleted
(was: Test case web application.)
> 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
[jira] Updated: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli updated TILES-503:
-----------------------------------
Affects Version/s: 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
Fix Version/s: 2.2.2
> 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
> Fix For: 2.2.2
>
>
> 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.
[jira] Closed: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli closed TILES-503.
----------------------------------
Resolution: Cannot Reproduce
> 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.
[jira] Reopened: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Jeff Reichenberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Reichenberg reopened TILES-503:
------------------------------------
I've created a test case that illustrates the issue. My only customization is the extension of ResolvingLocaleUrlDefinitionDAO, which just adds some console logging at key points.
Here are the steps. tiles-503.zip file attached to the bug report. Looking forward to your comments.
1. Unzip the tiles-503.zip, cd into the "tiles-503" dir and run "mvn tomcat:run"
2. Hit http://localhost:8080/tiles-503/index.jsp with default "Accept-Language" header, "en-us" in my case. Tiles builds the definitions for this locale and "parent" locales
INFO: Starting Coyote HTTP/1.1 on http-8080
Post-processed 2 definitions for locale ''.
Post-processed 2 definitions for locale 'English'.
Post-processed 2 definitions for locale 'English (United States)'.
3. Update the "version" attribute in src/main/webapp/WEB-INF/tiles.xml to 2: <put-attribute name="version" value="2" />. Save the file
4. Start a new browser process/clear session cookies. Hit http://localhost:8080/tiles-503/index.jsp with "Accept-Language" header changed to, "fr-fr". (You can use Charles proxy rewrite function to do this, or Fiddler). Tiles builds the definitions for "fr-fr" and "parent" locales using the updated Tile definitions (i.e. "version 2"). The update is shown on the index.jsp page. Make sure the "Accept-Language header" text on the web page reads "fr-fr".
Post-processed 2 definitions for locale ''.
Post-processed 2 definitions for locale 'French'.
Post-processed 2 definitions for locale 'French (France)'.
5. Turn off header rewriting and start a new browser process/clear session cookies.
6. Hit http://localhost:8080/tiles-503/index.jsp. The original "version" attribute value is shown on the index.jsp as expected because we haven't refreshed the tile definitions yet and the default locale still has the old definitions in memory. Now click the "refresh tile definitions" link on the index.jsp page. This calls refresh() on the container. Note the following output. We'd expect to see the "Post-refresh size of locale2definitionMap" to be 0 because we updated a definition and it should be cleared out.
Pre-refresh size of locale2definitionMap: 5
Checking if refresh required, last mod dates for Tile def XMLs follow...
Last mod date for XML jndi:/localhost/tiles-503/WEB-INF/tiles_fr.xml: 0, cached last mod date: 0.
Last mod date for XML jndi:/localhost/tiles-503/WEB-INF/tiles_fr_FR.xml: 0, cached last mod date: 0.
Last mod date for XML jndi:/localhost/tiles-503/WEB-INF/tiles_en.xml: 0, cached last mod date: 0.
Last mod date for XML jndi:/localhost/tiles-503/WEB-INF/tiles_en_US.xml: 0, cached last mod date: 0.
Last mod date for XML jndi:/localhost/tiles-503/WEB-INF/tiles.xml: 1271188631745, cached last mod date: 1271188631745.
Post-refresh size of locale2definitionMap: 5
Completed Tiles refresh attempt for webapp org.apache.catalina.core.ApplicationContextFacade@15fd251
7. Go back to http://localhost:8080/tiles-503/index.jsp. We'd expect to see the updated "version" attribute. We don't, we still see "1". This is because the "fr-fr" locale request came in between the time we updated our definition xml on the file system and the time we called refresh() on the container. This "corrupted" the global BaseLocaleUrlDefinitionDAO#lastModifiedDates Map. Because the Map is global, but only the "fr-fr" locale was rebuilt, no other locales will ever be refreshed until the server is restarted or another update is made to the XML and we race to run refresh() before a request from an unbuilt locale comes in.
> 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
[jira] Assigned: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli reassigned TILES-503:
--------------------------------------
Assignee: Antonio Petrelli
> 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
> Fix For: 2.2.2
>
>
> 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.
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849386#action_12849386 ]
Antonio Petrelli commented on TILES-503:
----------------------------------------
I am sorry I was completely wrong. The locale2definitionMap is completely cleared when the refresh is needed.
I suppose that the correct approach is to check if refresh is needed before loading a new definition file.
> 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
> Fix For: 2.2.2
>
>
> 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.
[jira] Updated: (TILES-503) XML definitions for top/default locale
can be reloaded without invalidating definition maps for locales that share
the same definitions
Posted by "Jeff Reichenberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Reichenberg updated TILES-503:
-----------------------------------
Attachment: tiles-503.zip
Test case web application.
> 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
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857011#action_12857011 ]
Antonio Petrelli commented on TILES-503:
----------------------------------------
Bug replicated, let me work on it.
Thanks
> 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
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Jeff Reichenberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844239#action_12844239 ]
Jeff Reichenberg commented on TILES-503:
----------------------------------------
Actually, it seems that the correct behavior here is /not/ to invalidate definitions for other locales. That is the job of refresh(). Rather, Tiles should copy existing definitions for parent locales from cache, rather than loading from the file system in loadDefinitionsFromURLs.
> 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.
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (TILES-503) XML definitions for top/default
locale can be reloaded without invalidating definition maps for locales
that share the same definitions
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TILES-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857025#action_12857025 ]
Antonio Petrelli commented on TILES-503:
----------------------------------------
Auto refresh is not enabled by default.
I solved the problem by adding this context parameter:
<context-param>
<param-name>org.apache.tiles.definition.dao.LocaleUrlDefinitionDAO.CHECK_REFRESH</param-name>
<param-value>true</param-value>
</context-param>
Can you try it?
> 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