[TAP5-2659] Direct instantiation of ComponentResourceSelector should be replaced with delegation to ComponentRequestSelectorAnalyzer

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 5.6.2, 5.7.0
• Component/s: tapestry-core
• Assignee: Thiago Henrique De Paula Figueiredo
• Reporter: Dmitry Gusev
• Created: 11/Jan/21 16:44
• Updated: 20/Jun/21 07:50
• Resolved: 30/Jan/21 13:54

Description

Some implementation methods in tapestry core still use direct instantiation of ComponentResourceSelector instead of delegating to ComponentRequestSelectorAnalyzer, namely:

in ComponentMessageSourceImpl.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));
} 

in ComponentTemplateSourceImpl.java

 

public ComponentTemplate getTemplate(ComponentModel componentModel, Locale locale)
{
    return getTemplate(componentModel, new ComponentResourceSelector(locale));
}

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.:

public Messages getMessages(ComponentModel componentModel, Locale locale)
{
    Locale original = threadLocale.getLocale();

    try
    {
        threadLocale.setLocale(locale);

        return getMessages(componentModel, analyzer.buildSelectorForRequest());
    }
    finally
    {
        threadLocale.setLocale(original);
    }
}

{{}}