[jira] Created: (COMPRESS-104) The SHA1 files uploaded to the maven repository are not formatted correctly, and make it impossible to use Commons-Compress with maven or ivy
The SHA1 files uploaded to the maven repository are not formatted correctly, and make it impossible to use Commons-Compress with maven or ivy - Key: COMPRESS-104 URL: https://issues.apache.org/jira/browse/COMPRESS-104 Project: Commons Compress Issue Type: Bug Affects Versions: 1.0 Reporter: Kevin Squire Fix For: 1.0 In the maven repository at http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and mirrors), the SHA1 file for each uploaded file looks like this (shown is commons-compress-1.0.pom.sha1): commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 This file is in the wrong format for maven and ivy to parse, causing them not to be able to download and use commons-compress. The file should contain only the sha1 hash, with no spaces, as 325980a09dbbd0c108ece8e7733b462b00e6f2a8 Please fix the sha1 key for all files and re-upload. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-104) The SHA1 files uploaded to the maven repository are not formatted correctly, and make it impossible to use Commons-Compress with maven or ivy
[ https://issues.apache.org/jira/browse/COMPRESS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Squire updated COMPRESS-104: -- Description: In the maven repository at http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and mirrors), the SHA1 file for each uploaded file looks like this (shown is commons-compress-1.0.pom.sha1): commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 This file is in the wrong format for maven and ivy to parse, causing them not to be able to download and use commons-compress. The file should contain only the sha1 hash, with no spaces, as 325980a09dbbd0c108ece8e7733b462b00e6f2a8 Please fix the sha1 key for all files and re-upload. (For reference, see: http://maven.apache.org/guides/mini/guide-central-repository-upload.html) was: In the maven repository at http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and mirrors), the SHA1 file for each uploaded file looks like this (shown is commons-compress-1.0.pom.sha1): commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 This file is in the wrong format for maven and ivy to parse, causing them not to be able to download and use commons-compress. The file should contain only the sha1 hash, with no spaces, as 325980a09dbbd0c108ece8e7733b462b00e6f2a8 Please fix the sha1 key for all files and re-upload. Environment: maven 2.0 ivy 2.1.0 > The SHA1 files uploaded to the maven repository are not formatted correctly, > and make it impossible to use Commons-Compress with maven or ivy > - > > Key: COMPRESS-104 > URL: https://issues.apache.org/jira/browse/COMPRESS-104 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.0 > Environment: maven 2.0 > ivy 2.1.0 >Reporter: Kevin Squire > Fix For: 1.0 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > In the maven repository at > http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and > mirrors), the SHA1 file for each uploaded file looks like this (shown is > commons-compress-1.0.pom.sha1): > commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 > This file is in the wrong format for maven and ivy to parse, causing them not > to be able to download and use commons-compress. > The file should contain only the sha1 hash, with no spaces, as > 325980a09dbbd0c108ece8e7733b462b00e6f2a8 > Please fix the sha1 key for all files and re-upload. > (For reference, see: > http://maven.apache.org/guides/mini/guide-central-repository-upload.html) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-104) The SHA1 files uploaded to the maven repository are not formatted correctly, and make it impossible to use Commons-Compress with maven or ivy
[ https://issues.apache.org/jira/browse/COMPRESS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Squire updated COMPRESS-104: -- Description: In the maven repository at http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and mirrors), the SHA1 file for each uploaded file looks like this (shown is commons-compress-1.0.pom.sha1): commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 This file is in the wrong format for maven and ivy to parse, causing them not to be able to download and use commons-compress. The file should contain only the sha1 hash, with no spaces, as 325980a09dbbd0c108ece8e7733b462b00e6f2a8 Please fix the sha1 key for all files and re-upload. (For reference, see: http://maven.apache.org/guides/mini/guide-central-repository-upload.html) See corresponding maven upload bug report at http://jira.codehaus.org/browse/MAVENUPLOAD-2756 was: In the maven repository at http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and mirrors), the SHA1 file for each uploaded file looks like this (shown is commons-compress-1.0.pom.sha1): commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 This file is in the wrong format for maven and ivy to parse, causing them not to be able to download and use commons-compress. The file should contain only the sha1 hash, with no spaces, as 325980a09dbbd0c108ece8e7733b462b00e6f2a8 Please fix the sha1 key for all files and re-upload. (For reference, see: http://maven.apache.org/guides/mini/guide-central-repository-upload.html) > The SHA1 files uploaded to the maven repository are not formatted correctly, > and make it impossible to use Commons-Compress with maven or ivy > - > > Key: COMPRESS-104 > URL: https://issues.apache.org/jira/browse/COMPRESS-104 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.0 > Environment: maven 2.0 > ivy 2.1.0 >Reporter: Kevin Squire > Fix For: 1.0 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > In the maven repository at > http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and > mirrors), the SHA1 file for each uploaded file looks like this (shown is > commons-compress-1.0.pom.sha1): > commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 > This file is in the wrong format for maven and ivy to parse, causing them not > to be able to download and use commons-compress. > The file should contain only the sha1 hash, with no spaces, as > 325980a09dbbd0c108ece8e7733b462b00e6f2a8 > Please fix the sha1 key for all files and re-upload. > (For reference, see: > http://maven.apache.org/guides/mini/guide-central-repository-upload.html) > See corresponding maven upload bug report at > http://jira.codehaus.org/browse/MAVENUPLOAD-2756 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-104) The SHA1 files uploaded to the maven repository are not formatted correctly, and make it impossible to use Commons-Compress with maven or ivy
[ https://issues.apache.org/jira/browse/COMPRESS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Squire updated COMPRESS-104: -- Maven dependency: org.apache.commons commons-compress 1.0 Ivy dependency: (from: http://mvnrepository.com/artifact/org.apache.commons/commons-compress/1.0) > The SHA1 files uploaded to the maven repository are not formatted correctly, > and make it impossible to use Commons-Compress with maven or ivy > - > > Key: COMPRESS-104 > URL: https://issues.apache.org/jira/browse/COMPRESS-104 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.0 > Environment: maven 2.0 > ivy 2.1.0 >Reporter: Kevin Squire > Fix For: 1.0 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > In the maven repository at > http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ (and > mirrors), the SHA1 file for each uploaded file looks like this (shown is > commons-compress-1.0.pom.sha1): > commons-compress-1.0.pom: 3259 80A0 9DBB D0C1 08EC E8E7 733B 462B 00E6 F2A8 > This file is in the wrong format for maven and ivy to parse, causing them not > to be able to download and use commons-compress. > The file should contain only the sha1 hash, with no spaces, as > 325980a09dbbd0c108ece8e7733b462b00e6f2a8 > Please fix the sha1 key for all files and re-upload. > (For reference, see: > http://maven.apache.org/guides/mini/guide-central-repository-upload.html) > See corresponding maven upload bug report at > http://jira.codehaus.org/browse/MAVENUPLOAD-2756 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (POOL-162) When waiting threads are interrupted, pool can leak capacity
[ https://issues.apache.org/jira/browse/POOL-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-162. -- Resolution: Fixed Fix Version/s: 1.5.5 Thanks for the review Phil. That concurs with my view. > When waiting threads are interrupted, pool can leak capacity > > > Key: POOL-162 > URL: https://issues.apache.org/jira/browse/POOL-162 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4 >Reporter: Phil Steitz > Fix For: 1.5.5 > > > As reported on commons-dev (http://markmail.org/message/aqb23nnzyy2ar3vs), > when waiting threads are interrupted, GOP, GKOP may leak capacity. I do not > yet have a test case to confirm this, but I suspect that the problem reported > by the user is caused by a missing _allocationQueue.remove(latch) before > rethrowing InterruptedException in borrowObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DBCP-327) XAConnection is not closed
XAConnection is not closed -- Key: DBCP-327 URL: https://issues.apache.org/jira/browse/DBCP-327 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Environment: MySQL Connector/J 5.1.12; JOTM 2.1.9; propesed solution is tested with Derby 10.5.3.0_1 as well Reporter: Sergey Vladimirov Priority: Minor Fix For: 1.3.1 After creation of connection in DataSourceXAConnectionFactory::createConnection() the instance of XAConnection is ready to be garbage collected. But in MySQL Connector/J this instance holds the real physiscal connection to MySQL server. Thus, simple test case (in attach) opens 2 connections to server and the first one can be considered as "leak". The possible solution is to close "parent" XA connection as soon as "child" Connection is closed as well. Due to compatibility issues it may be an option for BasicManagerDataSource. However, Derby seems okay with both variants (according to my test cases with JOTM/Hibernate/Derby/DBCP(+-patch)) In the attachment - "manual" test case, since i don't know how to count real MySQL connection number in runtime. When BasicManagedDataSource is used (change it at ~43) we can create breakpoint at line "connection.close();" (~115). According to MySQL Administrator there are 2 connections, but according to pool - only one. If BasicManagedDataSourceXAClose is used - first connection correclty closed. This issue created serious problems in out production system, but, due to existing workaround (replace BasicManagedDataSource and DataSourceXAConnectionFactory) priority is minor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-327) XAConnection is not closed
[ https://issues.apache.org/jira/browse/DBCP-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Vladimirov updated DBCP-327: --- Attachment: MySQL and DBCP.zip > XAConnection is not closed > -- > > Key: DBCP-327 > URL: https://issues.apache.org/jira/browse/DBCP-327 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4 > Environment: MySQL Connector/J 5.1.12; JOTM 2.1.9; propesed solution > is tested with Derby 10.5.3.0_1 as well >Reporter: Sergey Vladimirov >Priority: Minor > Fix For: 1.3.1 > > Attachments: MySQL and DBCP.zip > > Original Estimate: 8h > Remaining Estimate: 8h > > After creation of connection in > DataSourceXAConnectionFactory::createConnection() the instance of > XAConnection is ready to be garbage collected. But in MySQL Connector/J this > instance holds the real physiscal connection to MySQL server. Thus, simple > test case (in attach) opens 2 connections to server and the first one can be > considered as "leak". > The possible solution is to close "parent" XA connection as soon as "child" > Connection is closed as well. Due to compatibility issues it may be an option > for BasicManagerDataSource. However, Derby seems okay with both variants > (according to my test cases with JOTM/Hibernate/Derby/DBCP(+-patch)) > In the attachment - "manual" test case, since i don't know how to count real > MySQL connection number in runtime. When BasicManagedDataSource is used > (change it at ~43) we can create breakpoint at line "connection.close();" > (~115). According to MySQL Administrator there are 2 connections, but > according to pool - only one. If BasicManagedDataSourceXAClose is used - > first connection correclty closed. > This issue created serious problems in out production system, but, due to > existing workaround (replace BasicManagedDataSource and > DataSourceXAConnectionFactory) priority is minor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-242) Pre- and post-processing support for ProxyReader/Writer
Pre- and post-processing support for ProxyReader/Writer --- Key: IO-242 URL: https://issues.apache.org/jira/browse/IO-242 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 2.0 In IO-211 we added protected before/after methods for all read and write operations in ProxyInputStream and ProxyOutputStream. I now have a use case where I need similar functionality also for a Writer, so I've implemented the same feature also for ProxyReader and ProxyWriter. I'll attach the patch for review before committing it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-242) Pre- and post-processing support for ProxyReader/Writer
[ https://issues.apache.org/jira/browse/IO-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated IO-242: - Attachment: IO-242.patch Proposed patch. > Pre- and post-processing support for ProxyReader/Writer > --- > > Key: IO-242 > URL: https://issues.apache.org/jira/browse/IO-242 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 2.0 > > Attachments: IO-242.patch > > > In IO-211 we added protected before/after methods for all read and write > operations in ProxyInputStream and ProxyOutputStream. I now have a use case > where I need similar functionality also for a Writer, so I've implemented the > same feature also for ProxyReader and ProxyWriter. I'll attach the patch for > review before committing it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-103) allow data descriptors to follow STORED entries in ZIP archives being read
[ https://issues.apache.org/jira/browse/COMPRESS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-103. - Resolution: Fixed Fix Version/s: 1.1 fixed with svn revision 925257, I'll add some documentation shortly. Note that the heuristics used are not safe. For example if the stored entry is a ZIP archive itself (think JAR inside a WAR) the stream would now happily extract the inner archive's contents and consider the outer archive finished as soon as the central directory of the inner archive has been encountered. > allow data descriptors to follow STORED entries in ZIP archives being read > -- > > Key: COMPRESS-103 > URL: https://issues.apache.org/jira/browse/COMPRESS-103 > Project: Commons Compress > Issue Type: New Feature >Affects Versions: 1.0 >Reporter: Stefan Bodewig >Priority: Minor > Fix For: 1.1 > > > the document named "Word XPS.xps" found under > http://www.wssdemo.com/XPS/Forms/AllItems.aspx contains at least one STORED > entry that uses a data descriptor after the entries' data to hold size and > CRC information. > The ZipFile class uses information from the central directory and thus knows > the size of the entry and can deal with the archive. ZipArchiveInputStream > currently can't. > One solution would be to read the entry until we hit the signature of a data > descriptor, local file header or the start of the central directory. If we > hit another LFH or the CD then the data descriptor didn't use the signature > (see COMPRESS-101 ) and the last 12 bytes read have already been the data > descriptor. This will certainly not be very efficient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SANDBOX-263) Excel strategy uses wrong separator
[
https://issues.apache.org/jira/browse/SANDBOX-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847419#action_12847419
]
Peter Koszek edited comment on SANDBOX-263 at 3/19/10 4:22 PM:
---
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
if (decimalSeparator == listSeparator) {
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
listSeparator = ';';
}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
was (Author: peko):
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
if (decimalSeparator == listSeparator) {
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
listSeparator = ';';
}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
> Excel strategy uses wrong separator
> ---
>
> Key: SANDBOX-263
> URL: https://issues.apache.org/jira/browse/SANDBOX-263
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Gunnar Wagenknecht
>
> The Excel strategy is defined as follows.
> {code}
> public static CSVStrategy EXCEL_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, false,
> false,
> false, false);
> {code}
> However, when I do a "Save as" in Excel the separator used is actually
> {{';'}}. Thus, parsing the CSV file as suggested in the JavaDoc of
> {{CSVParser}} fails.
> {code}
> String[][] data =
>(new CSVParser(new StringReader("a;b\nc;d"),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> {code}
> Simple test to reproduce:
> {code}
> import java.io.IOException;
> import java.io.StringReader;
> import org.apache.commons.csv.CSVParser;
> import org.apache.commons.csv.CSVStrategy;
> public class CSVExcelStrategyBug {
> public static void main(final String[] args) {
> try {
> System.out.println("Using ;");
> parse("a;b\nc;d");
> System.out.println();
> System.out.println("Using ,");
> parse("a,b\nc,d");
> } catch (final IOException e) {
> e.printStackTrace();
> }
> }
> private static void parse(final String input) throws IOException {
> final String[][] data = (new CSVParser(new StringReader(input),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> for (final String[] row : data) {
> System.out.print("[");
> for (final String cell : row) {
> System.out.print("(" + cell + ")");
> }
> System.out.println("]");
> }
> }
> }
> {code}
> Actual output:
> {noformat}
> Using ;
> [(a;b)]
> [(c;d)]
> Using
[jira] Commented: (SANDBOX-263) Excel strategy uses wrong separator
[
https://issues.apache.org/jira/browse/SANDBOX-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847419#action_12847419
]
Peter Koszek commented on SANDBOX-263:
--
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
if (decimalSeparator == listSeparator) {
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
listSeparator = ';';
}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
> Excel strategy uses wrong separator
> ---
>
> Key: SANDBOX-263
> URL: https://issues.apache.org/jira/browse/SANDBOX-263
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Gunnar Wagenknecht
>
> The Excel strategy is defined as follows.
> {code}
> public static CSVStrategy EXCEL_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, false,
> false,
> false, false);
> {code}
> However, when I do a "Save as" in Excel the separator used is actually
> {{';'}}. Thus, parsing the CSV file as suggested in the JavaDoc of
> {{CSVParser}} fails.
> {code}
> String[][] data =
>(new CSVParser(new StringReader("a;b\nc;d"),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> {code}
> Simple test to reproduce:
> {code}
> import java.io.IOException;
> import java.io.StringReader;
> import org.apache.commons.csv.CSVParser;
> import org.apache.commons.csv.CSVStrategy;
> public class CSVExcelStrategyBug {
> public static void main(final String[] args) {
> try {
> System.out.println("Using ;");
> parse("a;b\nc;d");
> System.out.println();
> System.out.println("Using ,");
> parse("a,b\nc,d");
> } catch (final IOException e) {
> e.printStackTrace();
> }
> }
> private static void parse(final String input) throws IOException {
> final String[][] data = (new CSVParser(new StringReader(input),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> for (final String[] row : data) {
> System.out.print("[");
> for (final String cell : row) {
> System.out.print("(" + cell + ")");
> }
> System.out.println("]");
> }
> }
> }
> {code}
> Actual output:
> {noformat}
> Using ;
> [(a;b)]
> [(c;d)]
> Using ,
> [(a)(b)]
> [(c)(d)]
> {noformat}
> Expected output:
> {noformat}
> Using ;
> [(a)(b)]
> [(c)(d)]
> Using ,
> [(a,b)]
> [(c,d)]
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SANDBOX-263) Excel strategy uses wrong separator
[
https://issues.apache.org/jira/browse/SANDBOX-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847419#action_12847419
]
Peter Koszek edited comment on SANDBOX-263 at 3/19/10 4:23 PM:
---
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
if (decimalSeparator == listSeparator) {
listSeparator = ';';
}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
was (Author: peko):
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
if (decimalSeparator == listSeparator) {
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
listSeparator = ';';
}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
> Excel strategy uses wrong separator
> ---
>
> Key: SANDBOX-263
> URL: https://issues.apache.org/jira/browse/SANDBOX-263
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Gunnar Wagenknecht
>
> The Excel strategy is defined as follows.
> {code}
> public static CSVStrategy EXCEL_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, false,
> false,
> false, false);
> {code}
> However, when I do a "Save as" in Excel the separator used is actually
> {{';'}}. Thus, parsing the CSV file as suggested in the JavaDoc of
> {{CSVParser}} fails.
> {code}
> String[][] data =
>(new CSVParser(new StringReader("a;b\nc;d"),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> {code}
> Simple test to reproduce:
> {code}
> import java.io.IOException;
> import java.io.StringReader;
> import org.apache.commons.csv.CSVParser;
> import org.apache.commons.csv.CSVStrategy;
> public class CSVExcelStrategyBug {
> public static void main(final String[] args) {
> try {
> System.out.println("Using ;");
> parse("a;b\nc;d");
> System.out.println();
> System.out.println("Using ,");
> parse("a,b\nc,d");
> } catch (final IOException e) {
> e.printStackTrace();
> }
> }
> private static void parse(final String input) throws IOException {
> final String[][] data = (new CSVParser(new StringReader(input),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> for (final String[] row : data) {
> System.out.print("[");
> for (final String cell : row) {
> System.out.print("(" + cell + ")");
> }
> System.out.println("]");
> }
> }
> }
> {code}
> Actual output:
> {noformat}
> Using ;
> [(a;b)]
> [(c;d)]
> Using ,
>
[jira] Issue Comment Edited: (SANDBOX-263) Excel strategy uses wrong separator
[
https://issues.apache.org/jira/browse/SANDBOX-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847419#action_12847419
]
Peter Koszek edited comment on SANDBOX-263 at 3/19/10 4:25 PM:
---
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
{code:java}
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
if (decimalSeparator == listSeparator) {
listSeparator = ';';
}
{code}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
was (Author: peko):
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
if (decimalSeparator == listSeparator) {
listSeparator = ';';
}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
> Excel strategy uses wrong separator
> ---
>
> Key: SANDBOX-263
> URL: https://issues.apache.org/jira/browse/SANDBOX-263
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Gunnar Wagenknecht
>
> The Excel strategy is defined as follows.
> {code}
> public static CSVStrategy EXCEL_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, false,
> false,
> false, false);
> {code}
> However, when I do a "Save as" in Excel the separator used is actually
> {{';'}}. Thus, parsing the CSV file as suggested in the JavaDoc of
> {{CSVParser}} fails.
> {code}
> String[][] data =
>(new CSVParser(new StringReader("a;b\nc;d"),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> {code}
> Simple test to reproduce:
> {code}
> import java.io.IOException;
> import java.io.StringReader;
> import org.apache.commons.csv.CSVParser;
> import org.apache.commons.csv.CSVStrategy;
> public class CSVExcelStrategyBug {
> public static void main(final String[] args) {
> try {
> System.out.println("Using ;");
> parse("a;b\nc;d");
> System.out.println();
> System.out.println("Using ,");
> parse("a,b\nc,d");
> } catch (final IOException e) {
> e.printStackTrace();
> }
> }
> private static void parse(final String input) throws IOException {
> final String[][] data = (new CSVParser(new StringReader(input),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> for (final String[] row : data) {
> System.out.print("[");
> for (final String cell : row) {
> System.out.print("(" + cell + ")");
> }
> System.out.println("]");
> }
> }
> }
> {code}
> Actual output:
> {noformat}
> Using ;
> [(a;b)]
> [(c;d)
[jira] Issue Comment Edited: (SANDBOX-263) Excel strategy uses wrong separator
[
https://issues.apache.org/jira/browse/SANDBOX-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847419#action_12847419
]
Peter Koszek edited comment on SANDBOX-263 at 3/19/10 4:27 PM:
---
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
{code:java}// The following idea is based on a comment from
// http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
// If the floating point separator is a comma, use semi-colon to minimize
encapsulation
if (decimalSeparator == listSeparator) {
listSeparator = ';';
}{code}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
was (Author: peko):
RFC 4180 defines commas to be field separators.
The Excel strategy uses the local configuration to identify the separator.
The following approach can help to predict a field separator:
On Windows, read registry key "HKCU\Control Panel\International\sList".
On other systems, try to avoid a collision with the floating point separator
like this:
{code:java}
// The following idea is based on a comment from
//
http://www.experts-exchange.com/Programming/Languages/Q_24113673.html
DecimalFormatSymbols dfs =
DecimalFormatSymbols.getInstance(Locale.getDefault());
char decimalSeparator = dfs.getDecimalSeparator();
char listSeparator = ',';
// If the floating point separator is a comma, use semi-colon to
minimize encapsulation
if (decimalSeparator == listSeparator) {
listSeparator = ';';
}
{code}
CSV should be a standard, Excel is a specific application which uses the CSV
standard in a special way.
I wouldn't expect a CSV framework to be able to simulate Excel exactly.
CSV based formatting works with every arbitrary separator character.
I expect a CSV framework to fully support the standard and to give me the
possibility to configure individual solutions.
> Excel strategy uses wrong separator
> ---
>
> Key: SANDBOX-263
> URL: https://issues.apache.org/jira/browse/SANDBOX-263
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Gunnar Wagenknecht
>
> The Excel strategy is defined as follows.
> {code}
> public static CSVStrategy EXCEL_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, false,
> false,
> false, false);
> {code}
> However, when I do a "Save as" in Excel the separator used is actually
> {{';'}}. Thus, parsing the CSV file as suggested in the JavaDoc of
> {{CSVParser}} fails.
> {code}
> String[][] data =
>(new CSVParser(new StringReader("a;b\nc;d"),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> {code}
> Simple test to reproduce:
> {code}
> import java.io.IOException;
> import java.io.StringReader;
> import org.apache.commons.csv.CSVParser;
> import org.apache.commons.csv.CSVStrategy;
> public class CSVExcelStrategyBug {
> public static void main(final String[] args) {
> try {
> System.out.println("Using ;");
> parse("a;b\nc;d");
> System.out.println();
> System.out.println("Using ,");
> parse("a,b\nc,d");
> } catch (final IOException e) {
> e.printStackTrace();
> }
> }
> private static void parse(final String input) throws IOException {
> final String[][] data = (new CSVParser(new StringReader(input),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> for (final String[] row : data) {
> System.out.print("[");
> for (final String cell : row) {
> System.out.print("(" + cell + ")");
> }
> System.out.println("]");
> }
> }
> }
> {code}
> Actual output:
> {noformat}
> Using ;
> [(a;b)]
> [(c;d)]
> Using ,
> [(a)(b)]
> [(c)(d)]
> {noformat}
> Expected output:
[jira] Created: (MATH-355) State of the art SVD Algorithm
State of the art SVD Algorithm -- Key: MATH-355 URL: https://issues.apache.org/jira/browse/MATH-355 Project: Commons Math Issue Type: Improvement Reporter: Bruce A Johnson There has been a lot of recent activity on the SVD algorithm for Commons Math. The SVD has also been in the news lately because of the development of a new algorithm that is both faster and more accurate than previous algorithms. Given the importance of the SVD in many applications it would be useful to have a Java implementation of this new algorithm in Commons Math. News article on the new algorithm: http://www.siam.org/pdf/news/1696.pdf Manuscripts on the new algorithm: http://www.netlib.org/lapack/lawnspdf/lawn169.pdf http://www.netlib.org/lapack/lawnspdf/lawn170.pdf Implementation in LAPACK 3.2.1 dgesvj.f -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-373) CLONE - MethodUtils is not thread safe because WeakFastHashMap which uses WeakHashMap is not thread-safe.
[ https://issues.apache.org/jira/browse/BEANUTILS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Sunde updated BEANUTILS-373: --- Fix Version/s: (was: 1.8.0) Affects Version/s: (was: 1.7.0) 1.8.2 > CLONE - MethodUtils is not thread safe because WeakFastHashMap which uses > WeakHashMap is not thread-safe. > - > > Key: BEANUTILS-373 > URL: https://issues.apache.org/jira/browse/BEANUTILS-373 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.2 > Environment: Weblogic 9.2 on Linux, but should not be relevant >Reporter: Andrew Sunde >Assignee: Niall Pemberton > > The problem lies in the class org.apache.commons.beanutils.MethodUtils. This > class is keeping a global cache in a non synchronized WeakHashMap. > WeakHashMap is not thread safe and required external synchronization. The > lack of synchronization can cause corruption and the WeakHashMap.get() method > to go into an infinite loop. > Googling "WeakHashMap infinite loop" returns many cases of similar problem > with WeakHashMap. The solution is to decorate the WeakHashMap in a > synchronized Map as described in this thread: > http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg08824.html > The modification to make the MethodUtils cache thread safe is a one line > change. > Before: > private static WeakHashMap cache = new WeakHashMap(); > After: > private static Map cache = Collections.synchronizedMap(new WeakHashMap()); > Example of thread dump > "ExecuteThread: '0' for queue: 'weblogic.kernel.Default'" id=13 idx=0x3c > tid=5905 prio=5 alive, daemon > at > org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:828)[optimized] > at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] > at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] > at > org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] > at > org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] > > "ExecuteThread: '1' for queue: 'weblogic.kernel.Default'" id=14 idx=0x40 > tid=5906 prio=5 alive, daemon > at > org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] > at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] > at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] > at > org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] > at > org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] > ::: > "ExecuteThread: '2' for queue: 'weblogic.kernel.Default'" id=15 idx=0x44 > tid=5907 prio=5 alive, daemon > at > org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] > at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] > at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] > at > org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] > at > org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (BEANUTILS-373) CLONE - MethodUtils is not thread safe because WeakFastHashMap which uses WeakHashMap is not thread-safe.
CLONE - MethodUtils is not thread safe because WeakFastHashMap which uses WeakHashMap is not thread-safe. - Key: BEANUTILS-373 URL: https://issues.apache.org/jira/browse/BEANUTILS-373 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Weblogic 9.2 on Linux, but should not be relevant Reporter: Andrew Sunde Assignee: Niall Pemberton Fix For: 1.8.0 The problem lies in the class org.apache.commons.beanutils.MethodUtils. This class is keeping a global cache in a non synchronized WeakHashMap. WeakHashMap is not thread safe and required external synchronization. The lack of synchronization can cause corruption and the WeakHashMap.get() method to go into an infinite loop. Googling "WeakHashMap infinite loop" returns many cases of similar problem with WeakHashMap. The solution is to decorate the WeakHashMap in a synchronized Map as described in this thread: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg08824.html The modification to make the MethodUtils cache thread safe is a one line change. Before: private static WeakHashMap cache = new WeakHashMap(); After: private static Map cache = Collections.synchronizedMap(new WeakHashMap()); Example of thread dump "ExecuteThread: '0' for queue: 'weblogic.kernel.Default'" id=13 idx=0x3c tid=5905 prio=5 alive, daemon at org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:828)[optimized] at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] at org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] at org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] "ExecuteThread: '1' for queue: 'weblogic.kernel.Default'" id=14 idx=0x40 tid=5906 prio=5 alive, daemon at org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] at org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] at org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] ::: "ExecuteThread: '2' for queue: 'weblogic.kernel.Default'" id=15 idx=0x44 tid=5907 prio=5 alive, daemon at org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] at org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] at org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-373) CLONE - MethodUtils is not thread safe because WeakFastHashMap which uses WeakHashMap is not thread-safe.
[ https://issues.apache.org/jira/browse/BEANUTILS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Sunde updated BEANUTILS-373: --- Description: The problem lies in the class org.apache.commons.beanutils.MethodUtils. This class is keeping a global cache in a non synchronized WeakFastHashMap (which claims to be syncronized). When operating in Fast mode (which is what the WeakFastHashMap is set to after it is created), it then access the underlining WeakHashMap without synchronization. Therefore this can lead to a corruption in the underlining HashMap. See the description of the WeakHashMap javadoc: >From Java Sun: " Like most collection classes, this class is not synchronized. A synchronized WeakHashMap may be constructed using the Collections.synchronizedMap method. The behavior of the WeakHashMap class depends in part upon the actions of the garbage collector, so several familiar (though not required) Map invariants do not hold for this class. Because the garbage collector may discard keys at any time, a WeakHashMap may behave as though an unknown thread is silently removing entries. " Therefore even if you are doing a "get" from the hashmap, there is a chance that you could get a corrupted hashmap because the garbage collector could be changing the hashmap on the fly. This could lead to threads getting stuck in an infinite loop. The modification to make the MethodUtils cache thread safe is a one line change. Before: private static WeakFastHashMap cache = new WeakFastHashMap(); After: private static Map cache = Collections.synchronizedMap(new WeakHashMap()); was: The problem lies in the class org.apache.commons.beanutils.MethodUtils. This class is keeping a global cache in a non synchronized WeakHashMap. WeakHashMap is not thread safe and required external synchronization. The lack of synchronization can cause corruption and the WeakHashMap.get() method to go into an infinite loop. Googling "WeakHashMap infinite loop" returns many cases of similar problem with WeakHashMap. The solution is to decorate the WeakHashMap in a synchronized Map as described in this thread: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg08824.html The modification to make the MethodUtils cache thread safe is a one line change. Before: private static WeakHashMap cache = new WeakHashMap(); After: private static Map cache = Collections.synchronizedMap(new WeakHashMap()); Example of thread dump "ExecuteThread: '0' for queue: 'weblogic.kernel.Default'" id=13 idx=0x3c tid=5905 prio=5 alive, daemon at org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:828)[optimized] at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] at org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] at org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] "ExecuteThread: '1' for queue: 'weblogic.kernel.Default'" id=14 idx=0x40 tid=5906 prio=5 alive, daemon at org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] at org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] at org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] ::: "ExecuteThread: '2' for queue: 'weblogic.kernel.Default'" id=15 idx=0x44 tid=5907 prio=5 alive, daemon at org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] at org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] at org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] > CLONE - MethodUtils is not thread safe because WeakFastHashMap which uses > WeakHashMap is not thread-safe. > - > > Key: BEANUTILS-373 > URL: https://issues.apache.org/jira/browse/BEANUTILS-373 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.2 > Environment: Weblogic 9.2 on Linux, but should not be relevant >Reporter: Andrew Sunde >Assignee: Niall Pemberton > > The problem lies in the class org.apache.commons.beanutils.MethodUtils. This > class is keeping a global cache in a non synchronized WeakFastHashMap (which > claims to be syncronized).
[jira] Commented: (BEANUTILS-318) Many threads are stuck in infinite loops in MethodUtils because static WeakHashMap is not thread safe
[ https://issues.apache.org/jira/browse/BEANUTILS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847517#action_12847517 ] Andrew Sunde commented on BEANUTILS-318: See:https://issues.apache.org/jira/browse/BEANUTILS-373 Similar issue reopened. > Many threads are stuck in infinite loops in MethodUtils because static > WeakHashMap is not thread safe > -- > > Key: BEANUTILS-318 > URL: https://issues.apache.org/jira/browse/BEANUTILS-318 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.7.0 > Environment: Weblogic 9.2 on Linux, but should not be relevant >Reporter: Sylvain Legault >Assignee: Niall Pemberton > Fix For: 1.8.0 > > > The problem lies in the class org.apache.commons.beanutils.MethodUtils. This > class is keeping a global cache in a non synchronized WeakHashMap. > WeakHashMap is not thread safe and required external synchronization. The > lack of synchronization can cause corruption and the WeakHashMap.get() method > to go into an infinite loop. > Googling "WeakHashMap infinite loop" returns many cases of similar problem > with WeakHashMap. The solution is to decorate the WeakHashMap in a > synchronized Map as described in this thread: > http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg08824.html > The modification to make the MethodUtils cache thread safe is a one line > change. > Before: > private static WeakHashMap cache = new WeakHashMap(); > After: > private static Map cache = Collections.synchronizedMap(new WeakHashMap()); > Example of thread dump > "ExecuteThread: '0' for queue: 'weblogic.kernel.Default'" id=13 idx=0x3c > tid=5905 prio=5 alive, daemon > at > org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:828)[optimized] > at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] > at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] > at > org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] > at > org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] > > "ExecuteThread: '1' for queue: 'weblogic.kernel.Default'" id=14 idx=0x40 > tid=5906 prio=5 alive, daemon > at > org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] > at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] > at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] > at > org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] > at > org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] > ::: > "ExecuteThread: '2' for queue: 'weblogic.kernel.Default'" id=15 idx=0x44 > tid=5907 prio=5 alive, daemon > at > org/apache/commons/beanutils/MethodUtils$MethodDescriptor.equals(MethodUtils.java:833)[optimized] > at java/util/WeakHashMap.eq(WeakHashMap.java:254)[inlined] > at java/util/WeakHashMap.get(WeakHashMap.java:345)[optimized] > at > org/apache/commons/beanutils/MethodUtils.getMatchingAccessibleMethod(MethodUtils.java:530)[optimized] > at > org/apache/commons/beanutils/MethodUtils.invokeMethod(MethodUtils.java:209)[inlined] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAEMON-153) [PATCH] Update/fix of Tomcat5.sh script
[PATCH] Update/fix of Tomcat5.sh script --- Key: DAEMON-153 URL: https://issues.apache.org/jira/browse/DAEMON-153 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.1 Environment: Linux (tested on Fedora 8 / EC2) Reporter: Rob Slifka A few changes: - Enable default Tomcat logging behaviour (logs exist and now output to $CATALINA_BASE/logs). - Added 'status' support, to ping a URL and report success if the host was reachable and replied. - Added comments to give people a hint that further customization sourced from catalina.sh may be required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAEMON-153) [PATCH] Update/fix of Tomcat5.sh script
[ https://issues.apache.org/jira/browse/DAEMON-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Slifka updated DAEMON-153: -- Description: A few changes: - Enable default Tomcat logging behaviour (logs exist and now output to $CATALINA_BASE/logs). - Added 'status' support, to ping a URL and report success if the host was reachable and replied. - Added comments to give people a hint that further customization sourced from catalina.sh may be required. - Updated to currently shipping defaults of Java (1.6.0_18) and Tomcat (6.0.26). was: A few changes: - Enable default Tomcat logging behaviour (logs exist and now output to $CATALINA_BASE/logs). - Added 'status' support, to ping a URL and report success if the host was reachable and replied. - Added comments to give people a hint that further customization sourced from catalina.sh may be required. > [PATCH] Update/fix of Tomcat5.sh script > --- > > Key: DAEMON-153 > URL: https://issues.apache.org/jira/browse/DAEMON-153 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.1 > Environment: Linux (tested on Fedora 8 / EC2) >Reporter: Rob Slifka > > A few changes: > - Enable default Tomcat logging behaviour (logs exist and now output to > $CATALINA_BASE/logs). > - Added 'status' support, to ping a URL and report success if the host was > reachable and replied. > - Added comments to give people a hint that further customization sourced > from catalina.sh may be required. > - Updated to currently shipping defaults of Java (1.6.0_18) and Tomcat > (6.0.26). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAEMON-153) [PATCH] Update/fix of Tomcat5.sh script
[ https://issues.apache.org/jira/browse/DAEMON-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Slifka updated DAEMON-153: -- Attachment: DAEMON-153.patch Patch for /src/native/unix/native/Tomcat5.sh > [PATCH] Update/fix of Tomcat5.sh script > --- > > Key: DAEMON-153 > URL: https://issues.apache.org/jira/browse/DAEMON-153 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.1 > Environment: Linux (tested on Fedora 8 / EC2) >Reporter: Rob Slifka > Attachments: DAEMON-153.patch > > > A few changes: > - Enable default Tomcat logging behaviour (logs exist and now output to > $CATALINA_BASE/logs). > - Added 'status' support, to ping a URL and report success if the host was > reachable and replied. > - Added comments to give people a hint that further customization sourced > from catalina.sh may be required. > - Updated to currently shipping defaults of Java (1.6.0_18) and Tomcat > (6.0.26). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-412) Cannot use DatabaseConfiguration if the datasource has autocommit = false
[ https://issues.apache.org/jira/browse/CONFIGURATION-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847571#action_12847571 ] Oliver Heger commented on CONFIGURATION-412: I agree that for autocommit = false manual commits are required. However, I assume we would break applications that use autocommit = true if we always did a commit. Therefore I think the commit mode should be configurable. > Cannot use DatabaseConfiguration if the datasource has autocommit = false > - > > Key: CONFIGURATION-412 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-412 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 1.2 > Environment: Windows / Linux - Database Oracle 11 >Reporter: Stefano Bertini >Priority: Critical > > If using a DatabaseConfiguration object with a datasource that has > *autocommit = false*, the setProperty method fails with a *duplicate key* > error. > This happens because in the setProperty method the two calls > _clearProperty(key)_ and _addProperty(key, value)_ can retrieve two different > connections from the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
