You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Daniel Gredler <dg...@dhlglobalmail.com> on 2011/12/06 16:42:46 UTC
file component ant path matcher
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
Re: file component ant path matcher
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Dec 14, 2011 at 11:08 PM, Daniel Gredler
<dg...@dhlglobalmail.com> wrote:
>> 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.
>
Ah yeah in the old days you needed to have camel-spring JAR on the
classpath. Well back them most people had. But then with todays world
where ppl want more choices and OSGi Blueprint etc. we moved some
logic into camel-core-xml for the matcher.
> 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!
>
Perfect that's better, then its in core, and avail for everybody to
use more easily.
Let us take a look when the Camel 2.9.0 has been out of the door.
And thanks for the contributions. Keep em coming :)
> Take care,
>
> Daniel
>
>
> [1] https://issues.apache.org/jira/browse/CAMEL-4779
>
>
>
> -----Original Message-----
> From: Claus Ibsen [mailto:claus.ibsen@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
> <dg...@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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
RE: file component ant path matcher
Posted by Daniel Gredler <dg...@dhlglobalmail.com>.
> 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.ibsen@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
<dg...@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: file component ant path matcher
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Dec 6, 2011 at 4:42 PM, Daniel Gredler
<dg...@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/