[jira] [Created] (DBCP-380) DelegatingConnection isWrapperFor dies on older JDBC drivers
DelegatingConnection isWrapperFor dies on older JDBC drivers Key: DBCP-380 URL: https://issues.apache.org/jira/browse/DBCP-380 Project: Commons Dbcp Issue Type: Bug Reporter: Balazs Zsoldos The isWrapperFor function simply calls towards to the delegated connection iswrappedfor function instead of checking the result first by hand like in the unwrap function. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-380) DelegatingConnection isWrapperFor dies on older JDBC drivers
[ https://issues.apache.org/jira/browse/DBCP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated DBCP-380: Attachment: DelegatingConnection.java.patch With the tiny patch applied the isWrappedFor function will work well even with JDBC drivers that do not implement this function (e.g. Postgres 9.1 or H2) DelegatingConnection isWrapperFor dies on older JDBC drivers Key: DBCP-380 URL: https://issues.apache.org/jira/browse/DBCP-380 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Balazs Zsoldos Attachments: DelegatingConnection.java.patch Original Estimate: 1h Remaining Estimate: 1h The isWrapperFor function simply calls towards to the delegated connection iswrappedfor function instead of checking the result first by hand like in the unwrap function. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-380) DelegatingConnection isWrapperFor dies on older JDBC drivers
[ https://issues.apache.org/jira/browse/DBCP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated DBCP-380: Affects Version/s: 1.4 DelegatingConnection isWrapperFor dies on older JDBC drivers Key: DBCP-380 URL: https://issues.apache.org/jira/browse/DBCP-380 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Balazs Zsoldos Attachments: DelegatingConnection.java.patch Original Estimate: 1h Remaining Estimate: 1h The isWrapperFor function simply calls towards to the delegated connection iswrappedfor function instead of checking the result first by hand like in the unwrap function. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-356) ManagedDataSource doesn't work with an active transaction in progress on IBM JDK 6+
[ https://issues.apache.org/jira/browse/DBCP-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Zsoldos updated DBCP-356: Attachment: TransactionRegistry.java.patch TransactionRegistry.java.patch I experienced this problem on JDK 1.6_30. I managed to solve it by applying the patch (not hacking equals or any other function just being sure that the same object is used during getting the XAResource from the weakhashmap) ManagedDataSource doesn't work with an active transaction in progress on IBM JDK 6+ --- Key: DBCP-356 URL: https://issues.apache.org/jira/browse/DBCP-356 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: IBM JDK 6 java version 1.6.0 Java(TM) SE Runtime Environment (build pwa6460sr9fp1-20110208_03(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows 7 amd64-64 jvmwa6460sr9-20110203_74623 (JIT enabled, AOT enabled) J9VM - 20110203_074623 JIT - r9_20101028_17488ifx3 GC - 20101027_AA) JCL - 20110203_01 commons-dbcp of version 1.3 / 1.4 Reporter: an envy guest Labels: ibm, xaresource Fix For: 1.3.1, 1.4.1 Attachments: TransactionRegistry.java.patch, TransactionRegistry.java.patch When using IBM JDK 6+ and trying to build commons-dbcp, these tests fail: org.apache.commons.dbcp.managed.TestBasicManagedDataSource org.apache.commons.dbcp.managed.TestManagedDataSourceInTx with error: java.sql.SQLException: Connection does not have a registered XAResource null, UserName=null, null at org.apache.commons.dbcp.managed.TransactionRegistry.getXAResource(TransactionRegistry.java:81) at org.apache.commons.dbcp.managed.TransactionContext.setSharedConnection(TransactionContext.java:88) at org.apache.commons.dbcp.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:131) at org.apache.commons.dbcp.managed.ManagedConnection.init(ManagedConnection.java:55) at org.apache.commons.dbcp.managed.ManagedDataSource.getConnection(ManagedDataSource.java:76) at org.apache.commons.dbcp.managed.TestManagedDataSource.getConnection(TestManagedDataSource.java:53) at org.apache.commons.dbcp.TestConnectionPool.newConnection(TestConnectionPool.java:81) at org.apache.commons.dbcp.managed.TestManagedDataSourceInTx.testMaxActive(TestManagedDataSourceInTx.java:102) When used in conjunction with OpenEJB 3.1.4 examples, the error is the same. The problem disappears when switched to Oracle JDK 1.6.24 (so, all tests are passed and OpenEJB examples are working). I beleive this has something to do with differences in java.lang.ref.WeakReference implementations between IBM and Oracle JDKs, which was already discussed here: http://www.mail-archive.com/dev@commons.apache.org/msg13107.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-493) Incorrect backslash handling in windows environment variable
Incorrect backslash handling in windows environment variable
Key: CONFIGURATION-493
URL: https://issues.apache.org/jira/browse/CONFIGURATION-493
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.8
Reporter: Patrick Vanhuyse
Fix For: 1.7
Windows environment variable :
DFSROOT=\\DFSROOT\BEG
Properties file :
Personnel.jdbc.url = jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=${DFSROOT}/databases/personnel.mdb
Value returned...
...using 1.8 (incorrect) :
jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=\DFSROOT\BEG/databases/personnel.mdb
...using 1.7 (correct) :
jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=\\DFSROOT\BEG/databases/personnel.mdb
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-493) Incorrect backslash handling in windows environment variable
[
https://issues.apache.org/jira/browse/CONFIGURATION-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252648#comment-13252648
]
Oliver Heger commented on CONFIGURATION-493:
The changes you see may be related to CONFIGURATION-418. (This issue also
contains a longer discussion about backslash parsing and its complexity.) It
may be necessary now to escape the backslashes in the value of the variable.
Details can be found in the user's guide at
http://commons.apache.org/configuration/userguide/howto_properties.html#Special_Characters_and_Escaping
Does this solve your problem?
Incorrect backslash handling in windows environment variable
Key: CONFIGURATION-493
URL: https://issues.apache.org/jira/browse/CONFIGURATION-493
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.8
Reporter: Patrick Vanhuyse
Fix For: 1.7
Windows environment variable :
DFSROOT=\\DFSROOT\BEG
Properties file :
Personnel.jdbc.url = jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=${DFSROOT}/databases/personnel.mdb
Value returned...
...using 1.8 (incorrect) :
jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=\DFSROOT\BEG/databases/personnel.mdb
...using 1.7 (correct) :
jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=\\DFSROOT\BEG/databases/personnel.mdb
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-775) In the ListPopulation constructor, the check for a negative populationLimit should occur first.
[ https://issues.apache.org/jira/browse/MATH-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252690#comment-13252690 ] Thomas Neidhart commented on MATH-775: -- Fixed in r1325422. I kept the name getChromosomeList for the getter. In the ListPopulation constructor, the check for a negative populationLimit should occur first. --- Key: MATH-775 URL: https://issues.apache.org/jira/browse/MATH-775 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-775.txt Original Estimate: 1h Remaining Estimate: 1h In the ListPopulation constructor, the check to see whether the populationLimit is positive should occur before the check to see if the number of chromosomes is greater than the populationLimit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-775) In the ListPopulation constructor, the check for a negative populationLimit should occur first.
[ https://issues.apache.org/jira/browse/MATH-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-775. -- Resolution: Fixed In the ListPopulation constructor, the check for a negative populationLimit should occur first. --- Key: MATH-775 URL: https://issues.apache.org/jira/browse/MATH-775 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-775.txt Original Estimate: 1h Remaining Estimate: 1h In the ListPopulation constructor, the check to see whether the populationLimit is positive should occur before the check to see if the number of chromosomes is greater than the populationLimit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-779) ListPopulation Iterator allows you to remove chromosomes from the population.
[ https://issues.apache.org/jira/browse/MATH-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-779. -- Resolution: Fixed Fixed in r1325427 with minor modifications (updated javadoc, use getChromosomes() instead of Collections.unmodifiableList). ListPopulation Iterator allows you to remove chromosomes from the population. - Key: MATH-779 URL: https://issues.apache.org/jira/browse/MATH-779 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-779.txt Original Estimate: 1h Remaining Estimate: 1h Calling the iterator method of ListPopulation returns an iterator of the protected modifiable list. Before returning the iterator we should wrap it in an unmodifiable list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-212) GenericObjectPool allows maxIdle minIdle
[ https://issues.apache.org/jira/browse/POOL-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252756#comment-13252756 ] Mark Thomas commented on POOL-212: -- This can't be fixed in the setters since in a number of scenarios (e.g. when used with DBCP in Tomcat) there is no way to control the order in which the setters are called. GenericObjectPool allows maxIdle minIdle -- Key: POOL-212 URL: https://issues.apache.org/jira/browse/POOL-212 Project: Commons Pool Issue Type: Bug Affects Versions: 1.4 Reporter: Sergejs Melderis Priority: Minor GenericObjectPool allows any values for minIdle and maxIdle, and performs no validation on those values. It allows maxIdle to be less than minIdle, and that creates weird behavior during eviction. After each eviction the Evictor thread calls ensureMinIdle() method which adds objects the pool using addObjectToPool() to make sure there at least minIdle objects in the pool.addObjectToPool() on another hand makes sure that there no more then maxIdle objects in the pool, and immediately destroys the newly created object. In my application we had minIdle configured to 100, but maxIdle wasn't configured and used the default value which is 8, and each eviction would create and destroy a bunch of objects. This issue can be fixed by adding checks in setMinIdle and setMaxIdle, or by adding maxIdle variable to the formula used in calculateDevicit() method. We use version 1.4, but I also tested it on latest 1.6 and observed the same behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-212) GenericObjectPool allows maxIdle minIdle
[
https://issues.apache.org/jira/browse/POOL-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252785#comment-13252785
]
Sergejs Melderis commented on POOL-212:
---
Here is what I did in my application.
@Override
public void setMaxIdle(int maxIdle) {
int minIdle = getMinIdle();
if (maxIdle minIdle) {
super.setMinIdle(maxIdle);
}
super.setMaxIdle(maxIdle);
}
@Override
public void setMinIdle(int minIdle) {
int maxIdle = super.getMaxIdle();
if (maxIdle minIdle) {
super.setMaxIdle(minIdle);
}
super.setMinIdle(minIdle);
}
If client intentions are correct, meaning minIdle = maxIdle the order doesn't
matter.But if client calls setters
with minIdle maxIdle then, yes, it may end up in different configuration
depending on the order of calls.
GenericObjectPool allows maxIdle minIdle
--
Key: POOL-212
URL: https://issues.apache.org/jira/browse/POOL-212
Project: Commons Pool
Issue Type: Bug
Affects Versions: 1.4
Reporter: Sergejs Melderis
Priority: Minor
Fix For: 2.0
GenericObjectPool allows any values for minIdle and maxIdle, and performs no
validation on those values.
It allows maxIdle to be less than minIdle, and that creates weird behavior
during eviction.
After each eviction the Evictor thread calls ensureMinIdle() method which
adds objects the pool using addObjectToPool() to make sure there at least
minIdle objects in the pool.addObjectToPool() on another hand makes sure that
there no more then maxIdle objects in the pool, and immediately destroys the
newly created object.
In my application we had minIdle configured to 100, but maxIdle wasn't
configured and used the default value which is 8, and each eviction would
create and destroy a bunch of objects.
This issue can be fixed by adding checks in setMinIdle and setMaxIdle, or by
adding maxIdle variable to the formula used in calculateDevicit() method.
We use version 1.4, but I also tested it on latest 1.6 and observed the same
behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-212) GenericObjectPool allows maxIdle minIdle
[ https://issues.apache.org/jira/browse/POOL-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated POOL-212: - Fix Version/s: 1.5.8 1.6.1 GenericObjectPool allows maxIdle minIdle -- Key: POOL-212 URL: https://issues.apache.org/jira/browse/POOL-212 Project: Commons Pool Issue Type: Bug Affects Versions: 1.4 Reporter: Sergejs Melderis Priority: Minor Fix For: 1.6.1, 2.0, 1.5.8 GenericObjectPool allows any values for minIdle and maxIdle, and performs no validation on those values. It allows maxIdle to be less than minIdle, and that creates weird behavior during eviction. After each eviction the Evictor thread calls ensureMinIdle() method which adds objects the pool using addObjectToPool() to make sure there at least minIdle objects in the pool.addObjectToPool() on another hand makes sure that there no more then maxIdle objects in the pool, and immediately destroys the newly created object. In my application we had minIdle configured to 100, but maxIdle wasn't configured and used the default value which is 8, and each eviction would create and destroy a bunch of objects. This issue can be fixed by adding checks in setMinIdle and setMaxIdle, or by adding maxIdle variable to the formula used in calculateDevicit() method. We use version 1.4, but I also tested it on latest 1.6 and observed the same behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-212) GenericObjectPool allows maxIdle minIdle
[ https://issues.apache.org/jira/browse/POOL-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-212. -- Resolution: Fixed Fixed in all current development lines. GenericObjectPool allows maxIdle minIdle -- Key: POOL-212 URL: https://issues.apache.org/jira/browse/POOL-212 Project: Commons Pool Issue Type: Bug Affects Versions: 1.4 Reporter: Sergejs Melderis Priority: Minor Fix For: 1.6.1, 2.0, 1.5.8 GenericObjectPool allows any values for minIdle and maxIdle, and performs no validation on those values. It allows maxIdle to be less than minIdle, and that creates weird behavior during eviction. After each eviction the Evictor thread calls ensureMinIdle() method which adds objects the pool using addObjectToPool() to make sure there at least minIdle objects in the pool.addObjectToPool() on another hand makes sure that there no more then maxIdle objects in the pool, and immediately destroys the newly created object. In my application we had minIdle configured to 100, but maxIdle wasn't configured and used the default value which is 8, and each eviction would create and destroy a bunch of objects. This issue can be fixed by adding checks in setMinIdle and setMaxIdle, or by adding maxIdle variable to the formula used in calculateDevicit() method. We use version 1.4, but I also tested it on latest 1.6 and observed the same behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-249) Ref: HADOOP-8273 Update url for commons daemon ppc64 binary tarball
Ref: HADOOP-8273 Update url for commons daemon ppc64 binary tarball --- Key: DAEMON-249 URL: https://issues.apache.org/jira/browse/DAEMON-249 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.2 Environment: IBM PowerPC + IBM Java 6.0 SR10 on RHEL 6.1 Reporter: Kumar Ravi Fix For: 1.0.2 The workaround is to obtain the src. zip file from this URL: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip and to build the above tar file for PPC64 on an IBM Power system. Details: 1. Download this file: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip or the appropriate version for the build. 2. unzip the above downloaded file in a directory called /home/hadoop/commons (or any directory of your choice) 3. cd /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix 4. Run ./configure 5. Build the jsvc binary by typing make 6. Copy the jsvc binary thatr was just built to a new directory called /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 7.Copy the following text files home/hadoop/commons/commons-daemon-1.0.2-native-src directory to the /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build directory - 1. LICENSE.txt 2. NOTICE.txt 3. RELEASE-NOTES.txt 8. cd to the directory home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 9. Create the binary tar file for IBM Power by issuing the following command: tar -czvf commons-daemon-1.0.2-bin-linux-ppc64.tar.gz * 10. Copy the file to an appropriate directory where this can be accessed from the hadoop-common build: 11. For branch-1, edit the build.xml file on the build root to point to the binary tar file that was just built: property name=jsvc.location value=file:///home/hadoop/commons-daemon-1.0.2-bin-linux-ppc64.tar.gz/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-799) DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
DateUtils#parseDate uses default locale instead of US (or trying both default
locale and Locale.English)
Key: LANG-799
URL: https://issues.apache.org/jira/browse/LANG-799
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Reporter: Oliver Kopp
Priority: Minor
Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
Following line throws an ParseException on a German system:
d = DateUtils.parseDate(Wed, 09 Apr 2008 23:55:38 GMT, new String[] {EEE, dd
MMM HH:mm:ss zzz});
Reason: parseDate internally calls SimpleDateFormat without providing a locale.
This causes MMM to be interpreted using the system locale. If the system is
German, the date is trying to be interpreted as German date.
I see following solutions:
A) Always instantiate SimpleDateFormat with Locale.ENGLISH
B) Make two instances of SimpleDateFormat. One without providing a locale and
one with Locale.ENGLISH. Try two parsings
C) Make as many SimpleDateFormat instances as locales are availble iterate
over all instances at the parsing attempts.
D) provide an additional (optional) parameter to parseDate for providing a
Locale
I would prefer B) as this seems the best trade-off between internationalization
and local usage.
What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252960#comment-13252960
]
Sebb commented on LANG-799:
---
There seems no reason to treat Locale.ENGLISH specially here.
I think option D is the best.
i.e. leave the current behaviour as is (and make sure it's documented), but
allow the Locale to be provided.
DateUtils#parseDate uses default locale instead of US (or trying both default
locale and Locale.English)
Key: LANG-799
URL: https://issues.apache.org/jira/browse/LANG-799
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Reporter: Oliver Kopp
Priority: Minor
Labels: features
Original Estimate: 2h
Remaining Estimate: 2h
Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
Following line throws an ParseException on a German system:
d = DateUtils.parseDate(Wed, 09 Apr 2008 23:55:38 GMT, new String[] {EEE,
dd MMM HH:mm:ss zzz});
Reason: parseDate internally calls SimpleDateFormat without providing a
locale. This causes MMM to be interpreted using the system locale. If the
system is German, the date is trying to be interpreted as German date.
I see following solutions:
A) Always instantiate SimpleDateFormat with Locale.ENGLISH
B) Make two instances of SimpleDateFormat. One without providing a locale
and one with Locale.ENGLISH. Try two parsings
C) Make as many SimpleDateFormat instances as locales are availble iterate
over all instances at the parsing attempts.
D) provide an additional (optional) parameter to parseDate for providing a
Locale
I would prefer B) as this seems the best trade-off between
internationalization and local usage.
What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-249) Ref: HADOOP-8273 Update url for commons daemon ppc64 binary tarball
[ https://issues.apache.org/jira/browse/DAEMON-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved DAEMON-249. - Resolution: Won't Fix Fix Version/s: (was: 1.0.2) Version 1.0.2 is very much out of date; the current release is 1.0.10. In any case, it's not possible to update existing releases. Ref: HADOOP-8273 Update url for commons daemon ppc64 binary tarball --- Key: DAEMON-249 URL: https://issues.apache.org/jira/browse/DAEMON-249 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.2 Environment: IBM PowerPC + IBM Java 6.0 SR10 on RHEL 6.1 Reporter: Kumar Ravi The workaround is to obtain the src. zip file from this URL: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip and to build the above tar file for PPC64 on an IBM Power system. Details: 1. Download this file: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip or the appropriate version for the build. 2. unzip the above downloaded file in a directory called /home/hadoop/commons (or any directory of your choice) 3. cd /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix 4. Run ./configure 5. Build the jsvc binary by typing make 6. Copy the jsvc binary thatr was just built to a new directory called /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 7.Copy the following text files home/hadoop/commons/commons-daemon-1.0.2-native-src directory to the /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build directory - 1. LICENSE.txt 2. NOTICE.txt 3. RELEASE-NOTES.txt 8. cd to the directory home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 9. Create the binary tar file for IBM Power by issuing the following command: tar -czvf commons-daemon-1.0.2-bin-linux-ppc64.tar.gz * 10. Copy the file to an appropriate directory where this can be accessed from the hadoop-common build: 11. For branch-1, edit the build.xml file on the build root to point to the binary tar file that was just built: property name=jsvc.location value=file:///home/hadoop/commons-daemon-1.0.2-bin-linux-ppc64.tar.gz/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
