> As I recall the actual logic is in the Spring JARs, so you are > dependent on camel-spring / Spring modules. > So it would be hard to move such a feature to camel-core. > Alternative is to add java code for the ANT logic in camel-core directly.
Yeah, the weird thing is that AntPathMatcherGenericFileFilter is in camel-core, but it uses classpath checks and reflection magic to use classes in camel-spring. The other weird thing that I just realized is that Camel already contains a AntPathMatcher class very similar to Spring's AntPathMatcher class in the camel-core-xml module. I've posted a patch [1] that moves the AntPathMatcher from camel-core-xml to camel-core, uses it to provide full ant path matching in camel-core without any explicit or implicit dependencies on camel-spring, and I've added the String -> GenericFileFilter converter discussed below. Let me know what you think! Take care, Daniel [1] https://issues.apache.org/jira/browse/CAMEL-4779 -----Original Message----- From: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Wednesday, December 14, 2011 4:38 AM To: dev@camel.apache.org Subject: Re: file component ant path matcher On Tue, Dec 6, 2011 at 4:42 PM, Daniel Gredler <dgred...@dhlglobalmail.com> wrote: > 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. > As I recall the actual logic is in the Spring JARs, so you are dependent on camel-spring / Spring modules. So it would be hard to move such a feature to camel-core. Alternative is to add java code for the ANT logic in camel-core directly. > Take care, > > Daniel > > [1] > http://camel.apache.org/file2.html#File2-FilteringusingANTpathmatcher -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
