[jira] [Commented] (CSV-196) Store the information of raw data read by lexer
[ https://issues.apache.org/jira/browse/CSV-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172439#comment-16172439 ] Matt Sun commented on CSV-196: -- https://github.com/apache/commons-csv/pull/22 > Store the information of raw data read by lexer > --- > > Key: CSV-196 > URL: https://issues.apache.org/jira/browse/CSV-196 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.4 >Reporter: Matt Sun > Labels: patch > Original Estimate: 48h > Remaining Estimate: 48h > > It will be good to have CSVParser class to store the info of whether a field > was enclosed by quotes in the original source file. > For example, for this data sample: > A, B, C > a1, "b1", c1 > CSVParser gives us record a1, b1, c1, which is helpful because it parsed > double quotes, but we also lost the information of original data at the same > time. We can't tell from the CSVRecord returned whether the original data is > enclosed by double quotes or not. > In our use case, we are integrating Apache Hadoop APIs with Commons CSV. CSV > is one kind of input of Hadoop Jobs, which should support splitting input > data. To accurately split a CSV file into pieces, we need to count the bytes > of data CSVParser actually read. CSVParser doesn't have accurate information > of whether a field was enclosed by quotes, neither does it store raw data of > the original source. Downstream users of commons CSVParser is not able to get > those info. > To suggest a fix: Extend the token/CSVRecord to have a boolean field > indicating whether the column was enclosed by quotes. While Lexer is doing > getNextToken, set the flag if a field is encapsulated and successfully parsed. > I find another issue reported with similar request, but it was marked as > resolved: [CSV91] > https://issues.apache.org/jira/browse/CSV-91?jql=project%20%3D%20CSV%20AND%20text%20~%20%22with%20quotes%22 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (VFS-644) AbstractFileSystem.streamClosed() always sets openStream count to zero
[
https://issues.apache.org/jira/browse/VFS-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-644.
Resolution: Fixed
> AbstractFileSystem.streamClosed() always sets openStream count to zero
> --
>
> Key: VFS-644
> URL: https://issues.apache.org/jira/browse/VFS-644
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Critical
> Fix For: 2.2
>
>
> The method {{AbstractFileSystem.streamClosed()}} always sets its
> {{openStreams}} count to zero.
> Unit test:
> {{org.apache.commons.vfs2.provider.zip.test.ZipFileObjectTestCase.testReadingOneAfterClosingAnotherStream()}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (VFS-644) AbstractFileSystem.streamClosed() always sets openStream count to zero
[
https://issues.apache.org/jira/browse/VFS-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened VFS-644:
--
> AbstractFileSystem.streamClosed() always sets openStream count to zero
> --
>
> Key: VFS-644
> URL: https://issues.apache.org/jira/browse/VFS-644
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Critical
> Fix For: 2.2
>
>
> The method {{AbstractFileSystem.streamClosed()}} always sets its
> {{openStreams}} count to zero.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (VFS-644) AbstractFileSystem.streamClosed() always sets openStream count to zero
[
https://issues.apache.org/jira/browse/VFS-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-644:
-
Description:
The method {{AbstractFileSystem.streamClosed()}} always sets its
{{openStreams}} count to zero.
Unit test:
{{org.apache.commons.vfs2.provider.zip.test.ZipFileObjectTestCase.testReadingOneAfterClosingAnotherStream()}}
was:The method {{AbstractFileSystem.streamClosed()}} always sets its
{{openStreams}} count to zero.
> AbstractFileSystem.streamClosed() always sets openStream count to zero
> --
>
> Key: VFS-644
> URL: https://issues.apache.org/jira/browse/VFS-644
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Critical
> Fix For: 2.2
>
>
> The method {{AbstractFileSystem.streamClosed()}} always sets its
> {{openStreams}} count to zero.
> Unit test:
> {{org.apache.commons.vfs2.provider.zip.test.ZipFileObjectTestCase.testReadingOneAfterClosingAnotherStream()}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (VFS-291) ZIP archives are not properly closed after unzipping and cannot be deleted until the JVM exists
[
https://issues.apache.org/jira/browse/VFS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172253#comment-16172253
]
Gary Gregory edited comment on VFS-291 at 9/19/17 8:01 PM:
---
Add refinement:
{noformat}
commit -m "[VFS-291] ZIP archives are not properly closed after unzipping and
cannot be deleted until the JVM exists. Do not close underlying ZipFile too
aggressively; only do so if all open streams are not in use!" -N
C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/zip/ZipFileObject.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/zip/ZipFileObject.java
Transmitting file data ...
Unknown action received: commit finalizing
Committed revision 1808941.
{noformat}
was (Author: garydgregory):
Add refinement:
{noformat}
commit -m "[VFS-291] ZIP archives are not properly closed after unzipping and
cannot be deleted until the JVM exists. Do not close underlying ZipFile too
aggressively; only do so if all open streams are not in use!" -N
C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/zip/test/ZipFileObjectTestCase.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/zip/test/ZipFileObjectTestCase.java
Transmitting file data ...
Unknown action received: commit finalizing
Committed revision 1808939.
{noformat}
> ZIP archives are not properly closed after unzipping and cannot be deleted
> until the JVM exists
> ---
>
> Key: VFS-291
> URL: https://issues.apache.org/jira/browse/VFS-291
> Project: Commons VFS
> Issue Type: Bug
> Environment: Windows
>Reporter: Roman
>Priority: Critical
> Labels: patch
> Fix For: 2.2
>
> Attachments: AbstractFileObject.java.2.patch,
> AbstractFileObject.java.patch, FileLockUnitTest.diff, vfs-291.diff,
> ZipCloseBug.zip, ZipFileObject.java, ZipFileObject.java.patch
>
>
> Open a zip file with the ZipFileObject
> get an inputstream on its content
> try to delete it...
> it fails.
> I have attached a possible solution to this bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (VFS-644) AbstractFileSystem.streamClosed() always sets openStream count to zero
[
https://issues.apache.org/jira/browse/VFS-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-644.
Resolution: Fixed
Fix Version/s: 2.2
> AbstractFileSystem.streamClosed() always sets openStream count to zero
> --
>
> Key: VFS-644
> URL: https://issues.apache.org/jira/browse/VFS-644
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Critical
> Fix For: 2.2
>
>
> The method {{AbstractFileSystem.streamClosed()}} always sets its
> {{openStreams}} count to zero.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VFS-291) ZIP archives are not properly closed after unzipping and cannot be deleted until the JVM exists
[ https://issues.apache.org/jira/browse/VFS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172255#comment-16172255 ] Bernd Eckenfels commented on VFS-291: - I am currently not in the Office. Your mail will not be forwarded. I will be Back on 2017-10-04. If you need technical support with SEEBURGER products, contact supp...@seeburger.de or http://servicedesk.seeburger.de General inquiries can be directed to our info team: i...@seeburger.de Greetings Bernd Eckenfels Chief Architect, SEEBURGER AG SEEBURGER AGVorstand/SEEBURGER Executive Board: Sitz der Gesellschaft/Registered Office:Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker Edisonstr. 1 D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board: Tel.: 07252 / 96 - 0Prof. Dr. Simone Zeuchner Fax: 07252 / 96 - Internet: http://www.seeburger.de Registergericht/Commercial Register: e-mail: i...@seeburger.de HRB 240708 Mannheim Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen. This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses. > ZIP archives are not properly closed after unzipping and cannot be deleted > until the JVM exists > --- > > Key: VFS-291 > URL: https://issues.apache.org/jira/browse/VFS-291 > Project: Commons VFS > Issue Type: Bug > Environment: Windows >Reporter: Roman >Priority: Critical > Labels: patch > Fix For: 2.2 > > Attachments: AbstractFileObject.java.2.patch, > AbstractFileObject.java.patch, FileLockUnitTest.diff, vfs-291.diff, > ZipCloseBug.zip, ZipFileObject.java, ZipFileObject.java.patch > > > Open a zip file with the ZipFileObject > get an inputstream on its content > try to delete it... > it fails. > I have attached a possible solution to this bug. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VFS-291) ZIP archives are not properly closed after unzipping and cannot be deleted until the JVM exists
[
https://issues.apache.org/jira/browse/VFS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172253#comment-16172253
]
Gary Gregory commented on VFS-291:
--
Add refinement:
{noformat}
commit -m "[VFS-291] ZIP archives are not properly closed after unzipping and
cannot be deleted until the JVM exists. Do not close underlying ZipFile too
aggressively; only do so if all open streams are not in use!" -N
C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/zip/test/ZipFileObjectTestCase.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/zip/test/ZipFileObjectTestCase.java
Transmitting file data ...
Unknown action received: commit finalizing
Committed revision 1808939.
{noformat}
> ZIP archives are not properly closed after unzipping and cannot be deleted
> until the JVM exists
> ---
>
> Key: VFS-291
> URL: https://issues.apache.org/jira/browse/VFS-291
> Project: Commons VFS
> Issue Type: Bug
> Environment: Windows
>Reporter: Roman
>Priority: Critical
> Labels: patch
> Fix For: 2.2
>
> Attachments: AbstractFileObject.java.2.patch,
> AbstractFileObject.java.patch, FileLockUnitTest.diff, vfs-291.diff,
> ZipCloseBug.zip, ZipFileObject.java, ZipFileObject.java.patch
>
>
> Open a zip file with the ZipFileObject
> get an inputstream on its content
> try to delete it...
> it fails.
> I have attached a possible solution to this bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (VFS-644) AbstractFileSystem.streamClosed() always sets openStream count to zero
[
https://issues.apache.org/jira/browse/VFS-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-644:
-
Description: The method {{AbstractFileSystem.streamClosed()}} always sets
its {{openStreams}} count to zero. (was: AbstractFileSystem.streamClosed()
always sets openStream count to zero.)
> AbstractFileSystem.streamClosed() always sets openStream count to zero
> --
>
> Key: VFS-644
> URL: https://issues.apache.org/jira/browse/VFS-644
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Critical
>
> The method {{AbstractFileSystem.streamClosed()}} always sets its
> {{openStreams}} count to zero.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (VFS-644) AbstractFileSystem.streamClosed() always sets openStream count to zero
Gary Gregory created VFS-644: Summary: AbstractFileSystem.streamClosed() always sets openStream count to zero Key: VFS-644 URL: https://issues.apache.org/jira/browse/VFS-644 Project: Commons VFS Issue Type: Bug Affects Versions: 2.1 Reporter: Gary Gregory Assignee: Gary Gregory Priority: Critical AbstractFileSystem.streamClosed() always sets openStream count to zero. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (COLLECTIONS-657) "union" method is resulting in data loss
[ https://issues.apache.org/jira/browse/COLLECTIONS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Savin closed COLLECTIONS-657. -- Resolution: Invalid > "union" method is resulting in data loss > > > Key: COLLECTIONS-657 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-657 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Igor Savin >Priority: Critical > > Create 2 instances of StringReader from strings (1 and 2), put them into a > list A. > Create empty list B. > Call CollectionUtils.union(A, B); > Expected result: [1, 2] > Actual result: [1, 1]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-657) "union" method is resulting in data loss
[ https://issues.apache.org/jira/browse/COLLECTIONS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172149#comment-16172149 ] Igor Savin commented on COLLECTIONS-657: After digging in further to create a reproduction test, figured out it's actually an issue with how equals is implemented in Drools library. > "union" method is resulting in data loss > > > Key: COLLECTIONS-657 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-657 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Igor Savin >Priority: Critical > > Create 2 instances of StringReader from strings (1 and 2), put them into a > list A. > Create empty list B. > Call CollectionUtils.union(A, B); > Expected result: [1, 2] > Actual result: [1, 1]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (COLLECTIONS-657) "union" method is resulting in data loss
Igor Savin created COLLECTIONS-657: -- Summary: "union" method is resulting in data loss Key: COLLECTIONS-657 URL: https://issues.apache.org/jira/browse/COLLECTIONS-657 Project: Commons Collections Issue Type: Bug Affects Versions: 4.1 Reporter: Igor Savin Priority: Critical Create 2 instances of StringReader from strings (1 and 2), put them into a list A. Create empty list B. Call CollectionUtils.union(A, B); Expected result: [1, 2] Actual result: [1, 1]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LANG-1353) NumberUtils.isNumber bug
[
https://issues.apache.org/jira/browse/LANG-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171791#comment-16171791
]
Sebb commented on LANG-1353:
The behaviour is clearly explained in the Javadoc:
http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/math/NumberUtils.html#isNumber-java.lang.String-
> NumberUtils.isNumber bug
>
>
> Key: LANG-1353
> URL: https://issues.apache.org/jira/browse/LANG-1353
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.6
>Reporter: yusw
>Priority: Critical
> Fix For: 3.7
>
>
> hi,I used to NumberUtils.isNumber()[version:3.6] find this error, this error
> is mainly caused by method isCreatable() in the 723 line of code。
> See below for details:
> String str = "0927";
> System.out.println(NumberUtils.isNumber(str));
> {color:red}//result:false{color}
> String str1 = "9027";
> System.out.println(NumberUtils.isNumber(str1));
> //result:true
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (LANG-1353) NumberUtils.isNumber bug
[
https://issues.apache.org/jira/browse/LANG-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed LANG-1353.
--
> NumberUtils.isNumber bug
>
>
> Key: LANG-1353
> URL: https://issues.apache.org/jira/browse/LANG-1353
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.6
>Reporter: yusw
>Priority: Critical
> Fix For: 3.7
>
>
> hi,I used to NumberUtils.isNumber()[version:3.6] find this error, this error
> is mainly caused by method isCreatable() in the 723 line of code。
> See below for details:
> String str = "0927";
> System.out.println(NumberUtils.isNumber(str));
> {color:red}//result:false{color}
> String str1 = "9027";
> System.out.println(NumberUtils.isNumber(str1));
> //result:true
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LANG-1353) NumberUtils.isNumber bug
[
https://issues.apache.org/jira/browse/LANG-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171670#comment-16171670
]
yusw commented on LANG-1353:
This is a trap, if you do not see the specific implementation of the method,
who do not know will be treated as octal. I do not think it's a good practice.
> NumberUtils.isNumber bug
>
>
> Key: LANG-1353
> URL: https://issues.apache.org/jira/browse/LANG-1353
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.6
>Reporter: yusw
>Priority: Critical
> Fix For: 3.7
>
>
> hi,I used to NumberUtils.isNumber()[version:3.6] find this error, this error
> is mainly caused by method isCreatable() in the 723 line of code。
> See below for details:
> String str = "0927";
> System.out.println(NumberUtils.isNumber(str));
> {color:red}//result:false{color}
> String str1 = "9027";
> System.out.println(NumberUtils.isNumber(str1));
> //result:true
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
