Fair enough, it has to do with the way we handle client-specific functionality. Eclipse copies everything, templates, .class files, and .properties files to the classpath that Jetty uses (for local deployments). We have a separate process that builds the context for us that includes client-specific overrides of the templates and .properties files. So, one client might have a different version of AssetEdit.html than the default AssetEdit.html, for example, and we want that client-specific version to get displayed. This is why it was a problem for us that Tapestry tried to search the classpath for templates first before checking the context.
I realize this is very specific to our setup but since Tapestry used to check the context first for templates and .properties files anyway it hasn't been a problem up until these changes started taking place. -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 5:10 PM To: Tapestry users Subject: Re: 4.1.2 snapshot changes 4-20 to 4-30 Right....I get that it's looking in the classpath first - but why is that a problem ? On 5/7/07, Ben Dotte <[EMAIL PROTECTED]> wrote: > > 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] > > -- 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]
