Ah...Ok. Thanks for the additional info. I think the new spec resource type change is here to stay, so it's just matter of cleaning up whatever pieces used to work the old way. The overall result being that Tapestry no longer ignores classpath resources (except for assets / things it has always handled) in a way that makes any resource resolution done globally work whether people stick things in the classpath / context / mixture of the two.
On 5/7/07, Ben Dotte <[EMAIL PROTECTED]> wrote:
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]
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
