[jira] Updated: (NET-257) FTP.getReplyStrings() returns array of null Strings
[
https://issues.apache.org/jira/browse/NET-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Wunderlich updated NET-257:
---
Description:
The 2.0 implementation of FTP.getReplyStrings() returns an array of null
Strings instead of the actual reply text. Here is the current method:
{{String[] lines;}}
{{lines = new String[_replyLines.size()];}}
{{_replyLines.addAll(Arrays.asList(lines));}}
{{return lines;}}
I believe the correction is to replace the above code with something like:
{{return _replyLines.toArray(new String[0]);}}
was:
The 2.0 implementation of FTP.getReplyStrings() returns an array of null
Strings instead of the actual reply text. Here is the current method:
{{String[] lines;}}
{{ lines = new String[_replyLines.size()];}}
{{_replyLines.addAll(Arrays.asList(lines));}}
{{return lines;}}
I believe the correction is to replace the above code with something like:
{{return _replyLines.toArray(new String[0]);}}
> FTP.getReplyStrings() returns array of null Strings
> ---
>
> Key: NET-257
> URL: https://issues.apache.org/jira/browse/NET-257
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Win XP, JRE 1.5
>Reporter: Rob Wunderlich
>
> The 2.0 implementation of FTP.getReplyStrings() returns an array of null
> Strings instead of the actual reply text. Here is the current method:
> {{String[] lines;}}
> {{lines = new String[_replyLines.size()];}}
> {{_replyLines.addAll(Arrays.asList(lines));}}
> {{return lines;}}
> I believe the correction is to replace the above code with something like:
> {{return _replyLines.toArray(new String[0]);}}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-257) FTP.getReplyStrings() returns array of null Strings
[
https://issues.apache.org/jira/browse/NET-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Wunderlich updated NET-257:
---
Description:
The 2.0 implementation of FTP.getReplyStrings() returns an array of null
Strings instead of the actual reply text. Here is the current method:
{{String[] lines;}}
{{ lines = new String[_replyLines.size()];}}
{{_replyLines.addAll(Arrays.asList(lines));}}
{{return lines;}}
I believe the correction is to replace the above code with something like:
{{return _replyLines.toArray(new String[0]);}}
was:
The 2.0 implementation of FTP.getReplyStrings() returns an array of null
Strings instead of the actual reply text. Here is the current method:
{{String[] lines;
lines = new String[_replyLines.size()];
_replyLines.addAll(Arrays.asList(lines));
return lines;}}
I believe the correction is to replace the above code with something like:
{{return _replyLines.toArray(new String[0]);}}
> FTP.getReplyStrings() returns array of null Strings
> ---
>
> Key: NET-257
> URL: https://issues.apache.org/jira/browse/NET-257
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Win XP, JRE 1.5
>Reporter: Rob Wunderlich
>
> The 2.0 implementation of FTP.getReplyStrings() returns an array of null
> Strings instead of the actual reply text. Here is the current method:
> {{String[] lines;}}
> {{ lines = new String[_replyLines.size()];}}
> {{_replyLines.addAll(Arrays.asList(lines));}}
> {{return lines;}}
> I believe the correction is to replace the above code with something like:
> {{return _replyLines.toArray(new String[0]);}}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-257) FTP.getReplyStrings() returns array of null Strings
FTP.getReplyStrings() returns array of null Strings
---
Key: NET-257
URL: https://issues.apache.org/jira/browse/NET-257
Project: Commons Net
Issue Type: Bug
Affects Versions: 2.0
Environment: Win XP, JRE 1.5
Reporter: Rob Wunderlich
The 2.0 implementation of FTP.getReplyStrings() returns an array of null
Strings instead of the actual reply text. Here is the current method:
{{String[] lines;
lines = new String[_replyLines.size()];
_replyLines.addAll(Arrays.asList(lines));
return lines;}}
I believe the correction is to replace the above code with something like:
{{return _replyLines.toArray(new String[0]);}}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674486#action_12674486 ] David Wang commented on MATH-246: - Just to throw in my two cents: The simplex algorithm forms the core of many scheduling and constraint algorithms. Unfortunately, I haven't found many Java implementations of the simplex method. This version has the understandable object-oriented structure that I've come to expect (and love) from commons-math. And I think it would be very useful to have it incorporated in the next release. Thanks Benjamin. > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CLI-174) RuntimeException in the wrapping code of HelpFormatter
[
https://issues.apache.org/jira/browse/CLI-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed CLI-174.
-
Resolution: Won't Fix
No longer true - RuntimeException was removed prior to 1.2 being released.
> RuntimeException in the wrapping code of HelpFormatter
> --
>
> Key: CLI-174
> URL: https://issues.apache.org/jira/browse/CLI-174
> Project: Commons CLI
> Issue Type: Bug
> Components: Help formatter
>Affects Versions: 1.1
>Reporter: Emmanuel Bourg
> Fix For: 1.3
>
>
> If there is not enough space to display a word on a single line,
> HelpFormatter goes into a infinite loops until the JVM crashes with an
> OutOfMemoryError.
> Test case:
> {code}
> Options options = new Options();
> options.addOption("h", "help", false, "This is a long description");
> HelpFormatter formatter = new HelpFormatter();
> formatter.setWidth(20);
> formatter.printHelp("app", options); // hang & crash
> {code}
> An helpful exception indicating the insufficient width would be more
> appropriate than an OutOfMemoryError.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLI-162) infinite loop in the wrapping code of HelpFormatter
[
https://issues.apache.org/jira/browse/CLI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674473#action_12674473
]
Henri Yandell commented on CLI-162:
---
svn ci -m "Applying my second attempt at a patch to CLI-162. This fixes Gary's
reported bug (one of which was an example of CLI-162, and one a bug in my first
attempt to patch). Open question is whether to output text that is too long, or
try and break it up to fit the screen width. "
Sendingsrc/java/org/apache/commons/cli/HelpFormatter.java
Sendingsrc/test/org/apache/commons/cli/bug/BugCLI162Test.java
Transmitting file data ..
Committed revision 745388.
> infinite loop in the wrapping code of HelpFormatter
> ---
>
> Key: CLI-162
> URL: https://issues.apache.org/jira/browse/CLI-162
> Project: Commons CLI
> Issue Type: Bug
> Components: Help formatter
>Affects Versions: 1.1
>Reporter: Emmanuel Bourg
> Fix For: 1.2
>
> Attachments: CLI-162-take2.patch
>
>
> If there is not enough space to display a word on a single line,
> HelpFormatter goes into a infinite loops until the JVM crashes with an
> OutOfMemoryError.
> Test case:
> {code}
> Options options = new Options();
> options.addOption("h", "help", false, "This is a long description");
> HelpFormatter formatter = new HelpFormatter();
> formatter.setWidth(20);
> formatter.printHelp("app", options); // hang & crash
> {code}
> An helpful exception indicating the insufficient width would be more
> appropriate than an OutOfMemoryError.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CLI-162) infinite loop in the wrapping code of HelpFormatter
[
https://issues.apache.org/jira/browse/CLI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated CLI-162:
--
Attachment: CLI-162-take2.patch
Attaching patch that rolls back the previous RuntimeException throwing. The if
statement in that patch was testing the wrong condition. This patch adds the
correct condition, and rather than throwing an exception the text is simply
outputted irregardless of the fact it is over the width. What should happen is
debatable here - due to a side-effect of CLI-151, we can't do anything
aggressive here because things were printing out happily if they were under
width + printTabStop. Our options are either to just print, or to forcibly
break the text.
The test code no longer expects to get a RuntimeException.
> infinite loop in the wrapping code of HelpFormatter
> ---
>
> Key: CLI-162
> URL: https://issues.apache.org/jira/browse/CLI-162
> Project: Commons CLI
> Issue Type: Bug
> Components: Help formatter
>Affects Versions: 1.1
>Reporter: Emmanuel Bourg
> Fix For: 1.2
>
> Attachments: CLI-162-take2.patch
>
>
> If there is not enough space to display a word on a single line,
> HelpFormatter goes into a infinite loops until the JVM crashes with an
> OutOfMemoryError.
> Test case:
> {code}
> Options options = new Options();
> options.addOption("h", "help", false, "This is a long description");
> HelpFormatter formatter = new HelpFormatter();
> formatter.setWidth(20);
> formatter.printHelp("app", options); // hang & crash
> {code}
> An helpful exception indicating the insufficient width would be more
> appropriate than an OutOfMemoryError.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CLI-162) infinite loop in the wrapping code of HelpFormatter
[
https://issues.apache.org/jira/browse/CLI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674469#action_12674469
]
Henri Yandell commented on CLI-162:
---
Two of the options appear to be problematic in CLI162.
The first is OPT_PASSWORD. In this the url is longer than the allowed width of
the screen, so some kind of failure needs to happen - or the url needs to be
mercilessly chopped. This is the one that goes into an infinite loop due to
CLI-151. My gut feeling from the code is that CLI-151 didn't introduce this
bug, but you had to be significantly longer to hit the bug before (ie:
printTabStop longer than the width).
The second is OPT_PARAM_TYPES_INT + OPT_PARAM_TYPES_NAME, it shows the the
patch for this ticket contained a bug when the lastPos happened to equal the
firstPos for completely normal reasons. I'd missed that pos was already set to
a real value when the loop was begun and not to 0. I'm not sure why both
options have to be set for this to happen.
> infinite loop in the wrapping code of HelpFormatter
> ---
>
> Key: CLI-162
> URL: https://issues.apache.org/jira/browse/CLI-162
> Project: Commons CLI
> Issue Type: Bug
> Components: Help formatter
>Affects Versions: 1.1
>Reporter: Emmanuel Bourg
> Fix For: 1.2
>
>
> If there is not enough space to display a word on a single line,
> HelpFormatter goes into a infinite loops until the JVM crashes with an
> OutOfMemoryError.
> Test case:
> {code}
> Options options = new Options();
> options.addOption("h", "help", false, "This is a long description");
> HelpFormatter formatter = new HelpFormatter();
> formatter.setWidth(20);
> formatter.printHelp("app", options); // hang & crash
> {code}
> An helpful exception indicating the insufficient width would be more
> appropriate than an OutOfMemoryError.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CLI-151) HelpFormatter wraps incorrectly on every line beyond the first
[
https://issues.apache.org/jira/browse/CLI-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed CLI-151.
-
Resolution: Fixed
I've sat and looked at the code fresh, and I agree with the 0 as a fix here.
Digging into the new failing test, I think the errors are in other code - so
closing this out again.
> HelpFormatter wraps incorrectly on every line beyond the first
> --
>
> Key: CLI-151
> URL: https://issues.apache.org/jira/browse/CLI-151
> Project: Commons CLI
> Issue Type: Bug
> Components: Help formatter
>Reporter: Dan Armbrust
> Fix For: 1.2
>
> Attachments: fix-wrapping.patch
>
>
> The method findWrapPos(...) in the HelpFormatter is a couple of bugs in the
> way that it deals with the "startPos" variable. This causes it to format
> every line beyond the first line by "startPos" to many characters, beyond the
> specified width.
> To see this, create an option with a long description, and then use the help
> formatter to print it. The first line will be the correct length. The 2nd,
> 3rd, etc lines will all be too long.
> I don't have a patch (sorry) - but here is a corrected version of the method.
> I fixed it in two places - both were using "width + startPos" when they
> should have been using width.
> {code}
> protected int findWrapPos(String text, int width, int startPos)
> {
> int pos = -1;
> // the line ends before the max wrap pos or a new line char found
> if (((pos = text.indexOf('\n', startPos)) != -1 && pos <= width)
> || ((pos = text.indexOf('\t', startPos)) != -1 && pos <= width))
> {
> return pos+1;
> }
> else if ((width) >= text.length())
> {
> return -1;
> }
> // look for the last whitespace character before startPos+width
> pos = width;
> char c;
> while ((pos >= startPos) && ((c = text.charAt(pos)) != ' ')
>&& (c != '\n') && (c != '\r'))
> {
> --pos;
> }
> // if we found it - just return
> if (pos > startPos)
> {
> return pos;
> }
>
> // must look for the first whitespace chearacter after startPos
> // + width
> pos = startPos + width;
> while ((pos <= text.length()) && ((c = text.charAt(pos)) != ' ')
>&& (c != '\n') && (c != '\r'))
> {
> ++pos;
> }
> return (pos == text.length())? (-1) : pos;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (CLI-151) HelpFormatter wraps incorrectly on every line beyond the first
[
https://issues.apache.org/jira/browse/CLI-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell reopened CLI-151:
---
This caused OutOfMemoryExceptions in some cases, so reopening.
> HelpFormatter wraps incorrectly on every line beyond the first
> --
>
> Key: CLI-151
> URL: https://issues.apache.org/jira/browse/CLI-151
> Project: Commons CLI
> Issue Type: Bug
> Components: Help formatter
>Reporter: Dan Armbrust
> Fix For: 1.2
>
> Attachments: fix-wrapping.patch
>
>
> The method findWrapPos(...) in the HelpFormatter is a couple of bugs in the
> way that it deals with the "startPos" variable. This causes it to format
> every line beyond the first line by "startPos" to many characters, beyond the
> specified width.
> To see this, create an option with a long description, and then use the help
> formatter to print it. The first line will be the correct length. The 2nd,
> 3rd, etc lines will all be too long.
> I don't have a patch (sorry) - but here is a corrected version of the method.
> I fixed it in two places - both were using "width + startPos" when they
> should have been using width.
> {code}
> protected int findWrapPos(String text, int width, int startPos)
> {
> int pos = -1;
> // the line ends before the max wrap pos or a new line char found
> if (((pos = text.indexOf('\n', startPos)) != -1 && pos <= width)
> || ((pos = text.indexOf('\t', startPos)) != -1 && pos <= width))
> {
> return pos+1;
> }
> else if ((width) >= text.length())
> {
> return -1;
> }
> // look for the last whitespace character before startPos+width
> pos = width;
> char c;
> while ((pos >= startPos) && ((c = text.charAt(pos)) != ' ')
>&& (c != '\n') && (c != '\r'))
> {
> --pos;
> }
> // if we found it - just return
> if (pos > startPos)
> {
> return pos;
> }
>
> // must look for the first whitespace chearacter after startPos
> // + width
> pos = startPos + width;
> while ((pos <= text.length()) && ((c = text.charAt(pos)) != ' ')
>&& (c != '\n') && (c != '\r'))
> {
> ++pos;
> }
> return (pos == text.length())? (-1) : pos;
> }
> {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-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-246: - Attachment: (was: newfiles.zip) > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-246: - Attachment: (was: newfiles.zip) > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-246: - Comment: was deleted > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-246: - Attachment: newfiles.zip David Wang from MIT discovered a model that caused the code to fail. This version fixes the bug responsible. > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-246) Simplex Method Implementation
[ https://issues.apache.org/jira/browse/MATH-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin McCann updated MATH-246: - Attachment: newfiles.zip David Wang from MIT discovered a model for which the code was failing. This version fixes the bug that was responsible. > Simplex Method Implementation > - > > Key: MATH-246 > URL: https://issues.apache.org/jira/browse/MATH-246 > Project: Commons Math > Issue Type: New Feature >Reporter: Benjamin McCann >Assignee: Luc Maisonobe > Fix For: 2.0 > > Attachments: newfiles.zip, newfiles.zip > > > I've created an implementation of the Simplex algorithm for optimizing > systems of constrained linear equations that I'd like to contribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXEC-33) PumpStreamHandler hangs if System.in is redirect to process input stream
[ https://issues.apache.org/jira/browse/EXEC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674398#action_12674398 ] Siegfried Goeschl commented on EXEC-33: --- Throwing an IllegalArgumentException when System.in is used to notify the user > PumpStreamHandler hangs if System.in is redirect to process input stream > > > Key: EXEC-33 > URL: https://issues.apache.org/jira/browse/EXEC-33 > Project: Commons Exec > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: Windows Vista >Reporter: Marco Ferrante >Assignee: Siegfried Goeschl >Priority: Minor > Attachments: PumpStreamHandler.patch > > > When process input is redirected using a PumpStreamHandler, e.g. > PumpStreamHandler streamHanlder = new PumpStreamHandler(out, err, > System.in); > exec.setStreamHandler(streamHanlder); > MockExecuteResultHandler handler = new MockExecuteResultHandler(); > exec.execute(cl, handler); > the process hangs and never exit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXEC-33) PumpStreamHandler hangs if System.in is redirect to process input stream
[ https://issues.apache.org/jira/browse/EXEC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674395#action_12674395 ] Siegfried Goeschl commented on EXEC-33: --- Fixing this correctly on all platforms does not look easy so I will look at it after the first release. > PumpStreamHandler hangs if System.in is redirect to process input stream > > > Key: EXEC-33 > URL: https://issues.apache.org/jira/browse/EXEC-33 > Project: Commons Exec > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: Windows Vista >Reporter: Marco Ferrante >Assignee: Siegfried Goeschl >Priority: Minor > Attachments: PumpStreamHandler.patch > > > When process input is redirected using a PumpStreamHandler, e.g. > PumpStreamHandler streamHanlder = new PumpStreamHandler(out, err, > System.in); > exec.setStreamHandler(streamHanlder); > MockExecuteResultHandler handler = new MockExecuteResultHandler(); > exec.execute(cl, handler); > the process hangs and never exit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXEC-35) inefficiencies identified by findbugs
[ https://issues.apache.org/jira/browse/EXEC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl resolved EXEC-35. --- Resolution: Fixed Fix Version/s: 1.0.0 Applied the patch but skipped it for parts of OpenVmsProcessingEnvironment and DefaultProcessingEnvironment to avoid undesired side-effects. > inefficiencies identified by findbugs > - > > Key: EXEC-35 > URL: https://issues.apache.org/jira/browse/EXEC-35 > Project: Commons Exec > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: linux >Reporter: Luc Maisonobe >Assignee: Siegfried Goeschl >Priority: Trivial > Fix For: 1.0.0 > > Attachments: findbugs-configuration.patch, findbugs-fixes.patch > > > I've run findbugs, it shows the following issues: > DefaultExecutor (line 203) > setExitValues(int[]) may expose internal representation by storing an > externally mutable object into DefaultExecutor.exitValues > DefaultProcessingEnvironment (lines 169 and 171) > Hard coded reference to an absolute pathname > DefaultProcessingEnvironment (line 108) and > OpenVmsProcessingEnvironment (line 89) > concatenates strings using + in a loop > OpenVmsProcessingEnvironment (line 114) and > MapUtils (line 72) > inefficient use of keySet iterator instead of entrySet iterator > The first issue should probably be fixed by cloning the array, but does > not appear to be an important problem. The second issue is a false > positive (if findbugs were activated by default in the pom, this could > be prevented by a configured exclusion file). The remaining issues are > harmless. > I will provide a patch to fix these issues shortly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXEC-35) inefficiencies identified by findbugs
[ https://issues.apache.org/jira/browse/EXEC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674391#action_12674391 ] Siegfried Goeschl commented on EXEC-35: --- The patch regarding DefaultProcessingEnvironment and OpenVmsProcessingEnvironment I will not apply - I'm not 100% sure that the patch will not introduce problems and using string concatentation is fine for me when being used for 30 environment variables. > inefficiencies identified by findbugs > - > > Key: EXEC-35 > URL: https://issues.apache.org/jira/browse/EXEC-35 > Project: Commons Exec > Issue Type: Bug >Affects Versions: 1.0.0 > Environment: linux >Reporter: Luc Maisonobe >Assignee: Siegfried Goeschl >Priority: Trivial > Attachments: findbugs-configuration.patch, findbugs-fixes.patch > > > I've run findbugs, it shows the following issues: > DefaultExecutor (line 203) > setExitValues(int[]) may expose internal representation by storing an > externally mutable object into DefaultExecutor.exitValues > DefaultProcessingEnvironment (lines 169 and 171) > Hard coded reference to an absolute pathname > DefaultProcessingEnvironment (line 108) and > OpenVmsProcessingEnvironment (line 89) > concatenates strings using + in a loop > OpenVmsProcessingEnvironment (line 114) and > MapUtils (line 72) > inefficient use of keySet iterator instead of entrySet iterator > The first issue should probably be fixed by cloning the array, but does > not appear to be an important problem. The second issue is a false > positive (if findbugs were activated by default in the pom, this could > be prevented by a configured exclusion file). The remaining issues are > harmless. > I will provide a patch to fix these issues shortly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-365) Bean handling not allowing an XPathExpressionEngine
[
https://issues.apache.org/jira/browse/CONFIGURATION-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674345#action_12674345
]
Oliver Heger commented on CONFIGURATION-365:
We have unit tests that do similar things. For instance, in
{{TestDefaultConfigurationBuilder}} we have a test that reads a complex
configuration file containing the following declaration:
{code:xml}
table
list
...
{code}
Can you check the code in a normal environment to make sure that the problem is
not related to OSGi and class loading issues?
> Bean handling not allowing an XPathExpressionEngine
> ---
>
> Key: CONFIGURATION-365
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-365
> Project: Commons Configuration
> Issue Type: Bug
> Environment: OSGi / Felix
>Reporter: Rob Walker
>
> Trying to set an XPathExpressionEngine in the config file:
> ===
>config-name="config.product.xml"
> fileName="${sys:bundle.root}/etc/${sys:launch.target}.properties.xml"
> >
> config-class="org.apache.commons.configuration.tree.xpath.XPathExpressionEngine"/>
>
> ===
> And it throws an exception:
>
> Caused by: org.apache.commons.configuration.ConfigurationException:
> org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.IllegalArgumentException: Cannot invoke
> org.apache.commons.configuration.HierarchicalConfiguration.setExpressionEngine
> on
> bean class 'class org.apache.commons.configuration.XMLConfiguration' -
> argument type mismatch - had objects of type "org.apache.comm
> ons.configuration.tree.xpath.XPathExpressionEngine" but expected signature
> "org.apache.commons.configuration.tree.ExpressionEngine"
> at
> org.apache.commons.configuration.DefaultConfigurationBuilder.createConfigurationAt(DefaultConfigurationBuilder.java:752)
> at
> org.apache.commons.configuration.DefaultConfigurationBuilder.initCombinedConfiguration(DefaultConfigurationBuilder.java:6
> 28)
> at
> org.apache.commons.configuration.DefaultConfigurationBuilder.getConfiguration(DefaultConfigurationBuilder.java:560)
> at
> com.ascert.vt.modules.propsmgr.PropsMgrMainOSGI.(PropsMgrMainOSGI.java:102)
> ... 13 more
> Caused by: org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.IllegalArgumentException: Cannot invoke org.apa
> che.commons.configuration.HierarchicalConfiguration.setExpressionEngine on
> bean class 'class org.apache.commons.configuration.XMLCon
> figuration' - argument type mismatch - had objects of type
> "org.apache.commons.configuration.tree.xpath.XPathExpressionEngine" but e
> xpected signature "org.apache.commons.configuration.tree.ExpressionEngine"
> at
> org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:252)
> at
> org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:269)
> at
> org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:283)
> at
> org.apache.commons.configuration.DefaultConfigurationBuilder.createConfigurationAt(DefaultConfigurationBuilder.java:747)
> ... 16 more
> Caused by: java.lang.IllegalArgumentException: Cannot invoke
> org.apache.commons.configuration.HierarchicalConfiguration.setExpressio
> nEngine on bean class 'class
> org.apache.commons.configuration.XMLConfiguration' - argument type mismatch -
> had objects of type "org.
> apache.commons.configuration.tree.xpath.XPathExpressionEngine" but expected
> signature "org.apache.commons.configuration.tree.Express
> ionEngine"
> ===
> Since XPathExpressionEngine implements ExpressionEngine, this looks like a
> reflection bug to me i.e. not finding a method with a signature for
> implemented interfaces as opposed to just subclasses.
> Not sure if this is OSGi / Felix classloading related, but don't think so
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-196) Occasional FileSystemObserver test failures
[ https://issues.apache.org/jira/browse/IO-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674251#action_12674251 ] Jukka Zitting commented on IO-196: -- Also the following test fails occasionally: FilesystemObserverTestCase testFileDelete : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: E[0 0 0 0 0 1]: No. of directories changed expected:<1> but was:<0> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.commons.io.monitor.FilesystemObserverTestCase.checkCollectionSizes(FilesystemObserverTestCase.java:424) at org.apache.commons.io.monitor.FilesystemObserverTestCase.testFileDelete(FilesystemObserverTestCase.java:324) > Occasional FileSystemObserver test failures > --- > > Key: IO-196 > URL: https://issues.apache.org/jira/browse/IO-196 > Project: Commons IO > Issue Type: Bug >Reporter: Jukka Zitting >Priority: Minor > > The FilesystemObserverTestCase method testFileCreate() fails occasionally in > the Continuum build at > http://vmbuild.apache.org/continuum/projectView.action?projectId=155. The > failure, when it happens, is: > FilesystemObserverTestCase > testFileCreate : > junit.framework.AssertionFailedError > junit.framework.AssertionFailedError: E[0 0 0 1 0 0]: No. of directories > changed expected:<1> but was:<0> >at junit.framework.Assert.fail(Assert.java:47) >at junit.framework.Assert.failNotEquals(Assert.java:282) >at junit.framework.Assert.assertEquals(Assert.java:64) >at junit.framework.Assert.assertEquals(Assert.java:201) >at > org.apache.commons.io.monitor.FilesystemObserverTestCase.checkCollectionSizes(FilesystemObserverTestCase.java:424) >at > org.apache.commons.io.monitor.FilesystemObserverTestCase.testFileCreate(FilesystemObserverTestCase.java:203) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-365) Bean handling not allowing an XPathExpressionEngine
Bean handling not allowing an XPathExpressionEngine --- Key: CONFIGURATION-365 URL: https://issues.apache.org/jira/browse/CONFIGURATION-365 Project: Commons Configuration Issue Type: Bug Environment: OSGi / Felix Reporter: Rob Walker Trying to set an XPathExpressionEngine in the config file: === === And it throws an exception: Caused by: org.apache.commons.configuration.ConfigurationException: org.apache.commons.configuration.ConfigurationRuntimeException: java.lang.IllegalArgumentException: Cannot invoke org.apache.commons.configuration.HierarchicalConfiguration.setExpressionEngine on bean class 'class org.apache.commons.configuration.XMLConfiguration' - argument type mismatch - had objects of type "org.apache.comm ons.configuration.tree.xpath.XPathExpressionEngine" but expected signature "org.apache.commons.configuration.tree.ExpressionEngine" at org.apache.commons.configuration.DefaultConfigurationBuilder.createConfigurationAt(DefaultConfigurationBuilder.java:752) at org.apache.commons.configuration.DefaultConfigurationBuilder.initCombinedConfiguration(DefaultConfigurationBuilder.java:6 28) at org.apache.commons.configuration.DefaultConfigurationBuilder.getConfiguration(DefaultConfigurationBuilder.java:560) at com.ascert.vt.modules.propsmgr.PropsMgrMainOSGI.(PropsMgrMainOSGI.java:102) ... 13 more Caused by: org.apache.commons.configuration.ConfigurationRuntimeException: java.lang.IllegalArgumentException: Cannot invoke org.apa che.commons.configuration.HierarchicalConfiguration.setExpressionEngine on bean class 'class org.apache.commons.configuration.XMLCon figuration' - argument type mismatch - had objects of type "org.apache.commons.configuration.tree.xpath.XPathExpressionEngine" but e xpected signature "org.apache.commons.configuration.tree.ExpressionEngine" at org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:252) at org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:269) at org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:283) at org.apache.commons.configuration.DefaultConfigurationBuilder.createConfigurationAt(DefaultConfigurationBuilder.java:747) ... 16 more Caused by: java.lang.IllegalArgumentException: Cannot invoke org.apache.commons.configuration.HierarchicalConfiguration.setExpressio nEngine on bean class 'class org.apache.commons.configuration.XMLConfiguration' - argument type mismatch - had objects of type "org. apache.commons.configuration.tree.xpath.XPathExpressionEngine" but expected signature "org.apache.commons.configuration.tree.Express ionEngine" === Since XPathExpressionEngine implements ExpressionEngine, this looks like a reflection bug to me i.e. not finding a method with a signature for implemented interfaces as opposed to just subclasses. Not sure if this is OSGi / Felix classloading related, but don't think so -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
