You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Olivier Le Merdy (JIRA)" <ji...@apache.org> on 2013/09/06 11:32:52 UTC

[jira] [Created] (TAP5-2172) ComponentClassResolver does not resolve logical name to the more intuitive component

Olivier Le Merdy created TAP5-2172:
--------------------------------------

             Summary: ComponentClassResolver does not resolve logical name to the more intuitive component
                 Key: TAP5-2172
                 URL: https://issues.apache.org/jira/browse/TAP5-2172
             Project: Tapestry 5
          Issue Type: Bug
          Components: tapestry-core
    Affects Versions: 5.3.7
            Reporter: Olivier Le Merdy
            Priority: Minor


ComponentClassResolver does not always resolve components the more intuitive way.

See attached sample project for demonstration purposes but given a set of three components: "foo/Bar", "foo/FooBar" and "foo/BarFoo", the logical name "foo/bar" will be resolved to "foo/FooBar" component instead of the more intuitive "foo/Bar".

The workaround is to rename our components but, given the stripping can happen at multiple package levels, it is sometimes hard to predict (and debug) what is happening, e.g.: "layout/detail/Section" logical name will resolve primarily "layout/detail/SectionLayout" component instead of "layout/detail/Section" component.

Looking at ComponentClassResolverImpl implementation, the component name cache is filled following classpath alphabetical order, overriding any previous entry found.

Could it be possible to privilege a component when its unstripped name exactly match its logical name?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira