[jira] [Commented] (LANG-1085) Add a circuit breaker implementation
[ https://issues.apache.org/jira/browse/LANG-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577713#comment-14577713 ] Bruno P. Kinoshita commented on LANG-1085: -- Hi Oliver! That's our mutual goal :-) but I prefer to transfer the repository to your GitHub account if you are OK with that (alternatively you can drop it and create another one from scratch). So that you have the credit when people look at the provenance of that code. All I did was to break it into a few classes to show what I had in my mind, and mess around with the code. Add a circuit breaker implementation Key: LANG-1085 URL: https://issues.apache.org/jira/browse/LANG-1085 Project: Commons Lang Issue Type: New Feature Components: lang.concurrent.* Reporter: Oliver Heger Attachments: CircuitBreaker.java, CircuitBreakerTest.java A _circuit breaker_ is a useful component to protect an application against unreliable services or load peaks. A simple implementation could be a good fit for the concurrent package. A proposed implementation is attached. Feedback is welcome! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1085) Add a circuit breaker implementation
[ https://issues.apache.org/jira/browse/LANG-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577710#comment-14577710 ] Oliver Heger commented on LANG-1085: Hi Bruno! Some polishing of the code is certainly necessary. We also have to change the package names. I hope that a great deal of comments can be reused from the original patch. Some more has to be written for the newer classes. Regarding repositories: I really don't mind whether my repository or yours or somebody else's is used ;-) The goal is to get the code into [lang]. Add a circuit breaker implementation Key: LANG-1085 URL: https://issues.apache.org/jira/browse/LANG-1085 Project: Commons Lang Issue Type: New Feature Components: lang.concurrent.* Reporter: Oliver Heger Attachments: CircuitBreaker.java, CircuitBreakerTest.java A _circuit breaker_ is a useful component to protect an application against unreliable services or load peaks. A simple implementation could be a good fit for the concurrent package. A proposed implementation is attached. Feedback is welcome! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1085) Add a circuit breaker implementation
[ https://issues.apache.org/jira/browse/LANG-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577733#comment-14577733 ] Oliver Heger commented on LANG-1085: Hi Bruno! It is fine with me either way, but your contribution is nevertheless very important as you turned the original specific use case into a much broader one. Regarding the next steps, I am pretty content with the current state of TimedCircuitBreaker. I will copy (and maybe slightly adapt) the class documentation from the original CircuitBreaker class. The tests should also be pretty complete. Do you want to work on the polishing of the other classes? So what would be easier for our collaboration? Can I somehow grant you direct access to my repository? Add a circuit breaker implementation Key: LANG-1085 URL: https://issues.apache.org/jira/browse/LANG-1085 Project: Commons Lang Issue Type: New Feature Components: lang.concurrent.* Reporter: Oliver Heger Attachments: CircuitBreaker.java, CircuitBreakerTest.java A _circuit breaker_ is a useful component to protect an application against unreliable services or load peaks. A simple implementation could be a good fit for the concurrent package. A proposed implementation is attached. Feedback is welcome! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-480) IOUtils.closeQuietly can throw NullPointerException
[ https://issues.apache.org/jira/browse/IO-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577732#comment-14577732 ] Sebb commented on IO-480: - I think a better fix might be to correct the Javadoc. IOUtils.closeQuietly can throw NullPointerException --- Key: IO-480 URL: https://issues.apache.org/jira/browse/IO-480 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.4 Reporter: Matt Kusnierz Original Estimate: 10m Remaining Estimate: 10m The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions will be ignored. This is not the case, as the code only catches IOExceptions. As this example stack trace shows, it is possible for some InputStreams to throw NullPointerExceptions during close: java.lang.NullPointerException: null at java.io.FilterInputStream.close(FilterInputStream.java:155) ~[na:1.6.0_35] at sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) ~[na:1.6.0_35] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) ~[commons-io-2.1.jar:2.1] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) ~[commons-io-2.1.jar:2.1] Close quietly should do as advertised/suggested and catch all Exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577799#comment-14577799 ] Andy Seaborne commented on COLLECTIONS-442: --- [~tn],[~mbenson] - interesting to hear that. Jena has moved to Java8 and for java.lang.Iterable processing we have mostly adopted streams (or left it alone :-) ). There is still a lot of code where iterators are the design pattern and streams are not the right design so I'll be interested in looking at FluentIterable et al. A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.x Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-479) An Order Statistic Tree
[ https://issues.apache.org/jira/browse/COLLECTIONS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577892#comment-14577892 ] Thomas Neidhart commented on COLLECTIONS-479: - Looking through some old issue, COLLECTIONS-181 talks about the same problem but proposes another solution. From the referenced issue, I like the proposed interface: IndexedSortedMap. In total there are 4 approaches proposed: * create a concrete class with a sorted array as backing data structure * create a decorator with a sorted list as backing data structure * create a concrete class with a counted red-black tree * create a concrete class with an counted AVL tree An Order Statistic Tree --- Key: COLLECTIONS-479 URL: https://issues.apache.org/jira/browse/COLLECTIONS-479 Project: Commons Collections Issue Type: New Feature Reporter: Ajo Fod Priority: Minor Fix For: 4.x Attachments: COLLECTIONS-479.patch, NodeExistsException.java, RedBlackBST.java An order statistic tree http://en.wikipedia.org/wiki/Order_statistic_tree provides two useful properties. The ability to rank arbitrary keys relative to keys existing in the tree AND the ability to retrieve elements from the tree with the given rank. This can be used to find the percentile rank of a key for example. This functionality is not yet provided yet by any of the major libraries AFAIK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1085) Add a circuit breaker implementation
[ https://issues.apache.org/jira/browse/LANG-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577757#comment-14577757 ] Bruno P. Kinoshita commented on LANG-1085: -- Regarding the next steps, I am pretty content with the current state of TimedCircuitBreaker. I will copy (and maybe slightly adapt) the class documentation from the original CircuitBreaker class. The tests should also be pretty complete. Do you want to work on the polishing of the other classes? Excellent! I'll take care of the memory circuit breaker, tests and docs. So what would be easier for our collaboration? Can I somehow grant you direct access to my repository? I think the best would be if you could fork [lang]'s GitHub repository, create a branch for the circuit breaker and move the classes there. I can submit a pull request to your repository. Then you can squash the commits and push a single one as a pull request to [lang]. That would make reviewing the changes very easy, what do you think? Add a circuit breaker implementation Key: LANG-1085 URL: https://issues.apache.org/jira/browse/LANG-1085 Project: Commons Lang Issue Type: New Feature Components: lang.concurrent.* Reporter: Oliver Heger Attachments: CircuitBreaker.java, CircuitBreakerTest.java A _circuit breaker_ is a useful component to protect an application against unreliable services or load peaks. A simple implementation could be a good fit for the concurrent package. A proposed implementation is attached. Feedback is welcome! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-464) Add FluentIterator / FluentIterable implementation
[ https://issues.apache.org/jira/browse/COLLECTIONS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-464. - Resolution: Fixed Fix Version/s: (was: 4.x) 4.1 Implementation finalized together with tests. Pending review from the community. Add FluentIterator / FluentIterable implementation -- Key: COLLECTIONS-464 URL: https://issues.apache.org/jira/browse/COLLECTIONS-464 Project: Commons Collections Issue Type: Sub-task Components: Iterator Reporter: Thomas Neidhart Fix For: 4.1 Add an iterator implementation supporting a fluent API, similar to the Iter class in jena. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1085) Add a circuit breaker implementation
[ https://issues.apache.org/jira/browse/LANG-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577787#comment-14577787 ] Oliver Heger commented on LANG-1085: Ok, I forked the original repository at https://github.com/oheger/commons-lang, created a new branch circuitBreaker_lang1085, and imported the CircuitBreaker classes. So you should be able to start from there. Add a circuit breaker implementation Key: LANG-1085 URL: https://issues.apache.org/jira/browse/LANG-1085 Project: Commons Lang Issue Type: New Feature Components: lang.concurrent.* Reporter: Oliver Heger Attachments: CircuitBreaker.java, CircuitBreakerTest.java A _circuit breaker_ is a useful component to protect an application against unreliable services or load peaks. A simple implementation could be a good fit for the concurrent package. A proposed implementation is attached. Feedback is welcome! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COMPRESS-317) ArrayIndexOutOfBoundsException in ZipArchiveEntry.getMergedFields()
[
https://issues.apache.org/jira/browse/COMPRESS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Werkmeister updated COMPRESS-317:
---
Description:
{{src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java}}
contains the following at line 380 in {{getMergedFields()}}:
{code:java}
zipExtraFields[zipExtraFields.length] = unparseableExtra;
{code}
This will cause an {{ArrayIndexOutOfBoundsException}} when reached.
Note that Apache Ant inherited this bug with commit
[{{2c04d7e}}|https://git-wip-us.apache.org/repos/asf?p=ant.git;a=commitdiff;h=2c04d7e833b4e5dab1a3c5ddfe14b572aea8c112],
which is where I found it; a fix should be ported there too. (The class is
called just {{ZipEntry}} there; full path:
{{src/main/org/apache/tools/zip/ZipEntry.java}})
The correct line is probably one of the following:
{code:java}
zipExtraFields[zipExtraFields.length - 1] = unparseableExtra;
zipExtraFields[extraFields.length] = unparseableExtra;
{code}
They should be equivalent because of the line immediately above line 380, which
creates {{zipExtraFields}} as copy of {{extraFields}} that is one element
longer. It might be worth noting that line 411 of {{ZipArchiveEntry}} uses
{{zipExtraFields.length - 1}}, while line 411 of Ant's {{ZipEntry}} uses
{{extraFields.length}}.
was:
{{src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java}}
contains the following at line 380 in {{getMergedFields()}}:
{code:java}
zipExtraFields[zipExtraFields.length] = unparseableExtra;
{code}
This will cause an {{ArrayIndexOutOfBoundsException}} when reached.
Note that Apache Ant inherited this bug with commit
[{{2c04d7e}}|https://git-wip-us.apache.org/repos/asf?p=ant.git;a=commitdiff;h=2c04d7e833b4e5dab1a3c5ddfe14b572aea8c112],
which is where I found it; a fix should be ported there too. (The class is
called just {{ZipEntry}} there; full path:
{{src/main/org/apache/tools/zip/ZipEntry.java}})
The correct line is probably one of the following:
{code:java}
zipExtraFields[zipExtraFields.length - 1] = unparseableExtra;
zipExtraFields[extraFields.length] = unparseableExtra;
{code}
They should be equivalent because of the line immediately above line 380, which
crease {{zipExtraFields}} as copy of {{extraFields}} that is one element
longer. It might be worth noting that line 411 of {{ZipArchiveEntry}} uses
{{zipExtraFields.length - 1}}, while line 411 of Ant's {{ZipEntry}} uses
{{extraFields.length}}.
ArrayIndexOutOfBoundsException in ZipArchiveEntry.getMergedFields()
---
Key: COMPRESS-317
URL: https://issues.apache.org/jira/browse/COMPRESS-317
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Reporter: Lucas Werkmeister
Priority: Minor
Labels: easyfix
{{src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java}}
contains the following at line 380 in {{getMergedFields()}}:
{code:java}
zipExtraFields[zipExtraFields.length] = unparseableExtra;
{code}
This will cause an {{ArrayIndexOutOfBoundsException}} when reached.
Note that Apache Ant inherited this bug with commit
[{{2c04d7e}}|https://git-wip-us.apache.org/repos/asf?p=ant.git;a=commitdiff;h=2c04d7e833b4e5dab1a3c5ddfe14b572aea8c112],
which is where I found it; a fix should be ported there too. (The class is
called just {{ZipEntry}} there; full path:
{{src/main/org/apache/tools/zip/ZipEntry.java}})
The correct line is probably one of the following:
{code:java}
zipExtraFields[zipExtraFields.length - 1] = unparseableExtra;
zipExtraFields[extraFields.length] = unparseableExtra;
{code}
They should be equivalent because of the line immediately above line 380,
which creates {{zipExtraFields}} as copy of {{extraFields}} that is one
element longer. It might be worth noting that line 411 of {{ZipArchiveEntry}}
uses {{zipExtraFields.length - 1}}, while line 411 of Ant's {{ZipEntry}} uses
{{extraFields.length}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COMPRESS-317) ArrayIndexOutOfBoundsException in ZipArchiveEntry.getMergedFields()
Lucas Werkmeister created COMPRESS-317:
--
Summary: ArrayIndexOutOfBoundsException in
ZipArchiveEntry.getMergedFields()
Key: COMPRESS-317
URL: https://issues.apache.org/jira/browse/COMPRESS-317
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Reporter: Lucas Werkmeister
Priority: Minor
{{src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java}}
contains the following at line 380 in {{getMergedFields()}}:
{code:java}
zipExtraFields[zipExtraFields.length] = unparseableExtra;
{code}
This will cause an {{ArrayIndexOutOfBoundsException}} when reached.
Note that Apache Ant inherited this bug with commit
[{{2c04d7e}}|https://git-wip-us.apache.org/repos/asf?p=ant.git;a=commitdiff;h=2c04d7e833b4e5dab1a3c5ddfe14b572aea8c112],
which is where I found it; a fix should be ported there too. (The class is
called just {{ZipEntry}} there; full path:
{{src/main/org/apache/tools/zip/ZipEntry.java}})
The correct line is probably one of the following:
{code:java}
zipExtraFields[zipExtraFields.length - 1] = unparseableExtra;
zipExtraFields[extraFields.length] = unparseableExtra;
{code}
They should be equivalent because of the line immediately above line 380, which
crease {{zipExtraFields}} as copy of {{extraFields}} that is one element
longer. It might be worth noting that line 411 of {{ZipArchiveEntry}} uses
{{zipExtraFields.length - 1}}, while line 411 of Ant's {{ZipEntry}} uses
{{extraFields.length}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-517) [Collection|List]Utils.[intersection|union] should accept vararg parameters
[ https://issues.apache.org/jira/browse/COLLECTIONS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577876#comment-14577876 ] Thomas Neidhart commented on COLLECTIONS-517: - While working on the patch, I noticed a few things: * CollectionUtils.union and ListUtils.union use a different definition * currently there are no corresponding set operations * Bag would be a much better suited collection than a list with multiple values as return type thus I think the methods in CollectionUtils should be deprecated, and new ones created in SetUtils and IterableUtils. [Collection|List]Utils.[intersection|union] should accept vararg parameters --- Key: COLLECTIONS-517 URL: https://issues.apache.org/jira/browse/COLLECTIONS-517 Project: Commons Collections Issue Type: Improvement Components: Collection, List Affects Versions: 4.0 Reporter: Hollis Waite Priority: Minor Fix For: 4.1 Attachments: COLLECTIONS-517.patch Would be convenient if intersection/union methods accepted arbitrary number of arguments. Two-arg methods could be retained in order to avoid compiler warnings (https://issues.apache.org/jira/browse/COLLECTIONS-481?focusedCommentId=13762173page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13762173). Alternatively, method could be overloaded to accept a single Iterable of Lists/Sets. I could create a patch for this if it's deemed worthwhile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577759#comment-14577759 ] Thomas Neidhart commented on COLLECTIONS-442: - Sorry for the delay, but most of the proposed contributions have now been integrated in commons-collections (see the related sub-tasks). The proposed Iter class has been re-designed for the Iterable interface (see FluentIterable). Most of the methods in Iter have been added, with a few exceptions: fold, reduce - they require additional functional interfaces. Currently it is unclear how to proceed with the functional part in collections, especially considering all the changes in Java 8. It would be quite easy to add them later on if needed though. A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.x Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLI-252) LongOpt falsely detected as ambiguous
[ https://issues.apache.org/jira/browse/CLI-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578361#comment-14578361 ] ASF GitHub Bot commented on CLI-252: Github user asfgit closed the pull request at: https://github.com/apache/commons-cli/pull/2 LongOpt falsely detected as ambiguous - Key: CLI-252 URL: https://issues.apache.org/jira/browse/CLI-252 Project: Commons CLI Issue Type: Bug Components: Parser Affects Versions: 1.3 Environment: Windows 7, JDK 1.8.0v45 Reporter: Simon Harrer Assignee: Benedikt Ritter Fix For: 1.4 Options options = new Options(); options.addOption(Option.builder().longOpt(importToOpen).hasArg().argName(FILE).build()); options.addOption(Option.builder(i).longOpt(import).hasArg().argName(FILE).build()); Parsing --import=FILE is not possible since 1.3 as it throws a AmbiguousOptionException stating that it cannot decide whether import is import or importToOpen. In 1.2 this is not an issue. The root lies in the new DefaultParser which does a startsWith check internally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COMPRESS-317) ArrayIndexOutOfBoundsException in ZipArchiveEntry.getMergedFields()
[
https://issues.apache.org/jira/browse/COMPRESS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-317.
-
Resolution: Fixed
Fix Version/s: 1.10
Thanks!
fixed with svn revision 1684309, will port it to Ant.
ArrayIndexOutOfBoundsException in ZipArchiveEntry.getMergedFields()
---
Key: COMPRESS-317
URL: https://issues.apache.org/jira/browse/COMPRESS-317
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Reporter: Lucas Werkmeister
Priority: Minor
Labels: easyfix
Fix For: 1.10
{{src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveEntry.java}}
contains the following at line 380 in {{getMergedFields()}}:
{code:java}
zipExtraFields[zipExtraFields.length] = unparseableExtra;
{code}
This will cause an {{ArrayIndexOutOfBoundsException}} when reached.
Note that Apache Ant inherited this bug with commit
[{{2c04d7e}}|https://git-wip-us.apache.org/repos/asf?p=ant.git;a=commitdiff;h=2c04d7e833b4e5dab1a3c5ddfe14b572aea8c112],
which is where I found it; a fix should be ported there too. (The class is
called just {{ZipEntry}} there; full path:
{{src/main/org/apache/tools/zip/ZipEntry.java}})
The correct line is probably one of the following:
{code:java}
zipExtraFields[zipExtraFields.length - 1] = unparseableExtra;
zipExtraFields[extraFields.length] = unparseableExtra;
{code}
They should be equivalent because of the line immediately above line 380,
which creates {{zipExtraFields}} as copy of {{extraFields}} that is one
element longer. It might be worth noting that line 411 of {{ZipArchiveEntry}}
uses {{zipExtraFields.length - 1}}, while line 411 of Ant's {{ZipEntry}} uses
{{extraFields.length}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLI-252) LongOpt falsely detected as ambiguous
[
https://issues.apache.org/jira/browse/CLI-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved CLI-252.
-
Resolution: Fixed
Assignee: Benedikt Ritter
{code}
$ svn ci -m CLI-252: LongOpt falsely detected as ambiguous. This closes #2
from github. Thanks to Simon Harrer.
Sendingsrc/changes/changes.xml
Sendingsrc/main/java/org/apache/commons/cli/Options.java
Adding src/test/java/org/apache/commons/cli/bug/BugCLI252Test.java
Transmitting file data ...
Committed revision 1684315.
{code}
Thank you!
LongOpt falsely detected as ambiguous
-
Key: CLI-252
URL: https://issues.apache.org/jira/browse/CLI-252
Project: Commons CLI
Issue Type: Bug
Components: Parser
Affects Versions: 1.3
Environment: Windows 7, JDK 1.8.0v45
Reporter: Simon Harrer
Assignee: Benedikt Ritter
Fix For: 1.4
Options options = new Options();
options.addOption(Option.builder().longOpt(importToOpen).hasArg().argName(FILE).build());
options.addOption(Option.builder(i).longOpt(import).hasArg().argName(FILE).build());
Parsing --import=FILE is not possible since 1.3 as it throws a
AmbiguousOptionException stating that it cannot decide whether import is
import or importToOpen. In 1.2 this is not an issue.
The root lies in the new DefaultParser which does a startsWith check
internally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-480) IOUtils.closeQuietly can throw NullPointerException
[ https://issues.apache.org/jira/browse/IO-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577000#comment-14577000 ] Matt Kusnierz commented on IO-480: -- I have tried to raise this with Oracle through my support companies support contract; and they appear to be reluctant to fix this in the FilterInputStream. The closeQuietly method says that it should silently swallow ANY / all exceptions; so I still think that it makes sense to fix this within IOUtils. IOUtils.closeQuietly can throw NullPointerException --- Key: IO-480 URL: https://issues.apache.org/jira/browse/IO-480 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.4 Reporter: Matt Kusnierz Original Estimate: 10m Remaining Estimate: 10m The IOUtils#closeQuietly method in its javadoc suggests that ANY exceptions will be ignored. This is not the case, as the code only catches IOExceptions. As this example stack trace shows, it is possible for some InputStreams to throw NullPointerExceptions during close: java.lang.NullPointerException: null at java.io.FilterInputStream.close(FilterInputStream.java:155) ~[na:1.6.0_35] at sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90) ~[na:1.6.0_35] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:281) ~[commons-io-2.1.jar:2.1] at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:224) ~[commons-io-2.1.jar:2.1] Close quietly should do as advertised/suggested and catch all Exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1085) Add a circuit breaker implementation
[ https://issues.apache.org/jira/browse/LANG-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577023#comment-14577023 ] Bruno P. Kinoshita commented on LANG-1085: -- Hi Oliver! Thanks for the pull request. The timed circuit breaker has a few secondary classes, but I think that way it may be easier to understand the code, and avoid those redundant `if`'s. That way it might be easier to write tests too. I believe now we need to tidy up the code, update the docs (I didn't pay attention to comments, code, tabs, etc), and then either create a pull request to lang or attach a new patch. What way do you think it would be easier for us to work on it? Probably it would be better if the repo was yours, as the original patch was yours too :-) Thank you! Add a circuit breaker implementation Key: LANG-1085 URL: https://issues.apache.org/jira/browse/LANG-1085 Project: Commons Lang Issue Type: New Feature Components: lang.concurrent.* Reporter: Oliver Heger Attachments: CircuitBreaker.java, CircuitBreakerTest.java A _circuit breaker_ is a useful component to protect an application against unreliable services or load peaks. A simple implementation could be a good fit for the concurrent package. A proposed implementation is attached. Feedback is welcome! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
