[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366113#comment-17366113
]
Gamel Alomaisi commented on TAP5-2659:
--
T
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
> Fix For: 5.6.2, 5.7.0
>
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275664#comment-17275664
]
Hudson commented on TAP5-2659:
--
SUCCESS: Integrated in Jenkins build Tapestry » tapestry-5.6-freestyle #12 (See
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-5.6-freestyle/12/])
TAP5-2659: fixing bad merge again (thiago: rev
7edee2995d0d17401f4c0bfd40a316d7a04ad276)
* (edit)
tapestry-core/src/test/java/org/apache/tapestry5/internal/services/ComponentMessagesSourceImplTest.java
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
> Fix For: 5.6.2, 5.7.0
>
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275654#comment-17275654
]
ASF subversion and git services commented on TAP5-2659:
---
Commit 7edee2995d0d17401f4c0bfd40a316d7a04ad276 in tapestry-5's branch
refs/heads/5.6.x from Thiago H. de Paula Figueiredo
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=7edee29 ]
TAP5-2659: fixing bad merge again
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
> Fix For: 5.6.2, 5.7.0
>
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275647#comment-17275647
]
Hudson commented on TAP5-2659:
--
SUCCESS: Integrated in Jenkins build Tapestry » tapestry-trunk-freestyle #68
(See
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-trunk-freestyle/68/])
TAP5-2659: wrong locale being picked up when using axis (thiago: rev
b4e776a80c70ef0e8caf81d15356078c840215b0)
* (edit)
tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ComponentMessagesSourceImpl.java
* (edit)
tapestry-core/src/test/java/org/apache/tapestry5/internal/services/ComponentMessagesSourceImplTest.java
* (edit)
tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ComponentTemplateSourceImpl.java
* (edit)
tapestry-core/src/test/java/org/apache/tapestry5/internal/services/ComponentTemplateSourceImplTest.java
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
> Fix For: 5.6.2, 5.7.0
>
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275616#comment-17275616
]
Hudson commented on TAP5-2659:
--
FAILURE: Integrated in Jenkins build Tapestry » tapestry-5.6-freestyle #11 (See
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-5.6-freestyle/11/])
TAP5-2659: fixing bad merge (thiago: rev
4003ff2f7c1bc646e670757a6b1c000fc178432f)
* (edit)
tapestry-core/src/test/java/org/apache/tapestry5/internal/services/ComponentTemplateSourceImplTest.java
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
> Fix For: 5.6.2, 5.7.0
>
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275611#comment-17275611
]
ASF subversion and git services commented on TAP5-2659:
---
Commit 4003ff2f7c1bc646e670757a6b1c000fc178432f in tapestry-5's branch
refs/heads/5.6.x from Thiago H. de Paula Figueiredo
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=4003ff2 ]
TAP5-2659: fixing bad merge
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
> Fix For: 5.6.2, 5.7.0
>
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275597#comment-17275597
]
Hudson commented on TAP5-2659:
--
FAILURE: Integrated in Jenkins build Tapestry » tapestry-5.6-freestyle #10 (See
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-5.6-freestyle/10/])
TAP5-2659: wrong locale being picked up when using axis (thiago: rev
9912bff5450157f1e7605c759a3e7859a340be3e)
* (edit)
tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ComponentMessagesSourceImpl.java
* (edit)
tapestry-core/src/test/java/org/apache/tapestry5/internal/services/ComponentTemplateSourceImplTest.java
* (edit)
tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ComponentTemplateSourceImpl.java
* (edit)
tapestry-core/src/test/java/org/apache/tapestry5/internal/services/ComponentMessagesSourceImplTest.java
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275592#comment-17275592
]
ASF subversion and git services commented on TAP5-2659:
---
Commit 9912bff5450157f1e7605c759a3e7859a340be3e in tapestry-5's branch
refs/heads/5.6.x from Thiago H. de Paula Figueiredo
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=9912bff ]
TAP5-2659: wrong locale being picked up when using axis
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TAP5-2659) Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer
[
https://issues.apache.org/jira/browse/TAP5-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275589#comment-17275589
]
ASF subversion and git services commented on TAP5-2659:
---
Commit b4e776a80c70ef0e8caf81d15356078c840215b0 in tapestry-5's branch
refs/heads/master from Thiago H. de Paula Figueiredo
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=b4e776a ]
TAP5-2659: wrong locale being picked up when using axis
> Direct instantiation of ComponentResourceSelector should be replaced with
> delegation to ComponentRequestSelectorAnalyzer
>
>
> Key: TAP5-2659
> URL: https://issues.apache.org/jira/browse/TAP5-2659
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Reporter: Dmitry Gusev
>Assignee: Thiago Henrique De Paula Figueiredo
>Priority: Major
>
> Some implementation methods in tapestry core still use direct instantiation
> of {{ComponentResourceSelector}} instead of delegating to
> {{ComponentRequestSelectorAnalyzer}}, namely:
> in {{ComponentMessageSourceImpl.java}}
>
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> return getMessages(componentModel, new ComponentResourceSelector(locale));
> }
> public Messages getApplicationCatalog(Locale locale)
> {
> return messagesSource.getMessages(appCatalogBundle, new
> ComponentResourceSelector(locale));
> }
> {code}
> in {{ComponentTemplateSourceImpl.java}}
>
> {code:java}
> public ComponentTemplate getTemplate(ComponentModel componentModel, Locale
> locale)
> {
> return getTemplate(componentModel, new ComponentResourceSelector(locale));
> }{code}
> Which makes it impossible to use axes with message bundles and component
> templates.
>
> Default implementation of {{ComponentRequestSelectorAnalyzer}} interface uses
> {{ThreadLocale}} instead of directly passed Locale instance. To workaround
> this above methods may temporarily set passed locale into ThreadLocal and
> restore original value after `#buildSelectorForRequest` is returned, i.e.:
> {code:java}
> public Messages getMessages(ComponentModel componentModel, Locale locale)
> {
> Locale original = threadLocale.getLocale();
> try
> {
> threadLocale.setLocale(locale);
> return getMessages(componentModel,
> analyzer.buildSelectorForRequest());
> }
> finally
> {
> threadLocale.setLocale(original);
> }
> }{code}
> {{}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
