Continuing in this thought of using FilterChains to implement sed, grep, tr, etc. . . . I've been thinking about it between other tasks, and tonight I sat and looked at the existing filter chains and the ORO library.
I don't know if it's allowed to have something like jakarta-oro be a dependency in the core tasks, types, etc. But if that library was allowed in there, several of the existing built-in FilterReaders could be eliminated (if desired), in place of a more flexible, general purpose way of performing pattern-based file stream transformations. LineContains, LineContainsRegExp, ReplaceTokens, StripLineBreaks, StripLineComments, TabsToSpaces can be thought of as a small library of fixed substitutions or transformations. In UNIX these could all be done with grep, sed or tr (in more than one way), for example: LineContains = grep string file LineContainsRegExp = grep 'regex' file ReplaceTokens = sed 's/pattern/value/g' file StripLineBreaks = tr -d '\r\n' < file StripLineComments = sed '/pattern/d' file TabsToSpaces = tr '\t' ' ' < file The Jakarta ORO library provides a very graceful API for matching and replacing patterns. It's flexibility would make the whole FilterChain concept extremely extensible and flexible with minimal code writing. My only question at this point is how much trouble it would be to use it in the context of a FilterReader's read() method, where everything is based on reading a line and returning ints, one character at a time. Scott Stirling -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
