[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301462#comment-14301462
]
Alexander Klimetschek commented on SLING-4344:
--
IMO Sling i18n is not really designed for customer-changeable string
dictionaries.
> Modifying i18n language node in a path outside the resource resolver's search
> path will not invalidate the ResourceBundle cache
> ---
>
> Key: SLING-4344
> URL: https://issues.apache.org/jira/browse/SLING-4344
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: i18n 2.3.2
>Reporter: Konrad Windszus
> Fix For: i18n 2.3.4
>
> Attachments: SLING-4344-v02.patch
>
>
> Currently any modification of a Sling i18n message will not invalidate the
> {{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
> because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
> basename and contents only outside of the resource resolver's search path are
> always empty
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
> I would argue that it should be allowed to place language nodes anywhere in
> the repository, which seems to work well except for the cache invalidation.
> The problem is in the {{loadFully}} method
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
> which will only set languageRoots if they are below any of the resource
> resolver's search paths.
> To reproduce the issue you can just add the following node structure
> {code}
> /content/languages
>+-- English (nt:folder, mix:language)
>|+-- jcr:language = en
>|+-- basename = myuniquebasename
>|+-- m1 (sling:messageEntry)
>||+-- sling:key = "msg001"
>||+-- sling:message = "This is a message"
> {code}
> Then load the key from this resource bundle (by giving the right basename).
> It will internally put the resource bundle into the cache (although all
> contents of the given resource bundle are outside any of the default search
> paths /apps or /libs). Whenever you change the message that won't be
> reflected, because the resource bundle cache is not invalidated (caused by
> the empty {{languageRoots}}) therefore the old message would still be
> exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14297818#comment-14297818
]
Konrad Windszus commented on SLING-4344:
But my point is, since JCR Resource Bundles can be fed from anywhere in the
repository and just the invalidation is broken, I just fixed the invalidation
(instead of just disallowing language nodes anywhere outside the resource
resolver's search path, which would have been an incompatible change).
Also I would argue, that there are some good use cases for maintaining resource
bundles inside the content. They should be clearly separated from the regular
resource bundles (by giving them a dedicated basename), but the mechanism and
the connected tools (e.g. CQ translator in the CMS built on top of Sling) is
also very good for being used inside /content. Those language nodes clearly
follow a different lifecycle and ACLs, but still the mechanism is useful.
> Modifying i18n language node in a path outside the resource resolver's search
> path will not invalidate the ResourceBundle cache
> ---
>
> Key: SLING-4344
> URL: https://issues.apache.org/jira/browse/SLING-4344
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: i18n 2.3.2
>Reporter: Konrad Windszus
> Fix For: i18n 2.3.4
>
> Attachments: SLING-4344-v02.patch
>
>
> Currently any modification of a Sling i18n message will not invalidate the
> {{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
> because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
> basename and contents only outside of the resource resolver's search path are
> always empty
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
> I would argue that it should be allowed to place language nodes anywhere in
> the repository, which seems to work well except for the cache invalidation.
> The problem is in the {{loadFully}} method
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
> which will only set languageRoots if they are below any of the resource
> resolver's search paths.
> To reproduce the issue you can just add the following node structure
> {code}
> /content/languages
>+-- English (nt:folder, mix:language)
>|+-- jcr:language = en
>|+-- basename = myuniquebasename
>|+-- m1 (sling:messageEntry)
>||+-- sling:key = "msg001"
>||+-- sling:message = "This is a message"
> {code}
> Then load the key from this resource bundle (by giving the right basename).
> It will internally put the resource bundle into the cache (although all
> contents of the given resource bundle are outside any of the default search
> paths /apps or /libs). Whenever you change the message that won't be
> reflected, because the resource bundle cache is not invalidated (caused by
> the empty {{languageRoots}}) therefore the old message would still be
> exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295900#comment-14295900
]
Alexander Klimetschek commented on SLING-4344:
--
Hmm, while the fix might be good, I don't think it's a good idea to put
resource bundles outside /apps or /libs. They are considered part of the code
base and thus follow very different ACLs and lifecycle than say /content (as in
above example), so you want to be really careful about this.
> Modifying i18n language node in a path outside the resource resolver's search
> path will not invalidate the ResourceBundle cache
> ---
>
> Key: SLING-4344
> URL: https://issues.apache.org/jira/browse/SLING-4344
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: i18n 2.3.2
>Reporter: Konrad Windszus
> Fix For: i18n 2.3.4
>
> Attachments: SLING-4344-v02.patch
>
>
> Currently any modification of a Sling i18n message will not invalidate the
> {{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
> because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
> basename and contents only outside of the resource resolver's search path are
> always empty
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
> I would argue that it should be allowed to place language nodes anywhere in
> the repository, which seems to work well except for the cache invalidation.
> The problem is in the {{loadFully}} method
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
> which will only set languageRoots if they are below any of the resource
> resolver's search paths.
> To reproduce the issue you can just add the following node structure
> {code}
> /content/languages
>+-- English (nt:folder, mix:language)
>|+-- jcr:language = en
>|+-- basename = myuniquebasename
>|+-- m1 (sling:messageEntry)
>||+-- sling:key = "msg001"
>||+-- sling:message = "This is a message"
> {code}
> Then load the key from this resource bundle (by giving the right basename).
> It will internally put the resource bundle into the cache (although all
> contents of the given resource bundle are outside any of the default search
> paths /apps or /libs). Whenever you change the message that won't be
> reflected, because the resource bundle cache is not invalidated (caused by
> the empty {{languageRoots}}) therefore the old message would still be
> exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14288957#comment-14288957
]
Konrad Windszus commented on SLING-4344:
Applied a slightly modified patch in rev 1653136.
> Modifying i18n language node in a path outside the resource resolver's search
> path will not invalidate the ResourceBundle cache
> ---
>
> Key: SLING-4344
> URL: https://issues.apache.org/jira/browse/SLING-4344
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: i18n 2.3.2
>Reporter: Konrad Windszus
> Attachments: SLING-4344-v02.patch
>
>
> Currently any modification of a Sling i18n message will not invalidate the
> {{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
> because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
> basename and contents only outside of the resource resolver's search path are
> always empty
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
> I would argue that it should be allowed to place language nodes anywhere in
> the repository, which seems to work well except for the cache invalidation.
> The problem is in the {{loadFully}} method
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
> which will only set languageRoots if they are below any of the resource
> resolver's search paths.
> To reproduce the issue you can just add the following node structure
> {code}
> /content/languages
>+-- English (nt:folder, mix:language)
>|+-- jcr:language = en
>|+-- basename = myuniquebasename
>|+-- m1 (sling:messageEntry)
>||+-- sling:key = "msg001"
>||+-- sling:message = "This is a message"
> {code}
> Then load the key from this resource bundle (by giving the right basename).
> It will internally put the resource bundle into the cache (although all
> contents of the given resource bundle are outside any of the default search
> paths /apps or /libs). Whenever you change the message that won't be
> reflected, because the resource bundle cache is not invalidated (caused by
> the empty {{languageRoots}}) therefore the old message would still be
> exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4344) Modifying i18n language node in a path outside the resource resolver's search path will not invalidate the ResourceBundle cache
[
https://issues.apache.org/jira/browse/SLING-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14288202#comment-14288202
]
Carsten Ziegeler commented on SLING-4344:
-
[~kwin] Patch lgtm
> Modifying i18n language node in a path outside the resource resolver's search
> path will not invalidate the ResourceBundle cache
> ---
>
> Key: SLING-4344
> URL: https://issues.apache.org/jira/browse/SLING-4344
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: i18n 2.3.2
>Reporter: Konrad Windszus
> Attachments: SLING-4344-v02.patch
>
>
> Currently any modification of a Sling i18n message will not invalidate the
> {{resourceBundleCache}} in the {{JcrResourceBundleProvide}}
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L118),
> because the {{languageRoots}} for a {{JcrResourceBundle}} with a unique
> basename and contents only outside of the resource resolver's search path are
> always empty
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L211).
> I would argue that it should be allowed to place language nodes anywhere in
> the repository, which seems to work well except for the cache invalidation.
> The problem is in the {{loadFully}} method
> (https://github.com/apache/sling/blob/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundle.java#L155)
> which will only set languageRoots if they are below any of the resource
> resolver's search paths.
> To reproduce the issue you can just add the following node structure
> {code}
> /content/languages
>+-- English (nt:folder, mix:language)
>|+-- jcr:language = en
>|+-- basename = myuniquebasename
>|+-- m1 (sling:messageEntry)
>||+-- sling:key = "msg001"
>||+-- sling:message = "This is a message"
> {code}
> Then load the key from this resource bundle (by giving the right basename).
> It will internally put the resource bundle into the cache (although all
> contents of the given resource bundle are outside any of the default search
> paths /apps or /libs). Whenever you change the message that won't be
> reflected, because the resource bundle cache is not invalidated (caused by
> the empty {{languageRoots}}) therefore the old message would still be
> exposed, until you restart the Sling i18n bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
