[ http://issues.apache.org/jira/browse/TAPESTRY-645?page=comments#action_12329858 ]
Adam Greene commented on TAPESTRY-645: -------------------------------------- The problem lies within this line in org.apache.tapestry.services.impl.ComponentMessageSourceImpl: Resource specificationLocation = component.getSpecification().getSpecificationLocation(); As you can see it looks for the specification location as the root for looking up the properties file. If you don't have a page file, then the specification location is most likely the classpath to the page's class. I haven't delved very deep into this, it is just that I have spent a great deal of time in the the ComponentMessageSource stuff lately (modified it for a project I'm working on). > Properties file search procedure > -------------------------------- > > Key: TAPESTRY-645 > URL: http://issues.apache.org/jira/browse/TAPESTRY-645 > Project: Tapestry > Type: Bug > Components: Framework > Versions: 4.0 > Reporter: Kevin J. Menard, Jr. > > There seems to be an inconsistency with the properties file search procedure. > If I have something like: > context/blah/Page.html > context/blah/Page.page > context/blah/Page.properties > then all is good. The .properties file is found and the values pulled out > appropriately. > If the .page file is removed, however, the .properties file is not found and > loaded. Note that in this case, the .page file really contains nothing but > the bare minimum. > Since page specs are optional, it seems inconsistent that their presence or > lack thereof affects the search path for the properties files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
