On 23/09/2013 09:08, Rainer Jung wrote: > On 23.09.2013 17:27, Mark Thomas wrote: >> I've mentioned on a couple of different threads that refactoring how the >> class loader accesses resources was on my TODO list. I haven't done any >> implementation yet but I have some ideas that I wanted to get some >> feedback on before I start work. >> >> The things I have in mind at this point are: >> - Extracting anything into the work directory feels like a hack >> - The class loader should use the same API as every other component >> - The class loader needs URLs that actually work >> - The anti-locking options are responsible for a number of the hacks in >> the class loader >> >> The solution I have in mind is along the following lines: >> - Add a new getClassLoaderResource() to the WebResources interfaces. >> This will implement the standard WEB-INF/classes then JARs in >> WEB-INF/lib search order. It should be able to do this without any >> extraction into the work directory. > > A useful feature in TC 6/7 was to add search paths outside of the war to > look for config files in order to provide config options special to > deployment environments without working with individual war files (via > VirtualWebappLoader). > > I know it is possible with the current resource implementation in TC 8, > but will it also be possible after this change, i.e. if the webapp > retrieves a config file as a resource via the webapp class loader, can > we still configure additional directories to be searched for the resource?
Yes (assuming I don't mess up the implementation). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
