[jira] [Resolved] (VFS-189) Possible NPE in DefaultFileSystemManager
[ https://issues.apache.org/jira/browse/VFS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved VFS-189. Resolution: Fixed > Possible NPE in DefaultFileSystemManager > > > Key: VFS-189 > URL: https://issues.apache.org/jira/browse/VFS-189 > Project: Commons VFS > Issue Type: Bug > Environment: Fortify >Reporter: Henri Yandell >Assignee: Bruno P. Kinoshita > Labels: patch-available > Fix For: 2.0 > > > resolveName(FileName base, String, NameScope) does not protect from a null > base variable and will lead to an exception on realBase.getPath() later on in > the code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VFS-189) Possible NPE in DefaultFileSystemManager
[ https://issues.apache.org/jira/browse/VFS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119320#comment-16119320 ] Bruno P. Kinoshita commented on VFS-189: changes.xml updated in r1804482 > Possible NPE in DefaultFileSystemManager > > > Key: VFS-189 > URL: https://issues.apache.org/jira/browse/VFS-189 > Project: Commons VFS > Issue Type: Bug > Environment: Fortify >Reporter: Henri Yandell >Assignee: Bruno P. Kinoshita > Labels: patch-available > Fix For: 2.0 > > > resolveName(FileName base, String, NameScope) does not protect from a null > base variable and will lead to an exception on realBase.getPath() later on in > the code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VFS-189) Possible NPE in DefaultFileSystemManager
[ https://issues.apache.org/jira/browse/VFS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119317#comment-16119317 ] Bruno P. Kinoshita commented on VFS-189: Fixed in 1804480. Created GitHub patch (i.e. opened pull request URL, and then replaced the last part by .patch as https://github.com/apache/commons-vfs/pull/10.patch). Then applied locally with `patch -p1 -i ~/Downloads/10.patch`. Forgot to include in the commit message "This closes #10" so I am manually closing my pull request. > Possible NPE in DefaultFileSystemManager > > > Key: VFS-189 > URL: https://issues.apache.org/jira/browse/VFS-189 > Project: Commons VFS > Issue Type: Bug > Environment: Fortify >Reporter: Henri Yandell >Assignee: Bruno P. Kinoshita > Labels: patch-available > Fix For: 2.0 > > > resolveName(FileName base, String, NameScope) does not protect from a null > base variable and will lead to an exception on realBase.getPath() later on in > the code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (VFS-189) Possible NPE in DefaultFileSystemManager
[ https://issues.apache.org/jira/browse/VFS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated VFS-189: --- Assignee: Bruno P. Kinoshita > Possible NPE in DefaultFileSystemManager > > > Key: VFS-189 > URL: https://issues.apache.org/jira/browse/VFS-189 > Project: Commons VFS > Issue Type: Bug > Environment: Fortify >Reporter: Henri Yandell >Assignee: Bruno P. Kinoshita > Labels: patch-available > Fix For: 2.0 > > > resolveName(FileName base, String, NameScope) does not protect from a null > base variable and will lead to an exception on realBase.getPath() later on in > the code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IO-546) ClosedOutputStream#flush should throw
Tomas Celaya created IO-546:
---
Summary: ClosedOutputStream#flush should throw
Key: IO-546
URL: https://issues.apache.org/jira/browse/IO-546
Project: Commons IO
Issue Type: Improvement
Components: Streams/Writers
Reporter: Tomas Celaya
Priority: Minor
While debugging an issue involving usage of {{CloseShieldOutputStream}} I
discovered that {{ClosedOutputStream#flush}} is not overridden and will
silently succeed. Not sure how much of a breaking change this might be but I
think it makes more sense for {{ClosedOutputStream#flush}} to throw. This is
only really meaningful in contexts where multiple streams are being chained
together and some of the streams before {{CloseShieldOutputStream}} perform
buffering, but it would make behavior more consistent for these more complex
use-cases.
No patches are included because I'm interested in hearing what the opinion
would be on this issue. I can provide a patch if this seems like desired
behavior.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (LANG-1347) java.lang.NoClassDefFoundError: java.util.Objects on android < API 19
[
https://issues.apache.org/jira/browse/LANG-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter closed LANG-1347.
-
Resolution: Invalid
Commons Lang requires Java 7, which is not available on Android.
> java.lang.NoClassDefFoundError: java.util.Objects on android < API 19
> -
>
> Key: LANG-1347
> URL: https://issues.apache.org/jira/browse/LANG-1347
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.tuple.*
>Affects Versions: 3.6
> Environment: Android API level below 19
>Reporter: Volodymyr Lavruk
>
> The app is throwing a runtime error, as I understand, because the
> java.util.Objects is not available on Android below API 19.
> {code:java}
> AndroidRuntime E FATAL EXCEPTION: main
> E java.lang.NoClassDefFoundError: java.util.Objects
> E at
> org.apache.commons.lang3.tuple.Pair.equals(Pair.java:134)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LANG-1347) java.lang.NoClassDefFoundError: java.util.Objects on android < API 19
[
https://issues.apache.org/jira/browse/LANG-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volodymyr Lavruk updated LANG-1347:
---
Summary: java.lang.NoClassDefFoundError: java.util.Objects on android < API
19 (was: java.lang.NoClassDefFoundError: java.util.Objects found on android <
API 19)
> java.lang.NoClassDefFoundError: java.util.Objects on android < API 19
> -
>
> Key: LANG-1347
> URL: https://issues.apache.org/jira/browse/LANG-1347
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.tuple.*
>Affects Versions: 3.6
> Environment: Android API level below 19
>Reporter: Volodymyr Lavruk
>
> The app is throwing a runtime error, as I understand, because the
> java.util.Objects is not available on Android below API 19.
> {code:java}
> AndroidRuntime E FATAL EXCEPTION: main
> E java.lang.NoClassDefFoundError: java.util.Objects
> E at
> org.apache.commons.lang3.tuple.Pair.equals(Pair.java:134)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LANG-1347) java.lang.NoClassDefFoundError: java.util.Objects found on android < API 19
Volodymyr Lavruk created LANG-1347:
--
Summary: java.lang.NoClassDefFoundError: java.util.Objects found
on android < API 19
Key: LANG-1347
URL: https://issues.apache.org/jira/browse/LANG-1347
Project: Commons Lang
Issue Type: Bug
Components: lang.tuple.*
Affects Versions: 3.6
Environment: Android API level below 19
Reporter: Volodymyr Lavruk
The app is throwing a runtime error, as I understand, because the
java.util.Objects is not available on Android below API 19.
{code:java}
AndroidRuntime E FATAL EXCEPTION: main
E java.lang.NoClassDefFoundError: java.util.Objects
E at
org.apache.commons.lang3.tuple.Pair.equals(Pair.java:134)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
