> > I didn't look at the patch - but doesn't this mean you'll have to put the > properties file in path accessible to the resource loader? >
Yes. I'm not aware of the best practices/current style of where to put properties files, but Torque has them mixed in with the templates. Well, and the test bed naturally has the properties files mixed in with the templates also. Hm. Shoot. So I suppose you're saying it's not good to force a resource loader to be used in loading a properties file? I thought it made things a lot cleaner, but I was under the assumption that properties files wouldn't be coming in from places not already available to the resource loader(s). Perhaps I'm missing some, but the only location properties could be that perhaps works in the current PropertiesUtil but not the patch is if they're referred to with a full path (e.g. c:\offinanotherdir) or relative paths that back out of the dir the file resource loader is pointed at (e.g. ..\..\..\clearbackhere). Yeah, and I just reviewed FileResourceLoader and it looks like your specifically trying to prevent that with the StringUtils.normalizePath stuff. So, assuming this will break lots of Texen code (?), what if after trying Velocity's resource loader, if a ResourceNotFoundException occurs from the RuntimeSingleton.getContent, I just in some code that tries loading the properties file off the hard drive? If the properties file was in the classpath, template path, or any other resource, it would have been found by Velocity, so it'd only have to try loading with the path as is and not worry about calculating any template path stuff. Thanks, Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
