On 23.06.2011 16:51, Christopher Schultz wrote: > Rainer, > > On 6/23/2011 10:39 AM, Rainer Jung wrote: >> Globs in the file name and not >> the directory part is the most important use case and easy to understand >> in its consequences. So I lean towards this type of improvement right now. > > So: > > /path/to/*.jar (allowed today) > /path/to/foo*.jar (proposed) > /path/*/foo.jar (not proposed) > /path/**/foo.jar (ant-style "**" for "any depth", not proposed) > > ? > > Any reason not to allow globs in the non-filename path portion? I can't > really see a use case for actually wanting a path-glob but am interested > in your reasoning.
I think there are no very strong arguments for or against supporting globs in directory names and supporting **. I just finished the implementation for only supporting globs in the file name part and that's actually very simple using the util class we already have today. I'd say when defining the class path for Tomcat you want some kind of strictness to avoid unexpected stuff to get loaded. We allow to shortcut the jar list at the moment by loading all Jars from a directory (the *.jar pattern), but I feel a bit uncomfortable with searching recursive via ** and also about whether people understand what it means to include matched directories. The use case I have in mind, is some directoyr with extensions, where you install all of them, but want to choose which ones to load. At the moment you do it by listing all Jars explicitely. Now when upgrading the dependencies and the Jars have versions in their name, you have to update all your CATALINA_BASE/catalina.properties, because you had to include the explicit file names. Using globs like log4j-1.2.*.jar you can keep the config stable for a longer time. Will post a patch to inspect once my testing is done. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
