As an example, we have a component collective.md.ui.components.AssetEdit. For the NLS keys on that component, we want Tapestry to look for AssetEdit.properties under the context root/WEB-INF/app before it looks under the class path root/collective/md/ui/components. This is the behavior Tapestry used to have but now it looks on the classpath first.
Thanks for taking a look. -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 4:51 PM To: Tapestry users Subject: Re: 4.1.2 snapshot changes 4-20 to 4-30 It's fine, report things as much as you like. Spec resolution logic has changed so it makes sense that there are side effects. What is the exact problem (expected vs. actual) happening now? I know generally what you mean but properties get resolved by a completely different service so the patterns are different. On 5/7/07, Ben Dotte <[EMAIL PROTECTED]> wrote: > > Our templates are still getting resolved on WEB-INF/app just fine, but I > just found out we have a problem with NLS .properties files getting > resolved that is the same as the template resolution problem. > > So it looks like Tapestry is now looking on the classpath first for > .properties files whereas it used to look on the context first > (specifically for us this would also be WEB-INF/app). Would it be > possible to change this back to look at the context first like it used > to? > > Sorry to bother with this yet again! > > Thanks, > Ben > > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
