[jira] Commented: (IO-71) [io] PipedUtils
[ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567523#action_12567523 ] David Smiley commented on IO-71: Sorry if I was not clear in my description. I do in fact use PipedInput & Output streams within my code to do much of the work. I went to use them straight-up on a project but then found some shortcomings (not necessarily a problem for everyone out there but for my project any way). There are two things that those JDK classes don't do: IOException and close() propagation. The reader of a PipedInputStream won't get the actual IOException of the problem if the other side of the pipe pukes for whatever reason. And closing the PipedInputStream doesn't close a source InputStream from where the data actually came from in the first place. And by the way, the reading and writing needs to occur on separate threads which can be awkward. My PipedUtils wraps that up neatly to make all this easy. See PipedUtilsTest which goes back and forth through this process with a a bear minimum of code. > [io] PipedUtils > --- > > Key: IO-71 > URL: https://issues.apache.org/jira/browse/IO-71 > Project: Commons IO > Issue Type: Improvement > Components: Utilities > Environment: Operating System: All > Platform: All >Reporter: David Smiley >Priority: Minor > Fix For: 2.x > > Attachments: PipedUtils.zip > > > I developed some nifty code that takes an OutputStream and sort of reverses > it as if it were an > InputStream. Error passing and handling close is dealt with. It needs > another thread to do the work > which runs in parallel. It uses Piped streams. I created this because I > had to conform > GZIPOutputStream to my framework which demanded an InputStream. > See URL to source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567503#action_12567503
]
Gary Gregory commented on IO-119:
-
I know I am jumping in the middle here, but I must say that I do not agree with
last comment. Well, this style is optional since you do not have to cascade
method invocations like this, so I'm just stating this for discussion.
IMO, an API should not be designed for typing convenience. When I think about
code and its life cycle, I think about clarity. I think code should express
ideas as clearly as possible, whether or not this expression is succinct does
not matter to me.
The amount of time spent by one person witting new code is minuscule compared
the amount of time that will be spent by many people over the months and years
of that code's lifetime. So I rarely use cascading method invocation, since
it's never clear (unlike in Smalltalk) who the receiver of the method really
is. IDE code formatters also do not know that something is a 'builder' and
usually mess up all of that careful spacing.
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SCXML-67) can't have
[
https://issues.apache.org/jira/browse/SCXML-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567501#action_12567501
]
SeongSoo, Park commented on SCXML-67:
-
Thanks for your fix. I will try to test for it.
> can't have
> --
>
> Key: SCXML-67
> URL: https://issues.apache.org/jira/browse/SCXML-67
> Project: Commons SCXML
> Issue Type: Bug
>Affects Versions: 0.7
>Reporter: SeongSoo, Park
> Fix For: 0.8
>
>
> According to the latest SCXML W/D the can have as its
> child.
> But, Commons SCXML 0.7 doesn't seems to support that.
> The org.apache.commons.scxml.io.SCXMLParser can't parse this scxml doc.
>
> http://www.w3.org/2005/07/scxml"; version="1.0"
> initialstate="microwave">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The SCXML engine generates the following exception during parsing the scxml
> doc.
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.scxml.model.Parallel
> at
> org.apache.commons.scxml.io.ModelUpdater.updateState(ModelUpdater.java:213)
> at
> org.apache.commons.scxml.io.ModelUpdater.updateSCXML(ModelUpdater.java:78)
> at org.apache.commons.scxml.io.SCXMLParser.parse(SCXMLParser.java:268)
> at org.apache.commons.scxml.io.SCXMLParser.parse(SCXMLParser.java:152)
> at
> org.apache.commons.scxml.test.StandaloneUtils.execute(StandaloneUtils.java:80)
> at
> org.apache.commons.scxml.test.StandaloneJexlExpressions.main(StandaloneJexlExpressions.java:60)
> So, I fixed the 'updateState()' in org.apache.commons.scxml.io.ModelUpdater
> class like this
> (and also org.apache.commons.scxml.io.SCXMLSerializer.serializeState() )
> ..
> } else {
> Iterator j = c.keySet().iterator();
> /* your code
> while (j.hasNext()) {
> updateState((State) c.get(j.next()), targets);
> }
> */
> /* --- my fixed code -*/
> while (j.hasNext()) {
>TransitionTarget tt = (TransitionTarget) c.get(j.next());
> if (tt instanceof State) {
>updateState((State) tt, targets);
> } else {
>updateParallel((Parallel) tt, targets);
>}
>}
> /* */
> }
> } /* end of 'updateState()' */
> So, the engine works well.
> I think this is a critical bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-244) Connection socket hangs sporadically in DBCP 1.2.2 but not 1.2.1
[ https://issues.apache.org/jira/browse/DBCP-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567500#action_12567500 ] ori commented on DBCP-244: -- Phil, I've tried your suggestion for about seven days in the live environment with no luck so far. Looking at the source code, it seems like an excellent guess. But I have not been able to induce the exception. > Connection socket hangs sporadically in DBCP 1.2.2 but not 1.2.1 > > > Key: DBCP-244 > URL: https://issues.apache.org/jira/browse/DBCP-244 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.2 > Environment: Fedora Core 3, MySQL 4.1.22. with the latest driver > (5.07). Exceptions only occur in the "job processing" JVM, which sits idle > for long periods of time and occasionally wakes up to interact with the > database. >Reporter: ori > Fix For: 1.3 > > > I think I've traced an exception to DBCP's code. > Communication with the database is hanging sporadically in a production > environment. If I don't set the socketTimeout property on the underlying > connection, it will hang forever. With the socketTimeout property, I get the > following exception: > --- > com.mysql.jdbc.CommunicationsException: Communications link failure due to > underlying exception: > ** BEGIN NESTED EXCEPTION ** > java.net.SocketTimeoutException > MESSAGE: Read timed out > STACKTRACE: > java.net.SocketTimeoutException: Read timed out >at java.net.SocketInputStream.socketRead0(Native Method) >at java.net.SocketInputStream.read(SocketInputStream.java:129) >at > com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:113) >at > com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:160) >at > com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:188) >at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1994) >at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2411) >at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2916) >at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1631) >at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1723) >at com.mysql.jdbc.Connection.execSQL(Connection.java:3250) >at com.mysql.jdbc.Statement.executeUpdate(Statement.java:1355) >at com.mysql.jdbc.Statement.executeUpdate(Statement.java:1270) >at > org.apache.commons.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) > ... > --- > It always happens in an infrequently used JVM (not an app server handling > frequent connections). So it's likely the offending connection was asleep for > a long time before the exception occurs. > I've confirmed that this issue only occurs using 1.2.2 and not 1.2.1. I've > been looking through the changelogs but can't find anything that would cause > this behavior. > Does somebody familiar with the codebase have any idea what change > (1.2.1->1.2.2) could be causing this behavior? > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-188) Make Complex and Fraction classes immutable and thus thread-safe
[ https://issues.apache.org/jira/browse/MATH-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-188. -- Resolution: Fixed Patch and Complex deprecation applied in r 620373. Thanks! > Make Complex and Fraction classes immutable and thus thread-safe > > > Key: MATH-188 > URL: https://issues.apache.org/jira/browse/MATH-188 > Project: Commons Math > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.2 > > Attachments: Fraction.patch > > > There are many classes with instance fields that could be made final. > Two in particular seem like ideal candidates: > Complex - fields: real, imaginary > Fraction - fields: numerator, denominator (the private reduce() method also > needs to be inlined) > As far as I can tell, making the above changes makes the classes immutable > and therefore threadsafe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-184) cumulativeProbability((double)n, (double)n) returns 0 for integer distributions
[ https://issues.apache.org/jira/browse/MATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-184. -- Resolution: Fixed Fixed in r 620368. Thanks for reporting this. > cumulativeProbability((double)n, (double)n) returns 0 for integer > distributions > --- > > Key: MATH-184 > URL: https://issues.apache.org/jira/browse/MATH-184 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.1, 1.2 >Reporter: Yegor Bryukhov >Priority: Minor > Fix For: 1.2 > > > cumulativeProbability((double)n, (double)n) returns 0 for > discrete/integer distributions > I suppose AbstractIntegerDistribution.cumulativeProbability(double, > double) should be overridden to call its (int, int) version instead of > using default one from AbstractDistribution -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-180. -- Resolution: Fixed > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567488#action_12567488
]
Niall Pemberton commented on IO-119:
Mine is reduce typing, makes it very easy with auto-complete - just keep
hitting period and one or two letters to add another condition.
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567485#action_12567485 ] Niall Pemberton commented on MATH-180: -- I don't think so, I re-built math yesteray and checked that nothing had changed OSGi wise (and none of the commits since affect it) - so looks good to go from my PoV > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567476#action_12567476 ] Phil Steitz commented on MATH-180: -- Is there anything else we need to do on this before cutting math 1.2? > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-188) Make Complex and Fraction classes immutable and thus thread-safe
[ https://issues.apache.org/jira/browse/MATH-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-188: - Fix Version/s: 1.2 > Make Complex and Fraction classes immutable and thus thread-safe > > > Key: MATH-188 > URL: https://issues.apache.org/jira/browse/MATH-188 > Project: Commons Math > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.2 > > Attachments: Fraction.patch > > > There are many classes with instance fields that could be made final. > Two in particular seem like ideal candidates: > Complex - fields: real, imaginary > Fraction - fields: numerator, denominator (the private reduce() method also > needs to be inlined) > As far as I can tell, making the above changes makes the classes immutable > and therefore threadsafe. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-187) MatrixUtils - are these supposed to have a public or package scope constructor?
[
https://issues.apache.org/jira/browse/MATH-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved MATH-187.
--
Resolution: Fixed
Fixed in r 620330.
Thanks!
> MatrixUtils - are these supposed to have a public or package scope
> constructor?
> ---
>
> Key: MATH-187
> URL: https://issues.apache.org/jira/browse/MATH-187
> Project: Commons Math
> Issue Type: Bug
>Reporter: Sebb
>Priority: Minor
>
> Package or public?
> {code}
> /**
> * Default constructor. Package scope to prevent unwanted instantiation.
> */
> public MatrixUtils() {
> super();
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-184) cumulativeProbability((double)n, (double)n) returns 0 for integer distributions
[ https://issues.apache.org/jira/browse/MATH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-184: - Fix Version/s: 1.2 Summary: cumulativeProbability((double)n, (double)n) returns 0 for integer distributions (was: cumulativeProbability((double)n, (double)n) returns 0 for integer distributions ) > cumulativeProbability((double)n, (double)n) returns 0 for integer > distributions > --- > > Key: MATH-184 > URL: https://issues.apache.org/jira/browse/MATH-184 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.1, 1.2 >Reporter: Yegor Bryukhov >Priority: Minor > Fix For: 1.2 > > > cumulativeProbability((double)n, (double)n) returns 0 for > discrete/integer distributions > I suppose AbstractIntegerDistribution.cumulativeProbability(double, > double) should be overridden to call its (int, int) version instead of > using default one from AbstractDistribution -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JXPATH-118) wrongs xpath string from pointer.asPath()
[
https://issues.apache.org/jira/browse/JXPATH-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved JXPATH-118.
Resolution: Cannot Reproduce
I have tried this using jdom 1.1 and cannot reproduce it. I am not using JDK 6
(I use OS X) although I wouldn't expect that to be the source of your problem.
Please reopen this issue when you can submit a test case.
> wrongs xpath string from pointer.asPath()
> -
>
> Key: JXPATH-118
> URL: https://issues.apache.org/jira/browse/JXPATH-118
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: Nightly Builds
> Environment: jdk 1.603 jdom 1.1
>Reporter: David Croé
>
> Hello !
> after playing around awhile with JXPath and Jdom i guess i've found a bug:
> when trying to iterate over a html document parsed with jdom in this way:
> iterator = context.iteratePointers("/HTML[1]/BODY[1]/P[3]/TABLE[1]/TR/TD[3]");
>
> while(iterator.hasNext()){
> Pointer pointer = (Pointer)iterator.next();
> System.out.println("path:"+
> pointer.asPath()+":"+((Content)pointer.getNode()).getValue());
> }
> i get some wrong outputs.
> this shows sometime the wrong path for example:
> /HTML[1]/BODY[1]/P[3]/TABLE[1]/TR[2]/TD[1]
> but the value found is correct. I
> i would expect for example
> /HTML[1]/BODY[1]/P[3]/TABLE[1]/TR[2]/TD[3]
> Am i wrong or is this a bug !?
> greetings
> david croe
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JXPATH-117) ClassCastException using iteratePointer with JDom
[ https://issues.apache.org/jira/browse/JXPATH-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved JXPATH-117. Resolution: Cannot Reproduce I have tried this using jdom 1.1 and cannot reproduce it. I am not using JDK 6 (I use OS X) although I wouldn't expect that to be the source of your problem. Please reopen this issue when you can submit a test case. > ClassCastException using iteratePointer with JDom > - > > Key: JXPATH-117 > URL: https://issues.apache.org/jira/browse/JXPATH-117 > Project: Commons JXPath > Issue Type: Bug > Environment: jdk 1.603 jdom 1.1 >Reporter: David Croé > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > Hello i think i've found a bug in the latest nightly build > There is a ClassCastException JDOMNodeIterator cannot be cast to > PropertyIterator when using > iteratePointers with JDom. > Let me know if you need more informations. > i guess that the bug is in PrecedingOrFollowingContext.java line 151 of the > head version > There is a cast to PropertyIterator , but i think it should be a cast to > NodeIterator > Greetings > david croe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-233) Allow connection, statement, and result set to be closed multiple times
[ https://issues.apache.org/jira/browse/DBCP-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567468#action_12567468 ] Phil Steitz commented on DBCP-233: -- How does you code get connections and where are the exceptions occurring? The changes and tests committed should ensure that connection handles obtained from DBCP datasources can be closed multiple times without exceptions being generated. > Allow connection, statement, and result set to be closed multiple times > --- > > Key: DBCP-233 > URL: https://issues.apache.org/jira/browse/DBCP-233 > Project: Commons Dbcp > Issue Type: Improvement >Reporter: Dain Sundstrom > Fix For: 1.3 > > Attachments: CloseTwice.patch > > > This patch allows Connection, Statement, PreparedStatement, CallableStatement > and ResultSet to be closed multiple times. The first time close is called > the resource is closed and any subsequent calls have no effect. This > behavior is required as per the JavaDocs for these classes. The patch adds > tests for closing all types multiple times and updates any tests that > incorrectly assert that a resource can be closed more then once. > This patch fixes DBCP-134 and DBCP-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-119) Convenience "Builder" for creating complex FileFilter conditions
[
https://issues.apache.org/jira/browse/IO-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567451#action_12567451
]
Jukka Zitting commented on IO-119:
--
Yes, FileFilterUtils covers the Factory pattern, but it doesn't really reduce
the required typing (or more importantly for those with a modern IDE, the
amount of characters on a line). For example, the only benefit of
{{FileFilterUtils.suffixFileFilter(".java")}} (or {{suffixFileFilter(".java")}}
with static imports) over {{new SuffixFileFilter(".java")}} is one less import
statement.
What's your use case for adding the Builder class? Do you just want to reduce
the amount of typing when creating complex filters, or are your incrementally
building filters based on user input or some parsed filter description?
> Convenience "Builder" for creating complex FileFilter conditions
>
>
> Key: IO-119
> URL: https://issues.apache.org/jira/browse/IO-119
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 1.3.1
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 2.x
>
> Attachments: FileFilterBuilder.java, FileFilterBuilderTestCase.java
>
>
> I'd like to add a new convenience "builder" class (FileFilterBuilder) to make
> it easier to create complex FileFilter using Commons IO's IOFileFilter
> implementations.
> Heres an example of how it can be used to create a IOFileFilter for the
> following conditions:
> - Either, directories which are not hidden and not named ".svn"
> - or, files which have a suffix of ".java"
> IOFileFilter filter = FileFilterBuilder.orBuilder()
> .and().isDirectory().isHidden(false).not().name(".svn").end()
> .and().isFile().suffix(".java").end()
> .getFileFilter();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
