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