In message <[EMAIL PROTECTED]>, "Thomas Zillinger" writes: >I understand that by design it seems that GlobFilenameFilter only evaluates >the pathname.getName() part of a file (see RegexFilenameFilter). I was
It's required by the FileFilter and FilenameFilter interfaces. That's how they're expected to work. >wondering if it is easy to write a 'GlobFileFilter' which evaluates the >whole path of a file so I could pass it a pattern like: > myimages/lang_*/*.gif >and it correctly accepts a path like: > D:/mywebapp/myimages/lang_en/test.gif If you want to do this for your own purposes (as opposed to passing the filter to a class like JFileChooser which expects the FileFilter interface contract to be fulfilled), it's not easy to subclass GlobFilenameFilter for that purpose because the matcher and pattern in RegexFilenameFilter are not protected. Otherwise, you'd just override accept to return _matcher.matches(pathname.getAbsolutePath(), _pattern). So I'd say you've exposed what is arguably a design flaw. If there's a desire to make RegexFilenameFilter more customizable, would folks prefer that the matcher and pattern be made protected or for a public or protected accept(String) method be added? Or both? accept(File dir, String filename) would be implemented asl accept(filename) and accept(File pathname) would call accept(pathname.getName()). That way, to do what you want you'd just have to override accept(File pathname) and make it call accept(pathname.getAbsolutePath()). We're in between minor version number releases (2.1 will be the next release) so now's the time to get in your API addition requests. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]