[jira] [Updated] (CSV-154) CSVFormat.withHeaderComments() doesn't print comments header comments depending on when it is called
[
https://issues.apache.org/jira/browse/CSV-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raffi Khatchadourian updated CSV-154:
-
Description:
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
{code}
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withHeaderComments(Maximum
analysis depth: + this.getMaximumAnalysisDepth()).withCommentMarker('#');
System.out.println(format.getHeaderComments());
{code}
while this code *will* print them:
{code}
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#').withHeaderComments(Maximum
analysis depth: + this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
{code}
was:
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
{code}
StreamString header = getCSVHeader();
CSVFormat format = CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
{code}
while this code *will* print them:
{code}
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
{code}
CSVFormat.withHeaderComments() doesn't print comments header comments
depending on when it is called
Key: CSV-154
URL: https://issues.apache.org/jira/browse/CSV-154
Project: Commons CSV
Issue Type: Bug
Components: Printer
Affects Versions: 1.1
Reporter: Raffi Khatchadourian
Priority: Minor
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
{code}
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withHeaderComments(Maximum
analysis depth: + this.getMaximumAnalysisDepth()).withCommentMarker('#');
System.out.println(format.getHeaderComments());
{code}
while this code *will* print them:
{code}
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#').withHeaderComments(Maximum
analysis depth: + this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CSV-154) CSVFormat.withHeaderComments() doesn't print comments header comments depending on when it is called
Raffi Khatchadourian created CSV-154:
Summary: CSVFormat.withHeaderComments() doesn't print comments
header comments depending on when it is called
Key: CSV-154
URL: https://issues.apache.org/jira/browse/CSV-154
Project: Commons CSV
Issue Type: Bug
Components: Printer
Affects Versions: 1.1
Reporter: Raffi Khatchadourian
Priority: Minor
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
```
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
```
while this code *will* print them:
```
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-154) CSVFormat.withHeaderComments() doesn't print comments header comments depending on when it is called
[
https://issues.apache.org/jira/browse/CSV-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raffi Khatchadourian updated CSV-154:
-
Description:
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
{code}
StreamString header = getCSVHeader();
CSVFormat format = CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
{code}
while this code *will* print them:
{code}
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
{code}
was:
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
while this code *will* print them:
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
CSVFormat.withHeaderComments() doesn't print comments header comments
depending on when it is called
Key: CSV-154
URL: https://issues.apache.org/jira/browse/CSV-154
Project: Commons CSV
Issue Type: Bug
Components: Printer
Affects Versions: 1.1
Reporter: Raffi Khatchadourian
Priority: Minor
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
{code}
StreamString header = getCSVHeader();
CSVFormat format = CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
{code}
while this code *will* print them:
{code}
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-154) CSVFormat.withHeaderComments() doesn't print comments header comments depending on when it is called
[
https://issues.apache.org/jira/browse/CSV-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raffi Khatchadourian updated CSV-154:
-
Description:
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
while this code *will* print them:
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
was:
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
```
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
```
while this code *will* print them:
```
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
```
CSVFormat.withHeaderComments() doesn't print comments header comments
depending on when it is called
Key: CSV-154
URL: https://issues.apache.org/jira/browse/CSV-154
Project: Commons CSV
Issue Type: Bug
Components: Printer
Affects Versions: 1.1
Reporter: Raffi Khatchadourian
Priority: Minor
When building a CSVFormat with header comments, the order in which the with*
methods are called determines if the header comments will appear (note that
this does not seem to be an issue with the header, just the header comments).
For example, the following code *will not* print a header comment:
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new))
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth())
.withCommentMarker('#');
System.out.println(format.getHeaderComments());
while this code *will* print them:
StreamString header = getCSVHeader();
CSVFormat format =
CSVFormat.EXCEL.withHeader(header.toArray(String[]::new)).withCommentMarker('#')
.withHeaderComments(Maximum analysis depth:
+ this.getMaximumAnalysisDepth());
System.out.println(format.getHeaderComments());
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-441) Update DBCP2 configuration web page to add missing properties from BasicDataSource API and BasicDataSourceFactory config
[ https://issues.apache.org/jira/browse/DBCP-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647138#comment-14647138 ] Phil Steitz commented on DBCP-441: -- Missing BDSFactory property added in r1693385. Update DBCP2 configuration web page to add missing properties from BasicDataSource API and BasicDataSourceFactory config Key: DBCP-441 URL: https://issues.apache.org/jira/browse/DBCP-441 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.1 Environment: http://commons.apache.org/proper/commons-dbcp/configuration.html Reporter: Justin Cranford Priority: Minor Labels: documentation, easyfix This web page documents DBCP 2 configuration properties: http://commons.apache.org/proper/commons-dbcp/configuration.html I compared the listed properties to DBCP 2.1 classes BasicDataSource and BasicDataSourceFactory. I noticed 5 configuration properties supported by the code which are missing from the DBCP configuration web page. Please add these properties to the configuration documentation. Thank you. 1) jmxName - mentioned in DBCP-418, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 2) enableAutoCommitOnReturn - mentioned in DBCP-351, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 3) rollbackOnReturn - mentioned in DBCP-399 and DBCP-436, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 4) validationQueryTimeout - mentioned in DBCP-163 and DBCP-226, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 5) defaultQueryTimeout - mentioned in DBCP-340, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page Note: I also noticed BasicDataSource API supports setAbandonedUsageTracking which passes a configuration option to Commons Pool 2. This option is only available in BasicDataSource API, not in BasicDataSourceFactory config, so I am not sure if it was intentionally left out of BasicDataSourceFactory and the DBCP configuration web page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DBCP-441) Update DBCP2 configuration web page to add missing properties from BasicDataSource API and BasicDataSourceFactory config
[ https://issues.apache.org/jira/browse/DBCP-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-441: - Fix Version/s: 2.1.1 Update DBCP2 configuration web page to add missing properties from BasicDataSource API and BasicDataSourceFactory config Key: DBCP-441 URL: https://issues.apache.org/jira/browse/DBCP-441 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.1 Environment: http://commons.apache.org/proper/commons-dbcp/configuration.html Reporter: Justin Cranford Priority: Minor Labels: documentation, easyfix Fix For: 2.1.1 This web page documents DBCP 2 configuration properties: http://commons.apache.org/proper/commons-dbcp/configuration.html I compared the listed properties to DBCP 2.1 classes BasicDataSource and BasicDataSourceFactory. I noticed 5 configuration properties supported by the code which are missing from the DBCP configuration web page. Please add these properties to the configuration documentation. Thank you. 1) jmxName - mentioned in DBCP-418, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 2) enableAutoCommitOnReturn - mentioned in DBCP-351, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 3) rollbackOnReturn - mentioned in DBCP-399 and DBCP-436, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 4) validationQueryTimeout - mentioned in DBCP-163 and DBCP-226, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page 5) defaultQueryTimeout - mentioned in DBCP-340, supported by both BasicDataSource and BasicDataSourceFactory, but not documented on the DBCP configuration web page Note: I also noticed BasicDataSource API supports setAbandonedUsageTracking which passes a configuration option to Commons Pool 2. This option is only available in BasicDataSource API, not in BasicDataSourceFactory config, so I am not sure if it was intentionally left out of BasicDataSourceFactory and the DBCP configuration web page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JEXL-171) Map access operator does not work if key name clashes with map property name
Dmitri Blinov created JEXL-171: -- Summary: Map access operator does not work if key name clashes with map property name Key: JEXL-171 URL: https://issues.apache.org/jira/browse/JEXL-171 Project: Commons JEXL Issue Type: Bug Affects Versions: 3.0 Reporter: Dmitri Blinov Priority: Critical The following example returns *false*, according to documentation should return *2*. i = new (java.util.HashMap); i.a = 1; i[empty] = 2; i[empty] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DAEMON-336) prunsrv crash on service stop
[
https://issues.apache.org/jira/browse/DAEMON-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14645805#comment-14645805
]
masc commented on DAEMON-336:
-
Crash is triggered by {{apxHandleManagerDestroy();}} called before exiting
process.
As the process terminates shortly after, removing this line and letting the
system take care of freeing the memory may be an acceptable workaround until
the issue is fixed.
prunsrv crash on service stop
-
Key: DAEMON-336
URL: https://issues.apache.org/jira/browse/DAEMON-336
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.15
Environment: Windows 8.1 with Java 8 64bit, Java mode
Reporter: Volker Berlin
If the service should be stop then it crash. In the event log you can see:
Name der fehlerhaften Anwendung: foo-serverService.exe, Version: 1.0.15.0,
Zeitstempel: 0x51543b9d
Name des fehlerhaften Moduls: ntdll.dll, Version: 6.3.9600.17736,
Zeitstempel: 0x550f4336
Ausnahmecode: 0xc005
Fehleroffset: 0x00035150
ID des fehlerhaften Prozesses: 0x1578
Startzeit der fehlerhaften Anwendung: 0x01d0be119603c23f
Pfad der fehlerhaften Anwendung: C:\Program Files\foo
Server\foo-serverService.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll
Berichtskennung: da5b2537-2a04-11e5-8063-7427ea3e8675
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JXPATH-178) Contention on functions can be reduced
Rico Neubauer created JXPATH-178: Summary: Contention on functions can be reduced Key: JXPATH-178 URL: https://issues.apache.org/jira/browse/JXPATH-178 Project: Commons JXPath Issue Type: Improvement Affects Versions: 1.3 Reporter: Rico Neubauer Priority: Minor Several series of thread dumps showed us that some avoidable synchronization in jxpath causes plenty of blocked threads waiting on the sync block under heavy load. Using concurrent map makes the things better. See this for a proposed fix: https://github.com/seeburger-ag/commons-jxpath/commit/eeb7f30f761a6a89e03c2c1421c09968412659af.diff -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCXML-223) Project Page Contains Broken Link to Eclipse Plugin
[ https://issues.apache.org/jira/browse/SCXML-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14646089#comment-14646089 ] Woonsan Ko commented on SCXML-223: -- I believe the link should be http://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/scxml-eclipse/ instead according to [1]. The old GSoC project home doesn't seem to exist any more. I'll change the link to the SVN source link. [1] http://markmail.org/message/mxadcpp6yqqg4niz Project Page Contains Broken Link to Eclipse Plugin --- Key: SCXML-223 URL: https://issues.apache.org/jira/browse/SCXML-223 Project: Commons SCXML Issue Type: Bug Affects Versions: 0.9 Environment: N/A Reporter: Michael Mast Assignee: Woonsan Ko Priority: Trivial Labels: links The project page http://commons.apache.org/proper/commons-scxml/ contains a link, Commons SCXML - Eclipse with a reference to http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/. The link is bad. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SCXML-223) Project Page Contains Broken Link to Eclipse Plugin
[ https://issues.apache.org/jira/browse/SCXML-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko resolved SCXML-223. -- Resolution: Fixed Fix Version/s: 2.0 Project Page Contains Broken Link to Eclipse Plugin --- Key: SCXML-223 URL: https://issues.apache.org/jira/browse/SCXML-223 Project: Commons SCXML Issue Type: Bug Affects Versions: 0.9 Environment: N/A Reporter: Michael Mast Assignee: Woonsan Ko Priority: Trivial Labels: links Fix For: 2.0 The project page http://commons.apache.org/proper/commons-scxml/ contains a link, Commons SCXML - Eclipse with a reference to http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/. The link is bad. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCXML-223) Project Page Contains Broken Link to Eclipse Plugin
[ https://issues.apache.org/jira/browse/SCXML-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14646111#comment-14646111 ] Woonsan Ko commented on SCXML-223: -- Fixed in site documentation source. Project Page Contains Broken Link to Eclipse Plugin --- Key: SCXML-223 URL: https://issues.apache.org/jira/browse/SCXML-223 Project: Commons SCXML Issue Type: Bug Affects Versions: 0.9 Environment: N/A Reporter: Michael Mast Assignee: Woonsan Ko Priority: Trivial Labels: links Fix For: 2.0 The project page http://commons.apache.org/proper/commons-scxml/ contains a link, Commons SCXML - Eclipse with a reference to http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/. The link is bad. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
