camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Gredler" <dgred...@dhlglobalmail.com>
Subject file component ant path matcher
Date Tue, 06 Dec 2011 15:42:46 GMT
Hi all,

I've used the file ant path matching functionality that comes with
camel-spring [1] five or six times now, and my experience is that while
the advanced "includes" + "excludes" functionality is good to have, most
of the time I just need a single include pattern, e.g. "**/*.txt" or
something along those lines.

When this is the case, and you are using the Java DSL instead of the
Spring XML to configure Camel, it's very annoying (and bug-prone?) to
have to define your filter far away from the place that it is used. So I
made this specific (perhaps common?) use case nicer by implementing a
String -> GenericFileFilter converter, so that you can say e.g.:

from("file:blah/foo?recursive=true&filter=**/*.txt")
  .to(...);

Instead of:

from("file:blah/foo?recursive=true&filter=#myRecursiveTxtFilter")
  .to(...);

In the first example above, the "**/*.txt" filter string gets
automatically converted into a AntPathMatcherGenericFileFilter where
includes = "**/*.txt".

The only questionable thing about it is that
AntPathMatcherGenericFileFilter implements CamelContextAware, so this
converter also needs to know about the CamelContext so that it can pass
that information on to AntPathMatcherGenericFileFilter, which it uses
internally.

So, with that background, does this converter sound like something that
would be useful in camel-core or camel-spring
(AntPathMatcherGenericFileFilter is in camel-core, but
SpringAntPathMatcherFileFilter is in camel-spring)? I can submit it as
an enhancement via JIRA, but I wasn't sure whether others would find it
useful or not.

Take care,

Daniel

[1]
http://camel.apache.org/file2.html#File2-FilteringusingANTpathmatcher

Mime
View raw message