[jira] [Commented] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193855#comment-17193855
]
Gary Gregory commented on IO-686:
-
In general, we make the Javadoc match the code, as the code evolves.
In this case, that method's Javadoc got out of sync with code. The
method is now used from other call sites where the expected result is
an empty byte array.
Gary
> IOUtils.toByteArray(InputStream) Javadoc does not match code
>
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DBCP-546) Avoid NPE when calling DriverAdapterCPDS.toString()
Gary Gregory created DBCP-546: - Summary: Avoid NPE when calling DriverAdapterCPDS.toString() Key: DBCP-546 URL: https://issues.apache.org/jira/browse/DBCP-546 Project: Commons DBCP Issue Type: New Feature Reporter: Gary Gregory Fix For: 2.6.1 Avoid NPE when calling DriverAdapterCPDS.toString(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (DBCP-546) Avoid NPE when calling DriverAdapterCPDS.toString()
[ https://issues.apache.org/jira/browse/DBCP-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed DBCP-546. - Resolution: Fixed In git master. > Avoid NPE when calling DriverAdapterCPDS.toString() > --- > > Key: DBCP-546 > URL: https://issues.apache.org/jira/browse/DBCP-546 > Project: Commons DBCP > Issue Type: New Feature >Reporter: Gary Gregory >Priority: Major > Fix For: 2.6.1 > > > Avoid NPE when calling DriverAdapterCPDS.toString(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1458) Add EMPTY_ARRAY constants to classes in org.apache.commons.lang3.tuple
Gary Gregory created LANG-1458:
--
Summary: Add EMPTY_ARRAY constants to classes in
org.apache.commons.lang3.tuple
Key: LANG-1458
URL: https://issues.apache.org/jira/browse/LANG-1458
Project: Commons Lang
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Add {{EMPTY_ARRAY}} constants to classes in {{org.apache.commons.lang3.tuple}}:
org.apache.commons.lang3.tuple.ImmutablePair.EMPTY_ARRAY
org.apache.commons.lang3.tuple.ImmutableTriple.EMPTY_ARRAY
org.apache.commons.lang3.tuple.MutablePair.EMPTY_ARRAY
org.apache.commons.lang3.tuple.MutableTriple.EMPTY_ARRAY
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1458) Add EMPTY_ARRAY constants to classes in org.apache.commons.lang3.tuple
[
https://issues.apache.org/jira/browse/LANG-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1458:
---
Description:
Add {{EMPTY_ARRAY}} constants to classes in {{org.apache.commons.lang3.tuple}}:
org.apache.commons.lang3.tuple.ImmutablePair.EMPTY_ARRAY
org.apache.commons.lang3.tuple.ImmutableTriple.EMPTY_ARRAY
org.apache.commons.lang3.tuple.MutablePair.EMPTY_ARRAY
org.apache.commons.lang3.tuple.MutableTriple.EMPTY_ARRAY
Add methods {{emptyArray()}} on each class above that use generics to avoid
generics compiler warnings.
was:
Add {{EMPTY_ARRAY}} constants to classes in {{org.apache.commons.lang3.tuple}}:
org.apache.commons.lang3.tuple.ImmutablePair.EMPTY_ARRAY
org.apache.commons.lang3.tuple.ImmutableTriple.EMPTY_ARRAY
org.apache.commons.lang3.tuple.MutablePair.EMPTY_ARRAY
org.apache.commons.lang3.tuple.MutableTriple.EMPTY_ARRAY
> Add EMPTY_ARRAY constants to classes in org.apache.commons.lang3.tuple
> --
>
> Key: LANG-1458
> URL: https://issues.apache.org/jira/browse/LANG-1458
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add {{EMPTY_ARRAY}} constants to classes in
> {{org.apache.commons.lang3.tuple}}:
> org.apache.commons.lang3.tuple.ImmutablePair.EMPTY_ARRAY
> org.apache.commons.lang3.tuple.ImmutableTriple.EMPTY_ARRAY
> org.apache.commons.lang3.tuple.MutablePair.EMPTY_ARRAY
> org.apache.commons.lang3.tuple.MutableTriple.EMPTY_ARRAY
> Add methods {{emptyArray()}} on each class above that use generics to avoid
> generics compiler warnings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (LANG-1458) Add EMPTY_ARRAY constants to classes in org.apache.commons.lang3.tuple
[
https://issues.apache.org/jira/browse/LANG-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LANG-1458.
--
Resolution: Fixed
Fix Version/s: 3.10
In git master.
> Add EMPTY_ARRAY constants to classes in org.apache.commons.lang3.tuple
> --
>
> Key: LANG-1458
> URL: https://issues.apache.org/jira/browse/LANG-1458
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add {{EMPTY_ARRAY}} constants to classes in
> {{org.apache.commons.lang3.tuple}}:
> org.apache.commons.lang3.tuple.ImmutablePair.EMPTY_ARRAY
> org.apache.commons.lang3.tuple.ImmutableTriple.EMPTY_ARRAY
> org.apache.commons.lang3.tuple.MutablePair.EMPTY_ARRAY
> org.apache.commons.lang3.tuple.MutableTriple.EMPTY_ARRAY
> Add methods {{emptyArray()}} on each class above that use generics to avoid
> generics compiler warnings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-714) FileObject.deleteAll doesn't work on a NullFilesCache
[ https://issues.apache.org/jira/browse/VFS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837268#comment-16837268 ] Gary Gregory commented on VFS-714: -- [~boris-petrov], Thank you for your report. Feel free to submit a PR on GitHub :-) Gary > FileObject.deleteAll doesn't work on a NullFilesCache > - > > Key: VFS-714 > URL: https://issues.apache.org/jira/browse/VFS-714 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Boris Petrov >Priority: Major > > If one tries to call `folder.deleteAll` on a folder which has children and a > `NullFilesCache` is setup on the file system manager, this call fails to > delete the folder. > This is due to the `file.getChildren().length != 0` call returning `true` for > the folder - the children are cached for it and the cache is not cleared even > though a child is deleted because a `NullFilesCache` is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-715) Add org.apache.commons.vfs2.FileContent.getByteArray()
Gary Gregory created VFS-715:
Summary: Add org.apache.commons.vfs2.FileContent.getByteArray()
Key: VFS-715
URL: https://issues.apache.org/jira/browse/VFS-715
Project: Commons VFS
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Add {{org.apache.commons.vfs2.FileContent.getByteArray()}}.
This is a refactoring of
{{org.apache.commons.vfs2.FileUtil.getContent(FileObject)}} to a new default
method {{FileContent.getByteArray()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (VFS-715) Add org.apache.commons.vfs2.FileContent.getByteArray()
[
https://issues.apache.org/jira/browse/VFS-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-715.
Resolution: Fixed
Fix Version/s: 2.4
In git master.
> Add org.apache.commons.vfs2.FileContent.getByteArray()
> --
>
> Key: VFS-715
> URL: https://issues.apache.org/jira/browse/VFS-715
> Project: Commons VFS
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Add {{org.apache.commons.vfs2.FileContent.getByteArray()}}.
> This is a refactoring of
> {{org.apache.commons.vfs2.FileUtil.getContent(FileObject)}} to a new default
> method {{FileContent.getByteArray()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DBCP-342) Not cleaned up commons pool's evictor task when SQLException occurs after the GenericObjectPool is initialized in createDataSource.
[
https://issues.apache.org/jira/browse/DBCP-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838503#comment-16838503
]
Gary Gregory commented on DBCP-342:
---
You should really consider updating to the current version 2.6.0, which will
means changing package names from {{org.apache.commons.dbcp}} to
{{org.apache.commons.dbcp2}}
> Not cleaned up commons pool's evictor task when SQLException occurs after the
> GenericObjectPool is initialized in createDataSource.
> ---
>
> Key: DBCP-342
> URL: https://issues.apache.org/jira/browse/DBCP-342
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 1.3, 1.4
> Environment: * commons-pool : 1.4
> * commons-dbcp : 1.4, 1.3 both
> * dbms : MSSQL 2007
>Reporter: byungchol.kim
>Priority: Major
> Fix For: 1.3.1, 1.4.1
>
> Attachments: dbcp_orphan_evictor_fix_patch.txt
>
>
> JIRA DBCP-93 bts is not fixed correctly
> (JIRA DBCP-93 : If SQLException occurs after the GenericObjectPool is
> initialized in createDataSource, the evictor task is not cleaned up)
> Only one evictor timer thread leaves but evictor timer task queued as many as
> createDataSource() method called.
> queued evictor will keep tries to make connection to meet min idle connection.
> if suddenly dbms become stable and can accept connection again,
> then every queued evictor will try to make connection simultaneously.
> In my case there were more then 10 user requests while I set wrong
> password to database,
> when I change my password to correct in database
> more then 10 evictor tries to make connection
> and finally mssql makes connections as many as integer limit and dbms dies.
> here is my test.
> {code:title=TestBasicDataSource.java}
> public void testCreateDataSourceCleanupEvictor() throws Exception {
> ds.close();
> ds = null;
> ds = createDataSource();
>
> ds.setDriverClassName("org.apache.commons.dbcp.TesterConnRequestCountDriver");
> ds.setUrl("jdbc:apache:commons:testerConnRequestCountDriver");
> ds.setValidationQuery("SELECT DUMMY FROM DUAL");
> ds.setUsername("username");
>
> // Make password incorrect, so createDataSource will throw
> ds.setPassword("wrong");
> // Set timeBetweenEvictionRuns > 0, so evictor will be created
> ds.setTimeBetweenEvictionRunsMillis(100);
> // Set min idle > 0, so evictor will try to make connection as many as
> idle count
> ds.setMinIdle(2);
>
> Class.forName("org.apache.commons.dbcp.TesterConnRequestCountDriver");
> TesterConnRequestCountDriver testerDriver =
> (TesterConnRequestCountDriver)
> DriverManager.getDriver("jdbc:apache:commons:testerConnRequestCountDriver");
> testerDriver.initConnRequestCount();
>
> // user request 10 times
> for (int i=0; i<10; i++) {
> try {
> @SuppressWarnings("unused")
> DataSource ds2 = ds.createDataSource();
> } catch (SQLException e) {
> // Ignore
> }
> }
> // sleep 1000ms. evictory will invoked 10 times.
> Thread.sleep(1000);
>
> // if orphan evictor is alive, connection request count will be 100
> which is denoted from (ds.createDataSource() count * evictor invoke count)
> // if DBMS connection is back to stable in 10 minutes then this test
> case will make 12 connections simultaneously
> // 12 connections = ds.createDataSource() count (10) *
> evictor invoke count (6000) * min idle (2)
> // but if evictor is cleaned up, connection request count will be only
> 10 (ds.createDataSource() count )
> assertEquals(10, testerDriver.getConnectionRequestCount());
>
> // fail to create datasource then clean up orphan connection pool and
> evictor in connnection pool
> assertNull(ds.connectionPool);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1459) BigDecimalStatistics
[ https://issues.apache.org/jira/browse/LANG-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839759#comment-16839759 ] Gary Gregory commented on LANG-1459: Sounds like something that belongs to the Commons Math or related projects, not Commons Lang. > BigDecimalStatistics > > > Key: LANG-1459 > URL: https://issues.apache.org/jira/browse/LANG-1459 > Project: Commons Lang > Issue Type: New Feature >Reporter: Aleksander Ściborek >Priority: Major > > The idea is to create a util class for reducing stream of BigDecimal objects > and then getting an object which contains statistics such as > 1)Min and max value > 2)Average > 3)Total sum -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMAGING-225) Make ImageParser.getAcceptedExtensions public
[ https://issues.apache.org/jira/browse/IMAGING-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840628#comment-16840628 ] Gary Gregory commented on IMAGING-225: -- Hello [~pauldaustin], If we make this method public, we need, IMO better Javadocs: Is the array a copy or the real underlying array? IOW, if you modify an element of the array should it affect the image parser? Feel free to propose a PR on GitHub :) This is the same kind of issue we see a lot of warnings about in the site reports WRT to byte arrays and other arrays. The minimum would be to document the current implementation I would imagine. Do you have any thoughts here [~pauldaustin]? Any one else? Gary > Make ImageParser.getAcceptedExtensions public > - > > Key: IMAGING-225 > URL: https://issues.apache.org/jira/browse/IMAGING-225 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Paul Austin >Priority: Trivial > > Would it be possible to make ImageParser.getAcceptedExtensions public? > This way filters can be created in a file selection dialog in a UI. Or for > other purposes linking the ImageParser for the file extensions associated > with that ImageParser. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IO-578) ReversedLinesFileReader cannot be used with non-default file systems on Java 7+
[
https://issues.apache.org/jira/browse/IO-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed IO-578.
---
Resolution: Fixed
In git master.
> ReversedLinesFileReader cannot be used with non-default file systems on Java
> 7+
> ---
>
> Key: IO-578
> URL: https://issues.apache.org/jira/browse/IO-578
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Mark Chesney
>Priority: Major
> Fix For: 2.7
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> It's not currently possible to use {{ReversedLinesFileReader}} with a
> non-default file system like Jimfs. The file would first have to be copied to
> the default file system. Non-default file systems can be supported by
> preferring {{java.nio.file.Path}} and
> {{java.nio.channels.SeekableByteChannel}} to {{java.io.File}} and
> {{java.io.RandomAccessFile}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VFS-716) Fix AbstractFileName.getURI returning unencoded #-sign #64
Gary Gregory created VFS-716: Summary: Fix AbstractFileName.getURI returning unencoded #-sign #64 Key: VFS-716 URL: https://issues.apache.org/jira/browse/VFS-716 Project: Commons VFS Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Fix AbstractFileName.getURI returning unencoded #-sign #64 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (VFS-716) Fix AbstractFileName.getURI returning unencoded #-sign #64
[ https://issues.apache.org/jira/browse/VFS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-716. Resolution: Fixed Fix Version/s: 2.4 In git master. > Fix AbstractFileName.getURI returning unencoded #-sign #64 > -- > > Key: VFS-716 > URL: https://issues.apache.org/jira/browse/VFS-716 > Project: Commons VFS > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.4 > > > Fix AbstractFileName.getURI returning unencoded #-sign #64 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IO-607) Update from Java 7 to Java 8
Gary Gregory created IO-607: --- Summary: Update from Java 7 to Java 8 Key: IO-607 URL: https://issues.apache.org/jira/browse/IO-607 Project: Commons IO Issue Type: New Feature Reporter: Gary Gregory Update from Java 7 to Java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IO-607) Update from Java 7 to Java 8
[ https://issues.apache.org/jira/browse/IO-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842219#comment-16842219 ] Gary Gregory commented on IO-607: - - One justification is that Java 7 has been EOL for a long time. - Another is that it makes the component more attractive to contributors: You do not have to install and EOL'ed version of Java, you might want to use Java 8 APIs in contributions. > Update from Java 7 to Java 8 > > > Key: IO-607 > URL: https://issues.apache.org/jira/browse/IO-607 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary Gregory >Priority: Major > > Update from Java 7 to Java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IO-607) Update from Java 7 to Java 8
[ https://issues.apache.org/jira/browse/IO-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842219#comment-16842219 ] Gary Gregory edited comment on IO-607 at 5/17/19 2:30 PM: -- - One justification is that Java 7 has been EOL for a long time. - Another is that it makes the component more attractive to contributors: You do not have to install an EOL'ed version of Java, and you might want to use Java 8 APIs in contributions. was (Author: garydgregory): - One justification is that Java 7 has been EOL for a long time. - Another is that it makes the component more attractive to contributors: You do not have to install and EOL'ed version of Java, you might want to use Java 8 APIs in contributions. > Update from Java 7 to Java 8 > > > Key: IO-607 > URL: https://issues.apache.org/jira/browse/IO-607 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary Gregory >Priority: Major > > Update from Java 7 to Java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[
https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843448#comment-16843448
]
Gary Gregory commented on CSV-239:
--
Please see git master or a SNAPSHOT for the new method
{{org.apache.commons.csv.CSVRecord.getHeaderNames()}}.
> Cannot get headers in column order from CSVRecord
> -
>
> Key: CSV-239
> URL: https://issues.apache.org/jira/browse/CSV-239
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.6
>Reporter: Dave Moten
>Priority: Minor
>
> I have a use case where I read many lines from an arbitrary csv file with a
> given CSVFormat as List, transform that list and then want to
> write the transformed list to another file.
> When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the
> headers from the first line are available in the CSVRecord object via the
> CSVRecord.toMap object but their column positions are not (the iteration of
> the returned map does not reflect column order). Consequently I cannot write
> a header line in the correct order to the output csv file (which I do when
> the first CSVRecord is to be written).
> Another option would be to be to ensure that the CSVPrinter object writes the
> header on the first call to CSVPrinter.printRecord but we should also be able
> to cover the user case where we are writing to a non-csv format and we still
> want to write the headers in the correct order.
> My preference at minimum is that the headers with column order are available
> from CSVRecord (after all the data to supply this is already present in
> CVSRecord). The addition of a method `getHeaders` returning a `List`
> would do the job. I'm happy to submit a PR if desired.
> I've marked this as of minor importance but I think it's a pretty important
> flaw in the library at the moment that prevents event the simplest of
> round-trip (read then write) scenarios when the headers are read from the
> file rather than known up-front.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CSV-239) Cannot get headers in column order from CSVRecord
[
https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843448#comment-16843448
]
Gary Gregory edited comment on CSV-239 at 5/19/19 2:28 PM:
---
Please see git master or a SNAPSHOT
(https://repository.apache.org/content/repositories/snapshots/) for the new
method {{org.apache.commons.csv.CSVRecord.getHeaderNames()}}.
was (Author: garydgregory):
Please see git master or a SNAPSHOT for the new method
{{org.apache.commons.csv.CSVRecord.getHeaderNames()}}.
> Cannot get headers in column order from CSVRecord
> -
>
> Key: CSV-239
> URL: https://issues.apache.org/jira/browse/CSV-239
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.6
>Reporter: Dave Moten
>Priority: Minor
>
> I have a use case where I read many lines from an arbitrary csv file with a
> given CSVFormat as List, transform that list and then want to
> write the transformed list to another file.
> When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the
> headers from the first line are available in the CSVRecord object via the
> CSVRecord.toMap object but their column positions are not (the iteration of
> the returned map does not reflect column order). Consequently I cannot write
> a header line in the correct order to the output csv file (which I do when
> the first CSVRecord is to be written).
> Another option would be to be to ensure that the CSVPrinter object writes the
> header on the first call to CSVPrinter.printRecord but we should also be able
> to cover the user case where we are writing to a non-csv format and we still
> want to write the headers in the correct order.
> My preference at minimum is that the headers with column order are available
> from CSVRecord (after all the data to supply this is already present in
> CVSRecord). The addition of a method `getHeaders` returning a `List`
> would do the job. I'm happy to submit a PR if desired.
> I've marked this as of minor importance but I think it's a pretty important
> flaw in the library at the moment that prevents event the simplest of
> round-trip (read then write) scenarios when the headers are read from the
> file rather than known up-front.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843538#comment-16843538 ] Gary Gregory commented on CSV-239: -- Alternatively, we could add getHeaderNames() to CSVParser and drop it completely from CSVRecord. That would make the information available, just not on each record. Thoughts? There is no hard-core process. For contributors, it is nicer for us to get contributions through GitHub. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843538#comment-16843538 ] Gary Gregory edited comment on CSV-239 at 5/19/19 8:44 PM: --- Alternatively, we could add getHeaderNames() to CSVParser and drop it completely from CSVRecord. That would make the information available, just not on each record. Thoughts? There is no hard-core process. For contributors, it is nicer for us to get contributions through GitHub. We could also replace both headerMap and headerNames with a pointer back to the parser. was (Author: garydgregory): Alternatively, we could add getHeaderNames() to CSVParser and drop it completely from CSVRecord. That would make the information available, just not on each record. Thoughts? There is no hard-core process. For contributors, it is nicer for us to get contributions through GitHub. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843566#comment-16843566 ] Gary Gregory commented on CSV-239: -- In retrospect, I should have done this in a branch. Please see git master for the redo. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843912#comment-16843912 ] Gary Gregory commented on CSV-239: -- Yep, seems like a great idea. Please see git master and circle back :) > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CODEC-134. Resolution: Fixed Assignee: Gary Gregory Fix Version/s: 1.13 Squashed and merged in git master. > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char >Assignee: Gary Gregory >Priority: Major > Labels: security > Fix For: 1.13 > > Attachments: diff-120305-20.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[
https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844402#comment-16844402
]
Gary Gregory commented on CSV-239:
--
{quote}Just noticed, CSVParser.createHeaderNames should be private.
{quote}
Done
{quote}Yep, the unmodifiableList change looks good. What about getCSVParser ->
getParser?
{quote}
Done
> Cannot get headers in column order from CSVRecord
> -
>
> Key: CSV-239
> URL: https://issues.apache.org/jira/browse/CSV-239
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.6
>Reporter: Dave Moten
>Priority: Minor
>
> I have a use case where I read many lines from an arbitrary csv file with a
> given CSVFormat as List, transform that list and then want to
> write the transformed list to another file.
> When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the
> headers from the first line are available in the CSVRecord object via the
> CSVRecord.toMap object but their column positions are not (the iteration of
> the returned map does not reflect column order). Consequently I cannot write
> a header line in the correct order to the output csv file (which I do when
> the first CSVRecord is to be written).
> Another option would be to be to ensure that the CSVPrinter object writes the
> header on the first call to CSVPrinter.printRecord but we should also be able
> to cover the user case where we are writing to a non-csv format and we still
> want to write the headers in the correct order.
> My preference at minimum is that the headers with column order are available
> from CSVRecord (after all the data to supply this is already present in
> CVSRecord). The addition of a method `getHeaders` returning a `List`
> would do the job. I'm happy to submit a PR if desired.
> I've marked this as of minor importance but I think it's a pretty important
> flaw in the library at the moment that prevents event the simplest of
> round-trip (read then write) scenarios when the headers are read from the
> file rather than known up-front.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[
https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844408#comment-16844408
]
Gary Gregory commented on CSV-239:
--
{quote}??I also see the change in createHeaders of a LinkedHashMap to a TreeSet
and the return of a LinkedHashMap copy in CVSRecord.toMap. if this is an
attempt to make the entries iterable in column order it doesn't work! TreeSets
order on key value (header name) for starters.??
Can you also comment on this? I would like to see `toMap` iterator return
records in column order and say so in the javadoc of `toMap`.
{quote}
The change from LinkedHashMap to a TreeSet was a mistake but we do not have a
unit test to check whatever the consequence was. I changed it back.
WRT toMap(), I'll let you provide a PR ;)
I wonder if we should create a new method that says exactly what you want,
since someone else might want a different order tomorrow. Say
toColumnOrderMap(), and someone can then have toSortedMap() which would sort on
keys, and toMap(Comparator), and so on.
> Cannot get headers in column order from CSVRecord
> -
>
> Key: CSV-239
> URL: https://issues.apache.org/jira/browse/CSV-239
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.6
>Reporter: Dave Moten
>Priority: Minor
>
> I have a use case where I read many lines from an arbitrary csv file with a
> given CSVFormat as List, transform that list and then want to
> write the transformed list to another file.
> When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the
> headers from the first line are available in the CSVRecord object via the
> CSVRecord.toMap object but their column positions are not (the iteration of
> the returned map does not reflect column order). Consequently I cannot write
> a header line in the correct order to the output csv file (which I do when
> the first CSVRecord is to be written).
> Another option would be to be to ensure that the CSVPrinter object writes the
> header on the first call to CSVPrinter.printRecord but we should also be able
> to cover the user case where we are writing to a non-csv format and we still
> want to write the headers in the correct order.
> My preference at minimum is that the headers with column order are available
> from CSVRecord (after all the data to supply this is already present in
> CVSRecord). The addition of a method `getHeaders` returning a `List`
> would do the job. I'm happy to submit a PR if desired.
> I've marked this as of minor importance but I think it's a pretty important
> flaw in the library at the moment that prevents event the simplest of
> round-trip (read then write) scenarios when the headers are read from the
> file rather than known up-front.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CONFIGURATION-745) Add the special key "includeoptional" for properties files.
Gary Gregory created CONFIGURATION-745: -- Summary: Add the special key "includeoptional" for properties files. Key: CONFIGURATION-745 URL: https://issues.apache.org/jira/browse/CONFIGURATION-745 Project: Commons Configuration Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Add the special key "includeoptional" for properties files. If the file is missing, the rest of the file is processed normally, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CONFIGURATION-746) Update Jackson from 2.9.8 to 2.9.9.
Gary Gregory created CONFIGURATION-746: -- Summary: Update Jackson from 2.9.8 to 2.9.9. Key: CONFIGURATION-746 URL: https://issues.apache.org/jira/browse/CONFIGURATION-746 Project: Commons Configuration Issue Type: Improvement Reporter: Gary Gregory Assignee: Gary Gregory Update Jackson from 2.9.8 to 2.9.9. com.fasterxml.jackson.core:jackson-databind 2.9.8 -> 2.9.9 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-746) Update Jackson from 2.9.8 to 2.9.9.
[ https://issues.apache.org/jira/browse/CONFIGURATION-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-746. -- Resolution: Fixed Fix Version/s: 2.5 In git master. > Update Jackson from 2.9.8 to 2.9.9. > --- > > Key: CONFIGURATION-746 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-746 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.5 > > > Update Jackson from 2.9.8 to 2.9.9. > com.fasterxml.jackson.core:jackson-databind 2.9.8 -> 2.9.9 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CONFIGURATION-747) Update Spring from 4.3.22 to 4.3.24.
Gary Gregory created CONFIGURATION-747: -- Summary: Update Spring from 4.3.22 to 4.3.24. Key: CONFIGURATION-747 URL: https://issues.apache.org/jira/browse/CONFIGURATION-747 Project: Commons Configuration Issue Type: Improvement Reporter: Gary Gregory Assignee: Gary Gregory Update Spring from 4.3.22 to 4.3.24. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-747) Update Spring from 4.3.22 to 4.3.24.
[ https://issues.apache.org/jira/browse/CONFIGURATION-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-747. -- Resolution: Fixed Fix Version/s: 2.5 In git master. > Update Spring from 4.3.22 to 4.3.24. > > > Key: CONFIGURATION-747 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-747 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.5 > > > Update Spring from 4.3.22 to 4.3.24. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-745) Add the special key "includeoptional" for properties files.
[ https://issues.apache.org/jira/browse/CONFIGURATION-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844426#comment-16844426 ] Gary Gregory commented on CONFIGURATION-745: Created PR https://github.com/apache/commons-configuration/pull/27 > Add the special key "includeoptional" for properties files. > --- > > Key: CONFIGURATION-745 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-745 > Project: Commons Configuration > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add the special key "includeoptional" for properties files. > If the file is missing, the rest of the file is processed normally, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844429#comment-16844429 ] Gary Gregory commented on CSV-239: -- [done for tonight, tomorrow...] > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COLLECTIONS-718) Fix LRUMap exception message
Gary Gregory created COLLECTIONS-718: Summary: Fix LRUMap exception message Key: COLLECTIONS-718 URL: https://issues.apache.org/jira/browse/COLLECTIONS-718 Project: Commons Collections Issue Type: Improvement Reporter: Gary Gregory Assignee: Gary Gregory Fix LRUMap exception message -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COLLECTIONS-718) Fix LRUMap exception message
[ https://issues.apache.org/jira/browse/COLLECTIONS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed COLLECTIONS-718. Resolution: Fixed Fix Version/s: 4.4 In git master. > Fix LRUMap exception message > > > Key: COLLECTIONS-718 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-718 > Project: Commons Collections > Issue Type: Improvement >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 4.4 > > > Fix LRUMap exception message. > The exception error message does not include an '=' before every field. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COLLECTIONS-718) Fix LRUMap exception message
[ https://issues.apache.org/jira/browse/COLLECTIONS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated COLLECTIONS-718: - Description: Fix LRUMap exception message. The exception error message does not include an '=' before every field. was:Fix LRUMap exception message > Fix LRUMap exception message > > > Key: COLLECTIONS-718 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-718 > Project: Commons Collections > Issue Type: Improvement >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > > Fix LRUMap exception message. > The exception error message does not include an '=' before every field. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844884#comment-16844884 ] Gary Gregory commented on CSV-239: -- Please feel free to provide a PR. Busy w day job... ;) > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845011#comment-16845011 ] Gary Gregory commented on CODEC-134: I currently have no plans for a release. Someone else might pick up the task. Otherwise, it will be on my todo list. > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char >Assignee: Gary Gregory >Priority: Major > Labels: security > Fix For: 1.13 > > Attachments: diff-120305-20.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845272#comment-16845272 ] Gary Gregory commented on CODEC-134: You just did ;) I'm sure I or someone else should be able to get to it in that time frame. > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char >Assignee: Gary Gregory >Priority: Major > Labels: security > Fix For: 1.13 > > Attachments: diff-120305-20.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-745) Add the special key "includeoptional" for properties files.
[ https://issues.apache.org/jira/browse/CONFIGURATION-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-745. -- Resolution: Fixed Fix Version/s: 2.5 In git master. > Add the special key "includeoptional" for properties files. > --- > > Key: CONFIGURATION-745 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-745 > Project: Commons Configuration > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.5 > > Time Spent: 20m > Remaining Estimate: 0h > > Add the special key "includeoptional" for properties files. > If the file is missing, the rest of the file is processed normally, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845789#comment-16845789 ] Gary Gregory commented on CODEC-134: [~melloware], In the meantime, feel free to review this component or even the rest of Apache Commons. Gary > Base32 would decode some invalid Base32 encoded string into arbitrary value > --- > > Key: CODEC-134 > URL: https://issues.apache.org/jira/browse/CODEC-134 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.6 > Environment: All >Reporter: Hanson Char >Assignee: Gary Gregory >Priority: Major > Labels: security > Fix For: 1.13 > > Attachments: diff-120305-20.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Example, there is no byte array value that can be encoded into the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation > would not reject it but decode it into an arbitrary value which if re-encoded > again using the same implementation would result in the string > "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===". > Instead of blindly decoding the invalid string, the Base32 codec should > reject it (eg by throwing IlleglArgumentException) to avoid security > exploitation (such as tunneling additional information via seemingly valid > base 32 strings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CSV-239) Cannot get headers in column order from CSVRecord
[ https://issues.apache.org/jira/browse/CSV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CSV-239. -- Resolution: Fixed Fix Version/s: 1.7 Please review and close if all is well. > Cannot get headers in column order from CSVRecord > - > > Key: CSV-239 > URL: https://issues.apache.org/jira/browse/CSV-239 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6 >Reporter: Dave Moten >Priority: Minor > Fix For: 1.7 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I have a use case where I read many lines from an arbitrary csv file with a > given CSVFormat as List, transform that list and then want to > write the transformed list to another file. > When I specify the format as CSVFormat.DEFAULT.withFirstRecordAsHeader() the > headers from the first line are available in the CSVRecord object via the > CSVRecord.toMap object but their column positions are not (the iteration of > the returned map does not reflect column order). Consequently I cannot write > a header line in the correct order to the output csv file (which I do when > the first CSVRecord is to be written). > Another option would be to be to ensure that the CSVPrinter object writes the > header on the first call to CSVPrinter.printRecord but we should also be able > to cover the user case where we are writing to a non-csv format and we still > want to write the headers in the correct order. > My preference at minimum is that the headers with column order are available > from CSVRecord (after all the data to supply this is already present in > CVSRecord). The addition of a method `getHeaders` returning a `List` > would do the job. I'm happy to submit a PR if desired. > I've marked this as of minor importance but I think it's a pretty important > flaw in the library at the moment that prevents event the simplest of > round-trip (read then write) scenarios when the headers are read from the > file rather than known up-front. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CONFIGURATION-694) Update Java requirement from version 7 to 8.
[
https://issues.apache.org/jira/browse/CONFIGURATION-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-694:
---
Fix Version/s: (was: 2.5)
2.6
> Update Java requirement from version 7 to 8.
>
>
> Key: CONFIGURATION-694
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-694
> Project: Commons Configuration
> Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.6
>
>
> Update Java requirement from version 7 to 8.
> Then the plan is to add support for some type from {{java.time}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IO-608) Add a convenience NullPrintStream
Gary Gregory created IO-608:
---
Summary: Add a convenience NullPrintStream
Key: IO-608
URL: https://issues.apache.org/jira/browse/IO-608
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.7
We have a handy {{NullOutputStream}}.
I'd like to add a convenience {{NullPrintStream}}, which would dead simple:
{code:java}
/**
* This PrintStream writes all data to the famous /dev/null.
*
* This print stream has no destination (file/socket etc.) and all bytes
written to it are ignored and lost.
*
* @since 2.7
*/
public class NullPrintStream extends PrintStream {
public static final NullPrintStream NULL_PRINT_STREAM = new
NullPrintStream();
@SuppressWarnings("resource")
public NullPrintStream() {
super(new NullOutputStream());
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IO-608) Add a convenience NullPrintStream
[
https://issues.apache.org/jira/browse/IO-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed IO-608.
---
Resolution: Fixed
In git master.
> Add a convenience NullPrintStream
> -
>
> Key: IO-608
> URL: https://issues.apache.org/jira/browse/IO-608
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.7
>
>
> We have a handy {{NullOutputStream}}.
>
> I'd like to add a convenience {{NullPrintStream}}, which would dead simple:
>
> {code:java}
> /**
> * This PrintStream writes all data to the famous /dev/null.
> *
> * This print stream has no destination (file/socket etc.) and all bytes
> written to it are ignored and lost.
> *
> * @since 2.7
> */
> public class NullPrintStream extends PrintStream {
> public static final NullPrintStream NULL_PRINT_STREAM = new
> NullPrintStream();
> @SuppressWarnings("resource")
> public NullPrintStream() {
> super(new NullOutputStream());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114
[ https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed BEANUTILS-520. -- Resolution: Fixed Fix Version/s: 2.0.0 In git master. > BeanUtils2 mitigate CVE-2014-0114 > - > > Key: BEANUTILS-520 > URL: https://issues.apache.org/jira/browse/BEANUTILS-520 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.3 >Reporter: Melloware >Priority: Major > Labels: security > Fix For: 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > https://nvd.nist.gov/vuln/detail/CVE-2014-0114 > Due to the above CVE in 1.9.2 they added a Suppression but it is still being > marked as a security risk through most major checks from OWASP and Sonatype > IQ. > "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes > a specialized instance of itself as the SUPPRESS_CLASS constant beginning in > version 1.9.2 that specifically suppresses the class property. +However, this > fix is not enabled by default.+" > For BeanUtils2 why not make this the default and have people "enable" it if > it they want to get the feature. > Thanks for your consideration. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TEXT-165) ResourceBundleStringLookup.lookup(String)
Gary Gregory created TEXT-165:
-
Summary: ResourceBundleStringLookup.lookup(String)
Key: TEXT-165
URL: https://issues.apache.org/jira/browse/TEXT-165
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.6
Reporter: Gary Gregory
Assignee: Gary Gregory
The method
{{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
throws a {{MissingResourceException}} instead of returning {{null}} if a key is
absent.
This is a problem when you are using a resource bundle like this for example,
when the key is missing, we want the method to return null such that an
interpolator can supply a default value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TEXT-165) ResourceBundleStringLookup.lookup(String) throws Mi
[
https://issues.apache.org/jira/browse/TEXT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated TEXT-165:
--
Summary: ResourceBundleStringLookup.lookup(String) throws Mi (was:
ResourceBundleStringLookup.lookup(String))
> ResourceBundleStringLookup.lookup(String) throws Mi
> ---
>
> Key: TEXT-165
> URL: https://issues.apache.org/jira/browse/TEXT-165
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The method
> {{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
> throws a {{MissingResourceException}} instead of returning {{null}} if a key
> is absent.
> This is a problem when you are using a resource bundle like this for example,
> when the key is missing, we want the method to return null such that an
> interpolator can supply a default value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TEXT-165) ResourceBundleStringLookup.lookup(String) throws MissingResourceException instead of returning null
[
https://issues.apache.org/jira/browse/TEXT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated TEXT-165:
--
Summary: ResourceBundleStringLookup.lookup(String) throws
MissingResourceException instead of returning null (was:
ResourceBundleStringLookup.lookup(String) throws Mi)
> ResourceBundleStringLookup.lookup(String) throws MissingResourceException
> instead of returning null
> ---
>
> Key: TEXT-165
> URL: https://issues.apache.org/jira/browse/TEXT-165
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The method
> {{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
> throws a {{MissingResourceException}} instead of returning {{null}} if a key
> is absent.
> This is a problem when you are using a resource bundle like this for example,
> when the key is missing, we want the method to return null such that an
> interpolator can supply a default value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TEXT-165) ResourceBundleStringLookup.lookup(String) throws MissingResourceException instead of returning null
[
https://issues.apache.org/jira/browse/TEXT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed TEXT-165.
-
Resolution: Fixed
Fix Version/s: 1.7
In git master.
> ResourceBundleStringLookup.lookup(String) throws MissingResourceException
> instead of returning null
> ---
>
> Key: TEXT-165
> URL: https://issues.apache.org/jira/browse/TEXT-165
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.7
>
>
> The method
> {{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
> throws a {{MissingResourceException}} instead of returning {{null}} if a key
> is absent.
> This is a problem when you are using a resource bundle like this for example,
> when the key is missing, we want the method to return null such that an
> interpolator can supply a default value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags
[
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852952#comment-16852952
]
Gary Gregory commented on CODEC-214:
I am -1 here due to the Javadoc warning:
{quote}Note: Custom tags that could override future standard tags: @Immutable,
@ThreadSafe, @NotThreadSafe. To avoid potential overrides, use at least one
period character (.) in custom tag names.
{quote}
Commons Compress suppresses Javadoc console output so you do not see this
unless you set quiet to false.
> Update POM to support @NotThreadSafe @Immutable Javadoc tags
>
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
> Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags
[
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852952#comment-16852952
]
Gary Gregory edited comment on CODEC-214 at 5/31/19 12:10 PM:
--
I am -1 here due to the Javadoc warning:
{quote}Note: Custom tags that could override future standard tags: @Immutable,
@ThreadSafe, @NotThreadSafe. To avoid potential overrides, use at least one
period character (.) in custom tag names.
{quote}
Commons Compress suppresses Javadoc console output so you do not see this
unless you set quiet to false.
If we really want this we should use {{@org.apache.commons.Immutable}} and so
on.
was (Author: garydgregory):
I am -1 here due to the Javadoc warning:
{quote}Note: Custom tags that could override future standard tags: @Immutable,
@ThreadSafe, @NotThreadSafe. To avoid potential overrides, use at least one
period character (.) in custom tag names.
{quote}
Commons Compress suppresses Javadoc console output so you do not see this
unless you set quiet to false.
> Update POM to support @NotThreadSafe @Immutable Javadoc tags
>
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
> Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags
[ https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852957#comment-16852957 ] Gary Gregory commented on CODEC-214: Close it because...? You do not want to use tags with fully-qualified names? If the tags provide value, they do so regardless of the exact naming convention. What am I missing in your change of opinion? > Update POM to support @NotThreadSafe @Immutable Javadoc tags > > > Key: CODEC-214 > URL: https://issues.apache.org/jira/browse/CODEC-214 > Project: Commons Codec > Issue Type: New Feature >Reporter: Sebb >Priority: Major > Attachments: pom.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Commons Compress uses @Immutable etc tags in Javadoc > Codec could do the same -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853201#comment-16853201 ] Gary Gregory commented on BCEL-317: --- Hi [~suztomo], "When our tool checks classes" How do you do that? We have an API to get cached instances but it is not used internally: org.apache.bcel.classfile.ConstantUtf8.getCachedInstance(String). We need know how you use the library in order to even find out how we can adapt to your use case. Thank you, Gary > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 10m > Remaining Estimate: 0h > > Follow-up of https://issues.apache.org/jira/browse/BCEL-186. This enhancement > is to provide an option to cache ConstantUtf8 instances that have the same > value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COLLECTIONS-719) Create a PropertiesFactory and SortedPropertiesFactory
Gary Gregory created COLLECTIONS-719:
Summary: Create a PropertiesFactory and SortedPropertiesFactory
Key: COLLECTIONS-719
URL: https://issues.apache.org/jira/browse/COLLECTIONS-719
Project: Commons Collections
Issue Type: New Feature
Components: Properties
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 4.4
Create a {{PropertiesFactory}} and {{SortedPropertiesFactory}} to create and
load {{Properties}} and {{SortedProperties}} from standard sources.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COLLECTIONS-719) Create a PropertiesFactory and SortedPropertiesFactory
[
https://issues.apache.org/jira/browse/COLLECTIONS-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated COLLECTIONS-719:
-
Description:
Create a {{PropertiesFactory}} and {{SortedPropertiesFactory}} to create and
load {{Properties}} and {{SortedProperties}} from standard sources.
See https://github.com/apache/commons-collections/pull/75
was:
Create a {{PropertiesFactory}} and {{SortedPropertiesFactory}} to create and
load {{Properties}} and {{SortedProperties}} from standard sources.
> Create a PropertiesFactory and SortedPropertiesFactory
> --
>
> Key: COLLECTIONS-719
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-719
> Project: Commons Collections
> Issue Type: New Feature
> Components: Properties
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Create a {{PropertiesFactory}} and {{SortedPropertiesFactory}} to create and
> load {{Properties}} and {{SortedProperties}} from standard sources.
> See https://github.com/apache/commons-collections/pull/75
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COLLECTIONS-719) Create a PropertiesFactory and SortedPropertiesFactory
[
https://issues.apache.org/jira/browse/COLLECTIONS-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated COLLECTIONS-719:
-
External issue URL: https://github.com/apache/commons-collections/pull/75
External issue ID: 75
> Create a PropertiesFactory and SortedPropertiesFactory
> --
>
> Key: COLLECTIONS-719
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-719
> Project: Commons Collections
> Issue Type: New Feature
> Components: Properties
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Create a {{PropertiesFactory}} and {{SortedPropertiesFactory}} to create and
> load {{Properties}} and {{SortedProperties}} from standard sources.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CODEC-253) Upgrade to Java 8
[
https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854488#comment-16854488
]
Gary Gregory commented on CODEC-253:
[~melloware]: Yes, IMO, we can close this; YMMV.
[~michael-o]: The comment
https://issues.apache.org/jira/browse/CODEC-253?focusedCommentId=16761022&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16761022:
{quote}Java 7 still receives updates, many commercial vendors will provide
updates too.
{quote}
is to me a reason _against_ staying on Java 7. We cannot get these updates,
only companies that pay for Java 7 commercial support (from Oracle) get them.
So we have to way to know if newer "private" versions of Java 7 work or break
for us. Granted this is an unlikely case, but I do see why, as a FOSS
organization we should support Java 7 when support is only offered to paid
customers.
> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
> Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.13
>
>
> Upgrade to java 8 as the target of of the build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CODEC-253. Resolution: Fixed > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BCEL-318) Add org.apache.bcel.classfile.ConstantUtf8.clearCache().
Gary Gregory created BCEL-318:
-
Summary: Add org.apache.bcel.classfile.ConstantUtf8.clearCache().
Key: BCEL-318
URL: https://issues.apache.org/jira/browse/BCEL-318
Project: Commons BCEL
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Add {{org.apache.bcel.classfile.ConstantUtf8.clearCache()}}.
There was previously no way to clear the cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Deleted] (BCEL-319) DumpClass.main(String[]) leaks FileImageInputStream
[
https://issues.apache.org/jira/browse/BCEL-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory deleted BCEL-319:
--
> DumpClass.main(String[]) leaks FileImageInputStream
> ---
>
> Key: BCEL-319
> URL: https://issues.apache.org/jira/browse/BCEL-319
> Project: Commons BCEL
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The method {{DumpClass.main(String[])}} leaks {{FileImageInputStream}}
> instances by never closing them.
> This only matters if invoked via an API call instead of from an OS shell.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (BCEL-319) DumpClass.main(String[]) leaks FileImageInputStream
Gary Gregory created BCEL-319:
-
Summary: DumpClass.main(String[]) leaks FileImageInputStream
Key: BCEL-319
URL: https://issues.apache.org/jira/browse/BCEL-319
Project: Commons BCEL
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
The method {{DumpClass.main(String[])}} leaks {{FileImageInputStream}}
instances by never closing them.
This only matters if invoked via an API call instead of from an OS shell.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854538#comment-16854538
]
Gary Gregory commented on BCEL-317:
---
Hi [~suztomo],
I do not see such methods in {{src/examples/ClassDumper.java}}. Do you have a
customized version of the example?
Gary
> Pluggable cache for ConstantUtf8
>
>
> Key: BCEL-317
> URL: https://issues.apache.org/jira/browse/BCEL-317
> Project: Commons BCEL
> Issue Type: Improvement
> Components: Main
>Affects Versions: 6.3.1
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: 2644k_constantutf8_without_getCachedInstance.png,
> 621k_constantutf8_with_getCachedInstance.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Follow-up of BCEL-186. This enhancement is to provide an option to cache
> ConstantUtf8 instances that have the same value.
>
> Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
> instances
>
> We use BCEL library to inspect Java class. Thank you for the great library.
>
> When our tool checks classes in ~200 jar files, it creates more than 2
> million BCEL ConstantUtf8 instances. I suspect many of them share the same
> values such as "java.lang.String".
>
> Without cache, my tool created 2,6 million ConstantUtf8 instances (before
> failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
> !2644k_constantutf8_without_getCachedInstance.png!
>
> With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
> didn't throw the OutOfMemoryError.
> !621k_constantutf8_with_getCachedInstance.png!
>
> Old commit that made ConstantUtf8.getInstance
> [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383]
> The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
> [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541]
>
> h1. How our project uses BCEL
> Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200
> JAR files as its input class path
> ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
> and reads JavaClass one by one
> ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
> through the ClassPathRepository.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854631#comment-16854631 ] Gary Gregory commented on BCEL-317: --- May you please show how you use the BCEL API? That will help me see if I can provide a minimal change set for you to test... > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383] > The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 > [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541] > > h1. How our project uses BCEL > Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 > JAR files as its input class path > ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) > and reads JavaClass one by one > ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) > through the ClassPathRepository. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1461) Add null-safe versions to wrap getBytes(String, [Charset|String])
Gary Gregory created LANG-1461:
--
Summary: Add null-safe versions to wrap getBytes(String,
[Charset|String])
Key: LANG-1461
URL: https://issues.apache.org/jira/browse/LANG-1461
Project: Commons Lang
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 3.10
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Summary: Add null-safe StringUtils APIs to wrap getBytes(String,
[Charset|String]) (was: Add null-safe versions to wrap getBytes(String,
[Charset|String]))
> Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String])
> -
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Summary: Add null-safe StringUtils APIs to wrap
String#getBytes([Charset|String]) (was: Add null-safe StringUtils APIs to wrap
getBytes(String, [Charset|String]))
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Description:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
Also adds the following used by the above:
* {{CharSetUtils.defaultCharset(Charset)}}
* {{CharSetUtils.defaultCharset(String)}}
was:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
> Also adds the following used by the above:
> * {{CharSetUtils.defaultCharset(Charset)}}
> * {{CharSetUtils.defaultCharset(String)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Description:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
was:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
Also adds the following used by the above:
* {{CharSetUtils.defaultCharset(Charset)}}
* {{CharSetUtils.defaultCharset(String)}}
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LANG-1461.
--
Resolution: Fixed
In git master.
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-240) Links for JavaDoc broken on web site
[ https://issues.apache.org/jira/browse/CSV-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855046#comment-16855046 ] Gary Gregory commented on CSV-240: -- This will be fixed in the upcoming release; for a preview please see https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/site/index.html > Links for JavaDoc broken on web site > > > Key: CSV-240 > URL: https://issues.apache.org/jira/browse/CSV-240 > Project: Commons CSV > Issue Type: Bug > Components: Documentation >Affects Versions: 1.6 >Reporter: Basil >Priority: Minor > > The sidebar on the left of this page: > [https://commons.apache.org/proper/commons-csv/] > …has items for `Javadoc 1.6`, `Javadoc 1.5`, and so on. The main body of the > page has the same. All of these links for the numbered versions of `Javadoc` > are broken, resulting in a `Not Found` error page. > For example, one such broken link: > [https://commons.apache.org/proper/commons-csv/archives/1.6/apidocs/index.html] > The only Javadoc link that works is `Javadoc Trunk`, but that is for the > forthcoming release, not the current release. > https://commons.apache.org/proper/commons-csv/apidocs/index.html > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Moved] (CSV-241) CSVFormat#valiadte() does not account for allowDuplicateHeaderNames #43
[
https://issues.apache.org/jira/browse/CSV-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory moved COLLECTIONS-720 to CSV-241:
--
Workflow: classic default workflow (was: Default workflow, editable Closed
status)
Key: CSV-241 (was: COLLECTIONS-720)
Project: Commons CSV (was: Commons Collections)
> CSVFormat#valiadte() does not account for allowDuplicateHeaderNames #43
> ---
>
> Key: CSV-241
> URL: https://issues.apache.org/jira/browse/CSV-241
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Gary Gregory
>Priority: Major
>
> {{CSVFormat#valiadte()}} does not account for {{allowDuplicateHeaderNames}}
> {color:#a3aab1}#43{color}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (COLLECTIONS-720) CSVFormat#valiadte() does not account for allowDuplicateHeaderNames #43
Gary Gregory created COLLECTIONS-720:
Summary: CSVFormat#valiadte() does not account for
allowDuplicateHeaderNames #43
Key: COLLECTIONS-720
URL: https://issues.apache.org/jira/browse/COLLECTIONS-720
Project: Commons Collections
Issue Type: Bug
Reporter: Gary Gregory
{{CSVFormat#valiadte()}} does not account for {{allowDuplicateHeaderNames}}
{color:#a3aab1}#43{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16857152#comment-16857152
]
Gary Gregory commented on BCEL-317:
---
Hi [~suztomo],
I've been thinking about this as well and have been experimenting with changes,
which I now realize are too complex and extensive. I think simpler will be
better, I'll keep you posted.
Gary
> Pluggable cache for ConstantUtf8
>
>
> Key: BCEL-317
> URL: https://issues.apache.org/jira/browse/BCEL-317
> Project: Commons BCEL
> Issue Type: Improvement
> Components: Main
>Affects Versions: 6.3.1
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: 2644k_constantutf8_without_getCachedInstance.png,
> 621k_constantutf8_with_getCachedInstance.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Follow-up of BCEL-186. This enhancement is to provide an option to cache
> ConstantUtf8 instances that have the same value.
>
> Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
> instances
>
> We use BCEL library to inspect Java class. Thank you for the great library.
>
> When our tool checks classes in ~200 jar files, it creates more than 2
> million BCEL ConstantUtf8 instances. I suspect many of them share the same
> values such as "java.lang.String".
>
> Without cache, my tool created 2,6 million ConstantUtf8 instances (before
> failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
> !2644k_constantutf8_without_getCachedInstance.png!
>
> With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
> didn't throw the OutOfMemoryError.
> !621k_constantutf8_with_getCachedInstance.png!
>
> Old commit that made ConstantUtf8.getInstance
> [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383]
> The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
> [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541&r2=1652540&pathrev=1652541]
>
> h1. How our project uses BCEL
> - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
> 200 JAR files as its input class path in
> ClassDumper.createClassRepository([source code
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
> {code:java}
> private static Repository createClassRepository(List paths) {
> ClassPath classPath = new LinkageCheckClassPath(paths);
> return new ClassPathRepository(classPath); # This is BCEL API
> }{code}
> - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
> through the ClassPathRepository.
> {code:java}
> private ImmutableSet listClassesInJar(Path jar) throws
> IOException {
> ImmutableSet.Builder javaClasses = ImmutableSet.builder();
> for (String className : listClassNamesInJar(jar)) {
> try {
> JavaClass javaClass = classRepository.loadClass(className); # This is
> BCEL API. ConstantUtf8 is not cached.
> javaClasses.add(javaClass);
> ...(omit)
> return javaClasses.build();
> }{code}
> Stacktrace from the ClassDumper.listClassesInJar to BCEL's
> ConstantUtf8.getInstance would look like this:
> {code:java}
> ConstantUtf8.getInstance
> Constant.readConstant
> ConstantPool.
> ClassParser.readConstantPool
> ClassParser.parse
> ClassPathRepository.loadClass
> ClassPathRepository.loadClass
> ClassDumper.listClassesInJar {code}
> - Use the JavaClass instances to check if any symbol references (entries in
> constant pool [Java Virtual Machine Specification 4.4. The Constant
> Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]:
> CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and
> CONSTANT_InterfaceMethodref) has invalid referent in the class path.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CSV-241) CSVFormat#valiadte() does not account for allowDuplicateHeaderNames #43
[
https://issues.apache.org/jira/browse/CSV-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed CSV-241.
Resolution: Fixed
Fix Version/s: 1.8
In git master.
> CSVFormat#valiadte() does not account for allowDuplicateHeaderNames #43
> ---
>
> Key: CSV-241
> URL: https://issues.apache.org/jira/browse/CSV-241
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 1.8
>
>
> {{CSVFormat#valiadte()}} does not account for {{allowDuplicateHeaderNames}}
> {color:#a3aab1}#43{color}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-228) CSVParser extracts columns wrong in case of space before quoted col name with comma
[
https://issues.apache.org/jira/browse/CSV-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864038#comment-16864038
]
Gary Gregory commented on CSV-228:
--
We will need a reproducible test case, preferably in the form of a PR. See also
{{org.apache.commons.csv.CSVFormat.withIgnoreSurroundingSpaces(boolean)}}
> CSVParser extracts columns wrong in case of space before quoted col name with
> comma
> ---
>
> Key: CSV-228
> URL: https://issues.apache.org/jira/browse/CSV-228
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Artemii Chugreev
>Priority: Minor
>
> CSV header is something like
> col name 1, "col name 2, with comma", col name 3
> CSVParser#getHeadersMap returns 4 columns, because of space before second
> column name which breaks quoting
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CSV-245) Post 1.7 release fixes.
Gary Gregory created CSV-245: Summary: Post 1.7 release fixes. Key: CSV-245 URL: https://issues.apache.org/jira/browse/CSV-245 Project: Commons CSV Issue Type: Bug Affects Versions: 1.7 Reporter: Gary Gregory * Fix checkstyle: remove tabs * Fix checkstyle: Split long line * Fix checkstyle: exclude pom.properties * Update findbugs to allow deliberate fall-through * Fix pmd: Remove ternary operator returning false * Fix pmd: Remove implicit final * Fix pmd: Ignore TooManyStaticImports. This requires adding the default ruleset and then modifying with suppressions. * Add tests to cover use of the IOUtils class. Requires the CSVFormat to have no quote or escape character, and the formatted value to be a java.io.Reader. * Clean-up findbugs exclude filter. * Removed unused import * Updated test comments for print tests targeting IOUtils. * Fix checkstyle: Suppress line length warning in CSVParser. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CSV-245) Post 1.7 release fixes.
[ https://issues.apache.org/jira/browse/CSV-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CSV-245. Resolution: Fixed Fix Version/s: 1.8 In git master. > Post 1.7 release fixes. > --- > > Key: CSV-245 > URL: https://issues.apache.org/jira/browse/CSV-245 > Project: Commons CSV > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Gary Gregory >Priority: Major > Fix For: 1.8 > > > * Fix checkstyle: remove tabs > * Fix checkstyle: Split long line > * Fix checkstyle: exclude pom.properties > * Update findbugs to allow deliberate fall-through > * Fix pmd: Remove ternary operator returning false > * Fix pmd: Remove implicit final > * Fix pmd: Ignore TooManyStaticImports. > This requires adding the default ruleset and then modifying with > suppressions. > * Add tests to cover use of the IOUtils class. > Requires the CSVFormat to have no quote or escape character, and the > formatted value to be a java.io.Reader. > * Clean-up findbugs exclude filter. > * Removed unused import > * Updated test comments for print tests targeting IOUtils. > * Fix checkstyle: Suppress line length warning in CSVParser. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-717) Udpate org.apache.httpcomponents:httpclient fro
Gary Gregory created VFS-717: Summary: Udpate org.apache.httpcomponents:httpclient fro Key: VFS-717 URL: https://issues.apache.org/jira/browse/VFS-717 Project: Commons VFS Issue Type: Bug Affects Versions: 2.3 Reporter: Gary Gregory Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-717) Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.
[ https://issues.apache.org/jira/browse/VFS-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-717: - Summary: Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. (was: Udpate org.apache.httpcomponents:httpclient fro) > Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. > > > Key: VFS-717 > URL: https://issues.apache.org/jira/browse/VFS-717 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > > Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-717) Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.
[ https://issues.apache.org/jira/browse/VFS-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-717: - Description: Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. (was: Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.) > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. > > > Key: VFS-717 > URL: https://issues.apache.org/jira/browse/VFS-717 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-717) Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.
[ https://issues.apache.org/jira/browse/VFS-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-717: - Summary: Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. (was: Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9.) > Update org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. > > > Key: VFS-717 > URL: https://issues.apache.org/jira/browse/VFS-717 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > > Udpate org.apache.httpcomponents:httpclient from 4.5.8 to 4.5.9. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (VFS-698) SFTP file attributes are fetched multiple times leading to very slow directory listing
[
https://issues.apache.org/jira/browse/VFS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-698.
Resolution: Fixed
Fix Version/s: 2.4
> SFTP file attributes are fetched multiple times leading to very slow
> directory listing
> --
>
> Key: VFS-698
> URL: https://issues.apache.org/jira/browse/VFS-698
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: krishnan
>Priority: Major
> Fix For: 2.4
>
>
> getChildren() applied on SftpFileObject is very slow compared to JSCH
> implementation. This is because, the SftpATTRS which is readily available for
> the children after an "ls" call is again fetched for each child file since
> they are independently resolved. So if a directory contains 10 files, it
> results in 1 (ls) + 10 (stat) calls to server.
> For a folder with 100 files (AWS), it took about 35 secs instead of 1.5 secs
> to getChildren().
>
> *doListChildrenResolved:*
> {{final FileObject fo =
> getFileSystem().resolveFile(getFileSystem().getFileSystemManager()}}
> \{{ .resolveName(getName(), UriParser.encode(name), NameScope.CHILD));}}
> {{{color:#ff}((SftpFileObject)
> FileObjectUtils.getAbstractFileObject(fo)).setStat(stat.getAttrs());{color}}}
>
> The resolveFile call, creates a SftpFileObject and calls its resolve method,
> which results in getting the (stats) SftpATTRS for each child file. This stat
> is already available as part of the 'ls' call we made. The setStat call above
> (highlighted is red) is redundant, since stat for each child file is already
> fetched one at a time.
> The solution would be to avoid getting the stat for each child file after an
> 'ls' call. May be, the framework makes it difficult to do this easily.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CODEC-254) ColognePhonetic does not treat the letter H correctly
[ https://issues.apache.org/jira/browse/CODEC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CODEC-254: --- Summary: ColognePhonetic does not treat the letter H correctly (was: ColognePhonetic does not treat the letter H correct) > ColognePhonetic does not treat the letter H correctly > - > > Key: CODEC-254 > URL: https://issues.apache.org/jira/browse/CODEC-254 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > With the fix in CODEC-250 the letter H is not treaten correct any more. > A String 'shch' is coded as 8 and not as 84. (This string is sometimes in > foreign surnames) > The reasen is the letter h is ignored completely and not stored in the > lastChar anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-718) MonitorInputStream should not close the stream in "read" #67
Gary Gregory created VFS-718: Summary: MonitorInputStream should not close the stream in "read" #67 Key: VFS-718 URL: https://issues.apache.org/jira/browse/VFS-718 Project: Commons VFS Issue Type: Bug Affects Versions: 2.3 Reporter: Gary Gregory MonitorInputStream should not close the stream in "read" #67 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (VFS-718) MonitorInputStream should not close the stream in "read" #67
[ https://issues.apache.org/jira/browse/VFS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-718. Resolution: Fixed Fix Version/s: 2.4 In git master. > MonitorInputStream should not close the stream in "read" #67 > > > Key: VFS-718 > URL: https://issues.apache.org/jira/browse/VFS-718 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Gary Gregory >Priority: Major > Fix For: 2.4 > > > MonitorInputStream should not close the stream in "read" #67 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1467) Add zero arg contructor for org.apache.commons.lang3.NotImplementedException
Gary Gregory created LANG-1467:
--
Summary: Add zero arg contructor for
org.apache.commons.lang3.NotImplementedException
Key: LANG-1467
URL: https://issues.apache.org/jira/browse/LANG-1467
Project: Commons Lang
Issue Type: New Feature
Reporter: Gary Gregory
Add zero arg contructor for
{{org.apache.commons.lang3.NotImplementedException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1467) Add zero arg constructor for org.apache.commons.lang3.NotImplementedException
[
https://issues.apache.org/jira/browse/LANG-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1467:
---
Summary: Add zero arg constructor for
org.apache.commons.lang3.NotImplementedException (was: Add zero arg contructor
for org.apache.commons.lang3.NotImplementedException)
> Add zero arg constructor for org.apache.commons.lang3.NotImplementedException
> -
>
> Key: LANG-1467
> URL: https://issues.apache.org/jira/browse/LANG-1467
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Priority: Major
>
> Add zero arg contructor for
> {{org.apache.commons.lang3.NotImplementedException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (LANG-1467) Add zero arg constructor for org.apache.commons.lang3.NotImplementedException
[
https://issues.apache.org/jira/browse/LANG-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LANG-1467.
--
Resolution: Fixed
Fix Version/s: 3.10
In git master.
> Add zero arg constructor for org.apache.commons.lang3.NotImplementedException
> -
>
> Key: LANG-1467
> URL: https://issues.apache.org/jira/browse/LANG-1467
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add zero arg contructor for
> {{org.apache.commons.lang3.NotImplementedException}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-750) XMLPropertyListConfiguration cannot set arrays in the correct plist form
[
https://issues.apache.org/jira/browse/CONFIGURATION-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872327#comment-16872327
]
Gary Gregory commented on CONFIGURATION-750:
[~steinybot] May you provide a PR with a unit test?
> XMLPropertyListConfiguration cannot set arrays in the correct plist form
>
>
> Key: CONFIGURATION-750
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-750
> Project: Commons Configuration
> Issue Type: Bug
> Components: Format
>Affects Versions: 2.5
>Reporter: Jason Pickens
>Assignee: Emmanuel Bourg
>Priority: Minor
>
> This is the same as CONFIGURATION-427 except that it applies to
> {{setProperty}} which was missed in the original fix.
> {code:java}
> final FileBasedConfigurationBuilder builder =
> new
> FileBasedConfigurationBuilder<>(XMLPropertyListConfiguration.class);
> final FileBasedConfiguration configuration = builder.getConfiguration();
> configuration.setProperty("things", ['chair', 'hat', 'door']);
> final FileHandler fileHandler = new FileHandler(configuration);
> fileHandler.save(System.out);
> {code}
> results in
> {code:xml}
>
> "file://localhost/System/Library/DTDs/PropertyList.dtd">
>
>
> things
> chair
> things
> hat
> things
> door
>
>
> {code}
> expecting
> {code:xml}
>
> "file://localhost/System/Library/DTDs/PropertyList.dtd">
>
>
> things
>
> chair
> hat
> door
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-246) Misplaced null test
[
https://issues.apache.org/jira/browse/CSV-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872329#comment-16872329
]
Gary Gregory commented on CSV-246:
--
[~mdernst] May you please provide a PR on GitHub?
> Misplaced null test
> ---
>
> Key: CSV-246
> URL: https://issues.apache.org/jira/browse/CSV-246
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.7
>Reporter: Michael Ernst
>Priority: Trivial
>
> This code appears twice in CSVFileParserTest:
> final String comment = record.getComment().replace("\n", "\\n");
> if (comment != null) {
> The test never fails and seems misplaced.
> If execution gets past replace without a null pointer exception, then the
> variable `comment` is definitely non-null.
> The test should occur before the call to replace, or perhaps is not needed.
> (If it's not needed, why not? The documentation of getComment() says it is
> allowed to return null.)
> Here are the two occurrences:
> https://github.com/apache/commons-csv/blob/master/src/test/java/org/apache/commons/csv/CSVFileParserTest.java#L122
> https://github.com/apache/commons-csv/blob/master/src/test/java/org/apache/commons/csv/CSVFileParserTest.java#L166
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VFS-719) Add methods to get the contents of file objects as strings
Gary Gregory created VFS-719: Summary: Add methods to get the contents of file objects as strings Key: VFS-719 URL: https://issues.apache.org/jira/browse/VFS-719 Project: Commons VFS Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 2.4 Add methods to get the contents of file objects as strings as I keep on coding the same patterns in different projects: - org.apache.commons.vfs2.FileContent.getString(Charset) - org.apache.commons.vfs2.FileContent.getString(String) - org.apache.commons.vfs2.util.FileObjectUtils.getContentAsString(FileObject, Charset) - org.apache.commons.vfs2.util.FileObjectUtils.getContentAsString(FileObject, String) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-720) Implement Closeable for RandomAccessContent #66
Gary Gregory created VFS-720:
Summary: Implement Closeable for RandomAccessContent #66
Key: VFS-720
URL: https://issues.apache.org/jira/browse/VFS-720
Project: Commons VFS
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.4
Implement {{Closeable}} for {{RandomAccessContent}} #66
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (VFS-720) Implement Closeable for RandomAccessContent #66
[
https://issues.apache.org/jira/browse/VFS-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-720.
Resolution: Fixed
in git master.
> Implement Closeable for RandomAccessContent #66
> ---
>
> Key: VFS-720
> URL: https://issues.apache.org/jira/browse/VFS-720
> Project: Commons VFS
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Implement {{Closeable}} for {{RandomAccessContent}} #66
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (VFS-719) Add methods to get the contents of file objects as strings
[ https://issues.apache.org/jira/browse/VFS-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-719. Resolution: Fixed In git master. > Add methods to get the contents of file objects as strings > -- > > Key: VFS-719 > URL: https://issues.apache.org/jira/browse/VFS-719 > Project: Commons VFS > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.4 > > > Add methods to get the contents of file objects as strings as I keep on > coding the same patterns in different projects: > - org.apache.commons.vfs2.FileContent.getString(Charset) > - org.apache.commons.vfs2.FileContent.getString(String) > - org.apache.commons.vfs2.util.FileObjectUtils.getContentAsString(FileObject, > Charset) > - org.apache.commons.vfs2.util.FileObjectUtils.getContentAsString(FileObject, > String) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IO-610) Remove throws IOException in method isSymlink() #80
Gary Gregory created IO-610: --- Summary: Remove throws IOException in method isSymlink() #80 Key: IO-610 URL: https://issues.apache.org/jira/browse/IO-610 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: Gary Gregory Fix For: 2.7 Remove throws IOException in method isSymlink() #80 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IO-610) Remove throws IOException in method isSymlink() #80
[ https://issues.apache.org/jira/browse/IO-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed IO-610. --- Resolution: Fixed In git master. > Remove throws IOException in method isSymlink() #80 > --- > > Key: IO-610 > URL: https://issues.apache.org/jira/browse/IO-610 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Gary Gregory >Priority: Major > Fix For: 2.7 > > > Remove throws IOException in method isSymlink() #80 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DBCP-547) Add a ConnectionFactory Interface in BasicDataSource class
[
https://issues.apache.org/jira/browse/DBCP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876882#comment-16876882
]
Gary Gregory commented on DBCP-547:
---
[~Simple],
Feel free to provide a PR on github with a matching unit test.
Gary
> Add a ConnectionFactory Interface in BasicDataSource class
> --
>
> Key: DBCP-547
> URL: https://issues.apache.org/jira/browse/DBCP-547
> Project: Commons DBCP
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Lee Jun Gyun
>Priority: Minor
>
> It think it would be nice better to implement a ConnectionFactory interface
> in BasicDataSource class or implement a interface in DriverConnectionFactory
> class.
> In my current project, when getting a connection in my program, I call
> oracleSetModule.
> so, i think that after creating connection, call oracleSetModule via
> connectionFactoryImpl seems to be nice.
>
> [Before]
> protected ConnectionFactory createConnectionFactory() throws SQLException {
> ...
> ...
> ConnectionFactory driverConnectionFactory =
> new DriverConnectionFactory(driverToUse, url, connectionProperties);
> return driverConnectionFactory;
> }
> [After]
> protected ConnectionFactory createConnectionFactory() throws SQLException {
> ...
> ...
> ConnectionFactory driverConnectionFactory =
> getConnectionFactoryImpl().newInstance(...);
> return driverConnectionFactory;
> }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-750) XMLPropertyListConfiguration cannot set arrays in the correct plist form
[
https://issues.apache.org/jira/browse/CONFIGURATION-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed CONFIGURATION-750.
--
Resolution: Fixed
Assignee: Gary Gregory (was: Emmanuel Bourg)
Fix Version/s: 2.6
In git master.
> XMLPropertyListConfiguration cannot set arrays in the correct plist form
>
>
> Key: CONFIGURATION-750
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-750
> Project: Commons Configuration
> Issue Type: Bug
> Components: Format
>Affects Versions: 2.5
>Reporter: Jason Pickens
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
>
> This is the same as CONFIGURATION-427 except that it applies to
> {{setProperty}} which was missed in the original fix.
> {code:java}
> final FileBasedConfigurationBuilder builder =
> new
> FileBasedConfigurationBuilder<>(XMLPropertyListConfiguration.class);
> final FileBasedConfiguration configuration = builder.getConfiguration();
> configuration.setProperty("things", ['chair', 'hat', 'door']);
> final FileHandler fileHandler = new FileHandler(configuration);
> fileHandler.save(System.out);
> {code}
> results in
> {code:xml}
>
> "file://localhost/System/Library/DTDs/PropertyList.dtd">
>
>
> things
> chair
> things
> hat
> things
> door
>
>
> {code}
> expecting
> {code:xml}
>
> "file://localhost/System/Library/DTDs/PropertyList.dtd">
>
>
> things
>
> chair
> hat
> door
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
