[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12446203 ] Simon Kitching commented on DIGESTER-109: - I'd be keener to implement support for null classloaders if I could think of a sane reason for putting libraries on -Xbootclasspath... FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: http://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r469857 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/
Author: niallp
Date: Wed Nov 1 03:18:01 2006
New Revision: 469857
URL: http://svn.apache.org/viewvc?view=revrev=469857
Log:
Javadoc changes only
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/DecimalLocaleConverter.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/LongLocaleConverter.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlDateLocaleConverter.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlTimeLocaleConverter.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlTimestampLocaleConverter.java
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/StringLocaleConverter.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/DecimalLocaleConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/DecimalLocaleConverter.java?view=diffrev=469857r1=469856r2=469857
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/DecimalLocaleConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/DecimalLocaleConverter.java
Wed Nov 1 03:18:01 2006
@@ -221,8 +221,8 @@
* @param value The input object to be converted
* @param pattern The pattern is used for the convertion
*
- * @exception ConversionException if conversion cannot be performed
- * successfully
+ * @exception org.apache.commons.beanutils.ConversionException if
conversion
+ * cannot be performed successfully
*/
protected Object parse(Object value, String pattern) throws ParseException
{
// Note that despite the ambiguous getInstance name, and despite the
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/LongLocaleConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/LongLocaleConverter.java?view=diffrev=469857r1=469856r2=469857
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/LongLocaleConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/LongLocaleConverter.java
Wed Nov 1 03:18:01 2006
@@ -206,8 +206,8 @@
* @param value The input object to be converted
* @param pattern The pattern is used for the convertion
*
- * @exception ConversionException if conversion cannot be performed
- * successfully
+ * @exception org.apache.commons.beanutils.ConversionException if
conversion
+ * cannot be performed successfully
*/
protected Object parse(Object value, String pattern) throws ParseException
{
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlDateLocaleConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlDateLocaleConverter.java?view=diffrev=469857r1=469856r2=469857
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlDateLocaleConverter.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlDateLocaleConverter.java
Wed Nov 1 03:18:01 2006
@@ -209,8 +209,8 @@
* @param value The input object to be converted
* @param pattern The pattern is used for the convertion
*
- * @exception ConversionException if conversion cannot be performed
- * successfully
+ * @exception org.apache.commons.beanutils.ConversionException if
conversion
+ * cannot be performed successfully
*/
protected Object parse(Object value, String pattern) throws ParseException
{
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlTimeLocaleConverter.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/SqlTimeLocaleConverter.java?view=diffrev=469857r1=469856r2=469857
==
---
svn commit: r469863 [2/2] - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=diffrev=469863r1=469862r2=469863
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java
Wed Nov 1 03:26:22 2006
@@ -97,7 +97,11 @@
public class PropertyUtilsBean {
// - Class Methods
-
+
+/**
+ * Return the PropertyUtils bean instance.
+ * @return The PropertyUtils bean instance
+ */
protected static PropertyUtilsBean getInstance() {
return BeanUtilsBean.getInstance().getPropertyUtils();
}
@@ -250,6 +254,7 @@
* pstrongFIXME/strong - Does not account for mapped properties./p
*
* @param bean Bean whose properties are to be extracted
+ * @return The set of properties for the bean
*
* @exception IllegalAccessException if the caller does not have
* access to the property accessor method
@@ -299,6 +304,7 @@
* @param bean Bean whose property is to be extracted
* @param name codepropertyname[index]/code of the property value
* to be extracted
+ * @return the indexed property value
*
* @exception ArrayIndexOutOfBoundsException if the specified index
* is outside the valid range for the underlying array
@@ -354,6 +360,7 @@
* @param bean Bean whose property is to be extracted
* @param name Simple property name of the property value to be extracted
* @param index Index of the property value to be extracted
+ * @return the indexed property value
*
* @exception ArrayIndexOutOfBoundsException if the specified index
* is outside the valid range for the underlying array
@@ -453,6 +460,7 @@
* @param bean Bean whose property is to be extracted
* @param name codepropertyname(key)/code of the property value
* to be extracted
+ * @return the mapped property value
*
* @exception IllegalAccessException if the caller does not have
* access to the property accessor method
@@ -497,6 +505,7 @@
* @param bean Bean whose property is to be extracted
* @param name Mapped property name of the property value to be extracted
* @param key Key of the property value to be extracted
+ * @return the mapped property value
*
* @exception IllegalAccessException if the caller does not have
* access to the property accessor method
@@ -577,6 +586,7 @@
* pstrongFIXME/strong - Does not work with DynaBeans./p
*
* @param beanClass Bean class to be introspected
+ * @return the mapped property descriptors
* @deprecated This method should not be exposed
*/
public FastHashMap getMappedPropertyDescriptors(Class beanClass) {
@@ -597,6 +607,7 @@
* pstrongFIXME/strong - Does not work with DynaBeans./p
*
* @param bean Bean to be introspected
+ * @return the mapped property descriptors
* @deprecated This method should not be exposed
*/
public FastHashMap getMappedPropertyDescriptors(Object bean) {
@@ -615,6 +626,7 @@
*
* @param bean Bean whose property is to be extracted
* @param name Possibly nested name of the property to be extracted
+ * @return the nested property value
*
* @exception IllegalAccessException if the caller does not have
* access to the property accessor method
@@ -696,6 +708,10 @@
* This method is called by getNestedProperty and setNestedProperty to
* define what it means to get a property from an object which implements
* Map. See setPropertyOfMapBean for more information.
+ *
+ * @param bean Map bean
+ * @param propertyName The property name
+ * @return the property value
*
* @throws IllegalArgumentException when the propertyName is regarded as
* being invalid.
@@ -737,6 +753,7 @@
* @param bean Bean whose property is to be extracted
* @param name Possibly indexed and/or nested name of the property
* to be extracted
+ * @return the property value
*
* @exception IllegalAccessException if the caller does not have
* access to the property accessor method
@@ -769,6 +786,7 @@
* @param bean Bean for which a property descriptor is requested
* @param name Possibly indexed and/or nested name of the property for
* which a property descriptor is requested
+ * @return the property descriptor
*
* @exception IllegalAccessException if the caller does not have
* access to the property accessor method
@@ -914,6
[jira] Commented: (VALIDATOR-206) NullPointerException in ValidatorAction class when we start application in Unix
[ http://issues.apache.org/jira/browse/VALIDATOR-206?page=comments#action_12446212 ] Niall Pemberton commented on VALIDATOR-206: --- Validator has a feature to tell it to use the context class loader - can you see if that resolves your issue: On the Validator class use the setUseContextClassLoader(true) method Niall NullPointerException in ValidatorAction class when we start application in Unix --- Key: VALIDATOR-206 URL: http://issues.apache.org/jira/browse/VALIDATOR-206 Project: Commons Validator Issue Type: Bug Components: Framework Affects Versions: 1.3.0 Release, 1.2.0 Release Environment: Unix Reporter: Anna Komaristaia When I start the application in Unix, there is the NullPointerException going from the next methods in ValidatorAction class - loadValidationClass( ClassLoader ) - loadParameterClasses( ClassLoader ) ClassLoadet parameter is null. This is the printout from Unix console: ERROR validator.ValidatorAction - Unhandled exception thrown during validation: null java.lang.NullPointerException at org.apache.commons.validator.ValidatorAction.loadValidationClass(ValidatorAction.java:623) at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:531) at org.apache.commons.validator.Field.validateForRule(Field.java:766) at org.apache.commons.validator.Field.validate(Field.java:846) at org.apache.commons.validator.Form.validate(Form.java:290) ... java.lang.NullPointerException at org.apache.commons.validator.ValidatorAction.loadParameterClasses(ValidatorAction.java:652) at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:532) at org.apache.commons.validator.Field.validateForRule(Field.java:766) at org.apache.commons.validator.Field.validate(Field.java:846) at org.apache.commons.validator.Form.validate(Form.java:290) at org.apache.commons.validator.Validator.validate(Validator.java:354) ... I recompiled the commons-validator jar with the next change and it's working fine in PC and Unix: if( loader == null ) this.validationClass = Class.forName(this.classname); else this.validationClass = loader.loadClass(this.classname); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-98) VFS causes deadlocks or is not thread-safe
[ http://issues.apache.org/jira/browse/VFS-98?page=comments#action_12446226 ] Juha-Matti Toppinen commented on VFS-98: Thank you for the quick response. Creating a per-thread FileSystemManager is not very comfortable, because I have many, many classes that are shared between threads, and they all have a private main FileObject it uses to store information etc. They also are maintained using Multiton -like pattern, so that only one shared instance is created per FileObject, using FileObject.toString() as object pool key. Redesigning all these classes to use per-thread FileSystemManagers as well as per-thread FileObjects would be quite a lot of work. I checked out and built VFS from SVN (nightly builds directory was empty) to get the latest version, and still had the same problem. I attach both a thread dump (thanks for the helpful link) as well as a report generated by jstack. I tried both with the default VFS.getManager() and creating a custom DefaultFileSystemManager that uses SynchronizedFileObject decorator. Only difference was that with SynchronizedFileObject decorator the deadlock situation occurred more quickly. VFS causes deadlocks or is not thread-safe -- Key: VFS-98 URL: http://issues.apache.org/jira/browse/VFS-98 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Environment: jdk1.5.0_07 / Linux Reporter: Juha-Matti Toppinen Assigned To: Mario Ivankovits Attachments: vfs.dead.jstack.txt, vfs.dead.threaddump.synchronizedfileobject.txt, vfs.dead.threaddump.txt Newer versions of VFS seems to be unusable in multithreading environments, causing a deadlock of some kind. This causes my Java web server application to completely hang when there is many concurrent connections. My application uses a single FileSystemManager instance, and makes quite heavy use of VFS; opening many files from many threads simultaneously. I have tried, without success different workarounds based on some mailing list threads: - Using both NullReferenceFilesCache and the default SoftReferenceFilesCache. (SoftReferenceFilesCache seemed to sometimes cause some additional thread-related exceptions under heavy load, but propably unrelated to this issue) - Using the new SynchorizedFileObjectDecorator also did not help. On the contrary, it seemed to trigger the deadlock more easily. The version I have problems with is a nightly build: commons-vfs-20060831 The older version commons-vfs-20060115 works beautifully, but I would like to use newer version because I want to be able to use FileObject.refresh() to reset the internal state of files (specially, to get a fresh list of children). I hope the threading issues are going to be resolved in near future, and I am willing to help in any way. I do not have very deep experience about multithreading applications, so I wasn't able to get more close to the roots of the issue. Feel free to ask for more information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbutils] Outstanding issues against dbutils-1.1 as of Nov. 1, 2006
Apologies if this is a duplicate: I sent it in to the list earlier but didn't see it appear. There are four Major issues listed against the 1.1 release of [dbutils]. DBUTILS-1 BeanListHandler and BeanHandler fail to support java.sql.Date() The reporter of the bug supplied code to fix the issue. DBUTILS-32 Tests fail to build under 1.6, and warning while compiling source Alan Canon has supplied code in a JIRA comment to eliminate the compiler errors and warnings under Java 6 SDK. DBUTILS-3 Setting bean properties fails silently Alan Canon has supplied code in a JIRA comment to throw a SQLException when the described condition occurs, according to a recommendation made in a previous comment. DBUTILS-31 fillStatement setNull bug with the Derby JDBC driver Code is present in the bug description, however it appears to have been prepared to work against JDBC 3.0. The suggested patch uses java.sql.ParameterMetaData, not present in JDK 1.4.2. Comments on the bug suggest testing the JDBCMajor number to see what the JDBC version is, and acting accordingly. Additionally, another comment states the code would need to fall back to the JDBC 2.1 specification if the Oracle JDBC driver throws an exception. Francis Townsend and Henri Yandell posted comments recommending that this solution be put off for a future release. In addition, there are three Minor issues listed: DBUTILS-17 ScalarHandler subclasses that return Integers and Longs Sample implmentations are provided in the JIRA report. This also addresses issues present in DBUTILS-27. DBUTILS-27 QueryRunner.count(String, ...) methods for SELECT COUNT(...) sql This one is an improvement with diffs provided. Henri Yandell recommended it for the 1.1 release in a comment. DBUTILS-17 ResultSetRowProcessor abstract handler and some classes rework There are patches provided. This request for improvement is two years old. Henri Yandell posted a comment earlier this year that says FIX or WONTFIX for 1.1. These seven issues are all that are scheduled against the 1.1 release of dbutils. Four other unscheduled issues are not described in this message. -- Alan Canon
[jira] Updated: (DBUTILS-32) Tests fail to build under 1.6, and warning while compiling source
[ http://issues.apache.org/jira/browse/DBUTILS-32?page=all ]
Alan B. Canon updated DBUTILS-32:
-
Attachment: patch.txt
Patch is attached resolving issues as described in previous comments.
Tests fail to build under 1.6, and warning while compiling source
-
Key: DBUTILS-32
URL: http://issues.apache.org/jira/browse/DBUTILS-32
Project: Commons DbUtils
Issue Type: Bug
Reporter: Henri Yandell
Fix For: 1.1
Attachments: patch.txt
test:compile:
[javac] Compiling 20 source files to
/home/hen/apache/jakarta/commons-proper/dbutils/target/test-classes
/home/hen/apache/jakarta/commons-proper/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java:841:
org.apache.commons.dbutils.wrappers.SqlNullCheckedResultSetMockBlob is not
abstract and does not override abstract method getBinaryStream(long,long) in
java.sql.Blob
class SqlNullCheckedResultSetMockBlob implements Blob {
^
/home/hen/apache/jakarta/commons-proper/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java:882:
org.apache.commons.dbutils.wrappers.SqlNullCheckedResultSetMockClob is not
abstract and does not override abstract method getCharacterStream(long,long)
in java.sql.Clob
class SqlNullCheckedResultSetMockClob implements Clob {
and warning of:
[javac] Compiling 20 source files to
/home/hen/apache/jakarta/commons-proper/dbutils/target/classes
/home/hen/apache/jakarta/commons-proper/dbutils/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java:372:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
? nullMethod.invoke(this, null)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] Propose 0.8 Release
Looks good Robert.. Mvgr, Martin robert burrell donkin wrote: i've taken a good look at the code base, tidied up some legal issues and some bad speiling. looks good. so, i've created a minimal release plan here: http://wiki.apache.org/jakarta-commons/Betwixt/0.8ReleasePlan. unless there are any other volunteers, i'll act as release managers. sound ok? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBUTILS-32) Tests fail to build under 1.6, and warning while compiling source
[ http://issues.apache.org/jira/browse/DBUTILS-32?page=all ]
Alan B. Canon updated DBUTILS-32:
-
Attachment: patch-DBUTILS-32.txt
Sorry, the previous patch addressed two separate issues. The present attachment
resolves only DBUTILS-32 (the present issue)
Tests fail to build under 1.6, and warning while compiling source
-
Key: DBUTILS-32
URL: http://issues.apache.org/jira/browse/DBUTILS-32
Project: Commons DbUtils
Issue Type: Bug
Reporter: Henri Yandell
Fix For: 1.1
Attachments: patch-DBUTILS-32.txt, patch.txt
test:compile:
[javac] Compiling 20 source files to
/home/hen/apache/jakarta/commons-proper/dbutils/target/test-classes
/home/hen/apache/jakarta/commons-proper/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java:841:
org.apache.commons.dbutils.wrappers.SqlNullCheckedResultSetMockBlob is not
abstract and does not override abstract method getBinaryStream(long,long) in
java.sql.Blob
class SqlNullCheckedResultSetMockBlob implements Blob {
^
/home/hen/apache/jakarta/commons-proper/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java:882:
org.apache.commons.dbutils.wrappers.SqlNullCheckedResultSetMockClob is not
abstract and does not override abstract method getCharacterStream(long,long)
in java.sql.Clob
class SqlNullCheckedResultSetMockClob implements Clob {
and warning of:
[javac] Compiling 20 source files to
/home/hen/apache/jakarta/commons-proper/dbutils/target/classes
/home/hen/apache/jakarta/commons-proper/dbutils/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java:372:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
? nullMethod.invoke(this, null)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBUTILS-3) [dbutils] Setting bean properties fails silently
[ http://issues.apache.org/jira/browse/DBUTILS-3?page=all ] Alan B. Canon updated DBUTILS-3: Attachment: patch-DBUTILS-3.txt Patch to resolve issue as described in previous comments. [dbutils] Setting bean properties fails silently Key: DBUTILS-3 URL: http://issues.apache.org/jira/browse/DBUTILS-3 Project: Commons DbUtils Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Tim Bailen Fix For: 1.1 Attachments: patch-DBUTILS-3.txt I had a property in my bean that wasn't being set by BeanHandler. No matter the value of the matching field name in the database, the value in the bean would always come back as 0. I traced the culprit to BasicRowProcessor.callSetter(), which calls the setter method on the bean corresponding to the same field name in the database. Before it attempts to call the setter, it checks to make sure that the type of the value retrieved from the database is compatible with the type of the bean. This behavior is fair enough, but if the types are determined to be incompatible, DBUtils essentially fails silently. That is, it does not call the setter and it does nothing to inform the developer that this is what happened. This was frustrating for me because I had a field that was type int in my bean and type long in the database, but I didn't realize why it wasn't being set until I stepped through the code. POSSIBLE RESOLUTIONS 1. Start a FAQ for DBUtils and mention that a bean's property will not be initialized if its type is incompatible with the corresponding field in the database 2. Log some message to this effect when it occurs (I don't believe DBUtils has any logging, so this probably isn't viable) 3. Throw an exception when this case occurs. Better that the program fail obviously and with some information about what happened rather than return a bean in an invalid state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBUTILS-1) [dbutils] BeanListHandler and BeanHandler fail to support java.sql.Date()
[ http://issues.apache.org/jira/browse/DBUTILS-1?page=all ]
Alan B. Canon updated DBUTILS-1:
Attachment: patch-DBUTILS-1-and-3.txt
This patch also addresses DBUTILS-3. It may not work if the patch recently
attached to that issue has already been applied to source.
[dbutils] BeanListHandler and BeanHandler fail to support java.sql.Date()
-
Key: DBUTILS-1
URL: http://issues.apache.org/jira/browse/DBUTILS-1
Project: Commons DbUtils
Issue Type: Bug
Environment: Operating System: Windows 2000
Platform: PC
Reporter: Xinyi-Huang
Fix For: 1.1
Attachments: patch-DBUTILS-1-and-3.txt
BeanListHandler or BeanHandler fail to support the java.sql.Date type when
read from database.
I just add some codes to callSetter the method callSetter of BeanProcessor as
--
else if(params[0].getName().equals(java.sql.Date)){
value = (value==null)?null:new java.sql.Date
(((java.util.Date)value).getTime());
setter.invoke(target, new Object[] {value});
--
org.apache.commons.dbutils.BeanProcessor
private void callSetter(Object target, PropertyDescriptor prop, Object value)
throws SQLException {
Method setter = prop.getWriteMethod();
if (setter == null) {
return;
}
Class[] params = setter.getParameterTypes();
try {
// Don't call setter if the value object isn't the right type
if (this.isCompatibleType(value, params[0])) {
setter.invoke(target, new Object[] { value });
}else if(params[0].getName().equals(java.sql.Date)){
value = (value==null)?null:new java.sql.Date
(((java.util.Date)value).getTime());
setter.invoke(target, new Object[] {value});
}
} catch (IllegalArgumentException e) {
throw new SQLException(
Cannot set + prop.getName() + : + e.getMessage());
} catch (IllegalAccessException e) {
throw new SQLException(
Cannot set + prop.getName() + : + e.getMessage());
} catch (InvocationTargetException e) {
throw new SQLException(
Cannot set + prop.getName() + : + e.getMessage());
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBUTILS-3) [dbutils] Setting bean properties fails silently
[ http://issues.apache.org/jira/browse/DBUTILS-3?page=comments#action_12446287 ] Alan B. Canon commented on DBUTILS-3: - I supplied a patch for DBUTILS-1 which also fixes the present issue. It would be best to apply the patch for DBUTILS-1, and not the patch submitted above. [dbutils] Setting bean properties fails silently Key: DBUTILS-3 URL: http://issues.apache.org/jira/browse/DBUTILS-3 Project: Commons DbUtils Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Tim Bailen Fix For: 1.1 Attachments: patch-DBUTILS-3.txt I had a property in my bean that wasn't being set by BeanHandler. No matter the value of the matching field name in the database, the value in the bean would always come back as 0. I traced the culprit to BasicRowProcessor.callSetter(), which calls the setter method on the bean corresponding to the same field name in the database. Before it attempts to call the setter, it checks to make sure that the type of the value retrieved from the database is compatible with the type of the bean. This behavior is fair enough, but if the types are determined to be incompatible, DBUtils essentially fails silently. That is, it does not call the setter and it does nothing to inform the developer that this is what happened. This was frustrating for me because I had a field that was type int in my bean and type long in the database, but I didn't realize why it wasn't being set until I stepped through the code. POSSIBLE RESOLUTIONS 1. Start a FAQ for DBUtils and mention that a bean's property will not be initialized if its type is incompatible with the corresponding field in the database 2. Log some message to this effect when it occurs (I don't believe DBUtils has any logging, so this probably isn't viable) 3. Throw an exception when this case occurs. Better that the program fail obviously and with some information about what happened rather than return a bean in an invalid state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] JCL dependency versions
Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JCL dependency versions
-1 - we don't have the parallel release cycle to pull this off. We'll all be stuck because commons doodah has no reason to upgrade and no one active on it. I'm +1 to upgrading all the dependencies though - I wouldn't even think it needs a vote. Just dig in and upgrade all the dependencies you see (on all 3 build systems) and check they still compile. Then check it in. That's why I'm miffed about the commons-parent thing - it's broken the components because the job hasn't been finished by updating the pom.xmls. I know it's probably because it can be easy to view Commons Xxxx as Fred's baby, but it's one big codebase and you can go dive in and do cross-commons things that seem to be common sense and apologise later - or raise an all thread to discuss (kind of like below) and then dive in. Hen On 11/1/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r470003 - in /jakarta/commons/proper/dbutils/trunk/src: java/org/apache/commons/dbutils/ java/org/apache/commons/dbutils/wrappers/ test/org/apache/commons/dbutils/wrappers/
Author: bayard
Date: Wed Nov 1 09:33:50 2006
New Revision: 470003
URL: http://svn.apache.org/viewvc?view=revrev=470003
Log:
Applying Alan Canon's patch for DBUTILS-32
Modified:
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/BeanProcessor.java
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java
jakarta/commons/proper/dbutils/trunk/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java
Modified:
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/BeanProcessor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/BeanProcessor.java?view=diffrev=470003r1=470002r2=470003
==
---
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/BeanProcessor.java
(original)
+++
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/BeanProcessor.java
Wed Nov 1 09:33:50 2006
@@ -225,6 +225,9 @@
// Don't call setter if the value object isn't the right type
if (this.isCompatibleType(value, params[0])) {
setter.invoke(target, new Object[] { value });
+} else {
+ throw new SQLException(
+ Cannot set + prop.getName() + : incompatible types.);
}
} catch (IllegalArgumentException e) {
Modified:
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java?view=diffrev=470003r1=470002r2=470003
==
---
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java
(original)
+++
jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java
Wed Nov 1 09:33:50 2006
@@ -369,7 +369,7 @@
// Check nullMethod != null first so that we don't call wasNull()
// before a true getter method was invoked on the ResultSet.
return (nullMethod != null this.rs.wasNull())
-? nullMethod.invoke(this, null)
+? nullMethod.invoke(this, (Object[]) null)
: result;
}
Modified:
jakarta/commons/proper/dbutils/trunk/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbutils/trunk/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java?view=diffrev=470003r1=470002r2=470003
==
---
jakarta/commons/proper/dbutils/trunk/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java
(original)
+++
jakarta/commons/proper/dbutils/trunk/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java
Wed Nov 1 09:33:50 2006
@@ -877,6 +877,14 @@
return null;
}
+public void free() throws SQLException {
+
+}
+
+public InputStream getBinaryStream(long pos, long length) throws
SQLException {
+ return null;
+}
+
}
class SqlNullCheckedResultSetMockClob implements Clob {
@@ -924,6 +932,14 @@
public int setString(long pos, String str, int offset, int len)
throws SQLException {
return 0;
+}
+
+public void free() throws SQLException {
+
+}
+
+public Reader getCharacterStream(long pos, long length) throws
SQLException {
+ return null;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBUTILS-32) Tests fail to build under 1.6, and warning while compiling source
[ http://issues.apache.org/jira/browse/DBUTILS-32?page=all ]
Henri Yandell resolved DBUTILS-32.
--
Resolution: Fixed
Thanks Alan.
svn ci -m Applying Alan Canon's patch for DBUTILS-32
Sendingsrc/java/org/apache/commons/dbutils/BeanProcessor.java
Sending
src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java
Sending
src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java
Transmitting file data ...
Committed revision 470003.
I've also tested it under 1.6 on a Linux box (back to hating the Mac for not
having 1.6).
Btw, good naming for patches would be 'DBUTILS-32.patch'. Not sure about the
repeat though :)
Tests fail to build under 1.6, and warning while compiling source
-
Key: DBUTILS-32
URL: http://issues.apache.org/jira/browse/DBUTILS-32
Project: Commons DbUtils
Issue Type: Bug
Reporter: Henri Yandell
Fix For: 1.1
Attachments: patch-DBUTILS-32.txt, patch.txt
test:compile:
[javac] Compiling 20 source files to
/home/hen/apache/jakarta/commons-proper/dbutils/target/test-classes
/home/hen/apache/jakarta/commons-proper/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java:841:
org.apache.commons.dbutils.wrappers.SqlNullCheckedResultSetMockBlob is not
abstract and does not override abstract method getBinaryStream(long,long) in
java.sql.Blob
class SqlNullCheckedResultSetMockBlob implements Blob {
^
/home/hen/apache/jakarta/commons-proper/dbutils/src/test/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSetTest.java:882:
org.apache.commons.dbutils.wrappers.SqlNullCheckedResultSetMockClob is not
abstract and does not override abstract method getCharacterStream(long,long)
in java.sql.Clob
class SqlNullCheckedResultSetMockClob implements Clob {
and warning of:
[javac] Compiling 20 source files to
/home/hen/apache/jakarta/commons-proper/dbutils/target/classes
/home/hen/apache/jakarta/commons-proper/dbutils/src/java/org/apache/commons/dbutils/wrappers/SqlNullCheckedResultSet.java:372:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
? nullMethod.invoke(this, null)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JCL dependency versions
On 11/1/06, Henri Yandell [EMAIL PROTECTED] wrote: -1 - we don't have the parallel release cycle to pull this off. We'll all be stuck because commons doodah has no reason to upgrade and no one active on it. snip/ Correct, we can't help doodah. But this vote is really not about a parallel release cycle, or any assumptions thereof. Its about persuading doodah to upgrade JCL, whenever doodah++ is released (and if it is never released again, the question doesn't arise). I'm +1 to upgrading all the dependencies though - I wouldn't even think it needs a vote. Just dig in and upgrade all the dependencies you see (on all 3 build systems) and check they still compile. Then check it in. snap/ Components should have communal responsibility. That is the only thing that is going to scale. One person cannot save planetcommons. We cannot require one individual to go through all (80-odd components, lets say 50 have JCL dep, and 3 builds systems) to upgrade it. Well, I guess we can require it, its just unlikely to ever happen that way, which puts users at a disadvantage as this won't get done. That's why I'm miffed about the commons-parent thing - it's broken the components because the job hasn't been finished by updating the pom.xmls. I know it's probably because it can be easy to view Commons Xxxx as Fred's baby, but it's one big codebase and you can go dive in and do cross-commons things that seem to be common sense and apologise later - or raise an all thread to discuss (kind of like below) and then dive in. snip/ I understand, and I am happy to discuss current state of affairs of the m2 build. I agree it shouldn't have been broken in the first place, but I don't have time to fix it right now. I will however, take a look next weekend at the latest (not the upcoming one, the one in 10 days) and try to help. If you have done a preliminary scan, let me know what components you want me to look at -- that'd be great since it will help me get started. I don't think of Commons-Xxxx as Fred's baby, I just don't have the resources to babysit 80 kids everyday. But thats an aside. Don't let the m2 situation distract you from the essense of the vote below. -Rahul Hen On 11/1/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JCL dependency versions
Realized I didn't post a closing time, I'll wrap this up Saturday 4th around 2 PM New York time. And, if its any surprise ... [X] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On Wed, 2006-11-01 at 11:59 -0500, Rahul Akolkar wrote: Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. HttpClient, for instance, still mandates JCL 1.0.3 only, even though we recommend JCL 1.1 be used in production. Same goes for Commons Codec: 1.3 is preferred but only 1.2 is required, since there is no reason why HttpClient would not work with Codec 1.2. This way the project.xml captures an important bit of information: the oldest / least supported version of each individual project dependency. I would not want JCL level requirement be bumped up to 1.1 for no reason, as HttpClient works perfectly well with 1.0.3 or above. Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. Take it for what it is worth. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Wed, 2006-11-01 at 11:59 -0500, Rahul Akolkar wrote: Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. HttpClient, for instance, still mandates JCL 1.0.3 only, even though we recommend JCL 1.1 be used in production. Same goes for Commons Codec: 1.3 is preferred but only 1.2 is required, since there is no reason why HttpClient would not work with Codec 1.2. This way the project.xml captures an important bit of information: the oldest / least supported version of each individual project dependency. I would not want JCL level requirement be bumped up to 1.1 for no reason, as HttpClient works perfectly well with 1.0.3 or above. Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. Take it for what it is worth. An approach that takes Oleg's concerns into account would be to use version number ranges, rather than just a particular version number. Essentially, you are stating I have tested with everything from version X to version Y. You can also leave the high end open ended if you trust your downstream dependencies not to break you with later versions :-). Oleg Craig
Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Wed, 2006-11-01 at 11:59 -0500, Rahul Akolkar wrote: Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. snip/ We may present it differently, but many of us think some policy (not in the totalitarian sense, but in the has to make sense sense) is missing. Be it the package renaming, trying to get components to have a coherent story for the most common dependecies, or EOL procedures -- I see them as many sides of the same (multifaceted) coin. We cannot afford to evolve as a bunch of hard-to-predict whimsical bits and pieces, there has to be an undercurrent. HttpClient, for instance, still mandates JCL 1.0.3 only, even though we recommend JCL 1.1 be used in production. Same goes for Commons Codec: 1.3 is preferred but only 1.2 is required, since there is no reason why HttpClient would not work with Codec 1.2. This way the project.xml captures an important bit of information: the oldest / least supported version of each individual project dependency. I would not want JCL level requirement be bumped up to 1.1 for no reason, as HttpClient works perfectly well with 1.0.3 or above. Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. snap/ I wasn't implying we require JCL 1.1 now, but that when we do, we diligently upgrade with each new release (for those components that release). Otherwise we have Foo that needs 1.0.2 and Bar that needs 1.1 and it cannot be obvious to everyone what its implication on needing Foo and Bar together is. Take it for what it is worth. snip/ You're modest ;-) -Rahul Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On Wed, 2006-11-01 at 15:26 -0500, Rahul Akolkar wrote: On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: ... I wasn't implying we require JCL 1.1 now, but that when we do, we diligently upgrade with each new release (for those components that release). Otherwise we have Foo that needs 1.0.2 and Bar that needs 1.1 and it cannot be obvious to everyone what its implication on needing Foo and Bar together is. Rahul, I am fine with (and probably in favor of) all Commons simultaneously upgrading to a specific version of JCL (or any other common dependency). In practical terms, though, that would pretty much mean that I personally stop testing the component(s) I am maintaining against older versions of JCL, thus rendering them de-facto EOL. Wouldn't it be better to just come out and declare JCL x.y.z end-of-life / no longer supported? Oleg Take it for what it is worth. snip/ You're modest ;-) -Rahul Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Wed, 2006-11-01 at 15:26 -0500, Rahul Akolkar wrote: On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: ... I wasn't implying we require JCL 1.1 now, but that when we do, we diligently upgrade with each new release (for those components that release). Otherwise we have Foo that needs 1.0.2 and Bar that needs 1.1 and it cannot be obvious to everyone what its implication on needing Foo and Bar together is. Rahul, I am fine with (and probably in favor of) all Commons simultaneously upgrading to a specific version of JCL (or any other common dependency). In practical terms, though, that would pretty much mean that I personally stop testing the component(s) I am maintaining against older versions of JCL, thus rendering them de-facto EOL. Wouldn't it be better to just come out and declare JCL x.y.z end-of-life / no longer supported? snip/ EOL might be a nice way to play out that prodding other projects to move thing that was discussed lately. If maintainers of Foo don't mind caring about all major version branches, they're free to not declare any as EOL'ed (to save us from the special case arguments). I personally wouldn't be too keen on maintaining more than one branch for some things I'm more closely involved in. -Rahul Oleg Take it for what it is worth. snip/ You're modest ;-) -Rahul Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Wed, 2006-11-01 at 11:59 -0500, Rahul Akolkar wrote: Speaking of cross-commons, the JCL deps are all over the place. Which is probably OK for now, since most variants are point releases (1.0, 1.0.2, 1.0.3, 1.0.4 being popular ATM). Since JCL is the bottom rung of the ladder, we should do our bit and move as one (i.e. if a component wants to up the JCL version, it should be an [all] discussion, and all components should update trunk such that their next RC matches up). We could restrict this to minor or major release updates, but I don't see any harm in keeping the JCL point release consistent as well. [ ] +1 Sounds reasonable [ ] 0 [ ] -1 Sounds unreasonable -Rahul Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. I don't think the end of life concept fits for us - nothing gets end of life'd unless we lose the files, close the project or have to retract the release for some reason (legal). So..Alexandria could be argued as being end of life...just about. mod_jserv is pretty much end of life. Lang 1.0 is not end of life - if someone asks a question about it we're not going to then not answer it - even if our answer is that was fixed in 1.1. If someone has a definite need for something on an old version and can't upgrade; and someone here has the itch; then it'll get fixed otherwise we'd probably point out how they can fix it themselves (svn etc) and help if they find problems in the build etc. So I don't think the JCL people would be end of lifeing things in the below. Unless we just view end of life as everything but the active release(s) [where Collections has a 2.x and 3.x set, but the rest of us just have the one active release]. HttpClient, for instance, still mandates JCL 1.0.3 only, even though we recommend JCL 1.1 be used in production. Same goes for Commons Codec: 1.3 is preferred but only 1.2 is required, since there is no reason why HttpClient would not work with Codec 1.2. This way the project.xml captures an important bit of information: the oldest / least supported version of each individual project dependency. I would not want JCL level requirement be bumped up to 1.1 for no reason, as HttpClient works perfectly well with 1.0.3 or above. Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. A supported dependency range would have value if it existed, but I think it'll be too hard to maintain/test-for/support you'd need something gump like with a bit more added to it. The current situation seems to be a much better return on time - if a project depends on JCL 1.1, then the math of version numbers recommends that you don't try to put JCL 1.0.x in it. If a project depends on JCL 1.0.2, then you should feel 90% safe to try out JCL 1.0.4 instead. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-206) NullPointerException in ValidatorAction class when we start application in Unix
[ http://issues.apache.org/jira/browse/VALIDATOR-206?page=comments#action_12446391 ] Anna Komaristaia commented on VALIDATOR-206: Thanks a lot for your help ! It works after I put in my code validator.setUseContextClassLoader(true); Thanks, //Anna NullPointerException in ValidatorAction class when we start application in Unix --- Key: VALIDATOR-206 URL: http://issues.apache.org/jira/browse/VALIDATOR-206 Project: Commons Validator Issue Type: Bug Components: Framework Affects Versions: 1.3.0 Release, 1.2.0 Release Environment: Unix Reporter: Anna Komaristaia When I start the application in Unix, there is the NullPointerException going from the next methods in ValidatorAction class - loadValidationClass( ClassLoader ) - loadParameterClasses( ClassLoader ) ClassLoadet parameter is null. This is the printout from Unix console: ERROR validator.ValidatorAction - Unhandled exception thrown during validation: null java.lang.NullPointerException at org.apache.commons.validator.ValidatorAction.loadValidationClass(ValidatorAction.java:623) at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:531) at org.apache.commons.validator.Field.validateForRule(Field.java:766) at org.apache.commons.validator.Field.validate(Field.java:846) at org.apache.commons.validator.Form.validate(Form.java:290) ... java.lang.NullPointerException at org.apache.commons.validator.ValidatorAction.loadParameterClasses(ValidatorAction.java:652) at org.apache.commons.validator.ValidatorAction.executeValidationMethod(ValidatorAction.java:532) at org.apache.commons.validator.Field.validateForRule(Field.java:766) at org.apache.commons.validator.Field.validate(Field.java:846) at org.apache.commons.validator.Form.validate(Form.java:290) at org.apache.commons.validator.Validator.validate(Validator.java:354) ... I recompiled the commons-validator jar with the next change and it's working fine in PC and Unix: if( loader == null ) this.validationClass = Class.forName(this.classname); else this.validationClass = loader.loadClass(this.classname); Thanks, //Anna -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
Don't mean to be terse, just lack of time. On 11/1/06, Henri Yandell [EMAIL PROTECTED] wrote: On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: snip/ Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. I don't think the end of life concept fits for us - nothing gets end of life'd unless we lose the files, close the project or have to retract the release for some reason (legal). snap/ Call it something else. Invitation to upgrade / preferred version is x.y.*, some such prodding. So..Alexandria could be argued as being end of life...just about. mod_jserv is pretty much end of life. Lang 1.0 is not end of life - if someone asks a question about it we're not going to then not answer it - even if our answer is that was fixed in 1.1. If someone has a definite need for something on an old version and can't upgrade; and someone here has the itch; then it'll get fixed otherwise we'd probably point out how they can fix it themselves (svn etc) and help if they find problems in the build etc. snip/ Oversimplified view. Some amount of tenacity from users implied there (also important to note that fixing it yourself is not acceptable for use in many environments). Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. A supported dependency range would have value if it existed, but I think it'll be too hard to maintain/test-for/support you'd need something gump like with a bit more added to it. The current situation seems to be a much better return on time - if a project depends on JCL 1.1, then the math of version numbers recommends that you don't try to put JCL 1.0.x in it. If a project depends on JCL 1.0.2, then you should feel 90% safe to try out JCL 1.0.4 instead. snap/ To me, that doesn't paint a good picture of us if we release Commons Foo with 1.1 and Commons Bar with 1.0.2 some time after that. Which is the ongoing vote, full circle. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Major versions require package name change
An attempt at a summary on this topic. The majority view on the thread was that a major version should not be mandated to mean a package rename. Instead, the view most widely expressed was that this should be a component decision. A second angle to emerge is that a 'large non-compatible change', as per [collections] for generics, may in fact be a change larger than our current major version number expresses. Going forward, this may argue for a different component name, if package renaming does not have widespread support. I'm not planning on bringing this to a vote, as it would be defeated as is. Stephen Niall Pemberton wrote: On 10/30/06, Stephen Colebourne [EMAIL PROTECTED] wrote: From: Sandy McArthur [EMAIL PROTECTED] If we want to come up with the notion of a super version, something that is more broad than a major version and includes non-backwards compatible changes I'm fine with that. But mandating that any major release be completely non-backwards compatible is silly. So what does a major version mean? Surely a major version means we have changed the code so it is no longer compatible, you cannot upgrade simlpy and easily Occasional drastic pruning of code is needed to keep it healthy and manageable. But we should not be eager to run out and break compatibility without deliberate and compelling reasons. I agree that we should not run out and break compatibility without deliberate and compelling reasons. In fact, I'd suggest that one of the beneficial side-effects of adopting this as a policy would be that we would all be more reticent about making those incompatible changes, leading to more minor and compatible releases - which I would argue is a Good Thing. I'll admit its less fun though. Is that what the negative viewpoint here is? Or is it just that the negatives have never faced jar hell? At the moment, I haven't heard any debate of the validity of the problem, or alternatives to the solution/ The alternative solution is to use the deprecate / remove cycle in the event of backwards incompatibility. For some components I agree this could result in jar hell and is not appropriate - but for others its a valid approach. Some components are more widely depended on than others. For example Validator 1.2.0 removed a whole load of deprecated items and I've not seen one complaint of jar hell - probably for two reasons - 1) people don't usually depend directly on Commons Validator - they use XML to configure it and as long as they have the right config, it works - 2) its mainly only a Struts dependency and not a widely used dependency. I think theres a few factors which influence the decision: 1) How deep (widely depended on) a component is. 2) How long a features been deprecated. 3) How significant the backwards incompatiblity is By mandating the package rename route we prevent individual components taking into account the above factors and making their own decisions. Ruling out the java deprecation feature is a bad decision IMO as well as guranteeing user pain - whether necessary or not. I'm not saying I'm against package renaming - its a good decision in the right circumstances - I'm just against having it as a requried policy. If we go this route I forsee people voting -1 on releases just because its policy - whatever valid arguments a particular component developers make for choosing an alternative route. Niall Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
On 11/1/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Don't mean to be terse, just lack of time. On 11/1/06, Henri Yandell [EMAIL PROTECTED] wrote: On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: snip/ Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. I don't think the end of life concept fits for us - nothing gets end of life'd unless we lose the files, close the project or have to retract the release for some reason (legal). snap/ Call it something else. Invitation to upgrade / preferred version is x.y.*, some such prodding. So..Alexandria could be argued as being end of life...just about. mod_jserv is pretty much end of life. Lang 1.0 is not end of life - if someone asks a question about it we're not going to then not answer it - even if our answer is that was fixed in 1.1. If someone has a definite need for something on an old version and can't upgrade; and someone here has the itch; then it'll get fixed otherwise we'd probably point out how they can fix it themselves (svn etc) and help if they find problems in the build etc. snip/ Oversimplified view. Some amount of tenacity from users implied there (also important to note that fixing it yourself is not acceptable for use in many environments). I was surprised to learn that the many of the big serious places don't use our binaries anyway - they have mandatory rules that they have to build it from source. I can imagine that smaller places have 'don't fork internally' rules. Makes sense as the cost of doing so is hard if you're not organized as a company and large enough for that cost to be relatively small. If there is no one interested in a backport etc, fix it yourself is all you're ever going to get. It's hard to judge that until it happens - if someone can convince me of the necessity of a backport of Lang 1.0, then I'll do it. Takes tenacity as you said though. Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. A supported dependency range would have value if it existed, but I think it'll be too hard to maintain/test-for/support you'd need something gump like with a bit more added to it. The current situation seems to be a much better return on time - if a project depends on JCL 1.1, then the math of version numbers recommends that you don't try to put JCL 1.0.x in it. If a project depends on JCL 1.0.2, then you should feel 90% safe to try out JCL 1.0.4 instead. snap/ To me, that doesn't paint a good picture of us if we release Commons Foo with 1.1 and Commons Bar with 1.0.2 some time after that. Which is the ongoing vote, full circle. I'm definitely on board with you on that one - we should ideally not release with old versions of Commons dependencies. It means that we, the Commons community, are not agreeing with the it's stable view of another part of the Commons community. Ideally we should also not be using any deprecated calls on those libraries. It gets nice and tricky when you start to compound version numbering: If Digester releases a new version and the only change is a move from Collections 2 to Collections 3; does that mean Digester should also do a major release, or is it a minor or bugfix release. This is about the time that a single jar release starts to sound attractive (not all of commons, but all of the ones that would have internal dependencies). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=comments#action_12446407 ] Remi Arntzen commented on MATH-157: --- You know you can invert that matrix (it's orthogonal, so just take the transpose), and you can also invert the S matrix (it's diagonal, invert each value on the diagonal), so just invert those two and multiply through the original matrix to get the other orthogonal matrix however when the original matrix is not square that method fails to apply. the inverse of a non-square matrix does not exist, and as such you can not simply take the transpose of each matrix product as they are not of equal size. (although this method does work splendidly on square matrices) It just seems like you're kindof going in the wrong direction I'd say I'm literally going in the wrong direction, some of the vectors seem to be randomly inverted, and as I've said earlier I have never had any formal training on this subject (just rudimentary high school training). I'm basically coding as I am learning. Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=comments#action_12446421 ] Tyler Ward commented on MATH-157: - I think I see the confusion. Take a look at my first comment here. You don't want to invert (or find eigenvectors of) the original matrix. Say the original matrix is A (and A` is A-transpose, with row and column labels flipped), which is NxM (N M), you want to construct eigenvectors for... B = A`A [NxN square symmetric matrix] You can do most of this by performing a QR decomposition on B, and then producing T = QBQ`. Unfortunately, T is not diagonal, it will be tridiagonal (three rows of values), so you need to reduce it the rest of the way to diagonal form by multiplying by a matrix P. Finding which matrix does this however is a chore, it requires givens reductions, explained above. In the end, you want to produce a matrix P such that D = PQBQ`P` is diagonal. This should be reversible, B = Q`P`DPQ should be the B you started with. If you can do that, then you're home free, just a few matrix multiplications will finish the job. When you get to the step of needing givens reductions, let me know. I can probably give you some formulas and such that will make it really easy. If you let me know how you're doing with this, I can definitely help. I can't however contribute code (work forbids it), but I can help a lot with anything else, even formulas. So I'd say try this. Use the QR decomposition they already have to get to the point of being able to produce T, and reverse T to get the B that you started with. Do that, and I can give you a PDF that will make the givens step very easy, it's really only a couple dozen lines of code, but requires some care that I can walk you through. Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=comments#action_12446423 ] Tyler Ward commented on MATH-157: - Also, about testing. I've found that the best way to test this is just with random matrices. If you can use, say, 10,000 random matrices and always get back what you started with (within some small tolerance), then you'll know that you're doing it correctly. In order to create a symmetric matrix, just make a random matrix and multiply it by its own transpose, that will always be square symmetric, then try the above procedure, and make sure you can get back to what you started with. There are some special cases to be dealt with, but those are easily added later. Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[
http://issues.apache.org/jira/browse/DIGESTER-109?page=comments#action_12446425
]
Henri Yandell commented on DIGESTER-109:
In line with VALIDATOR-206, Digester also has a setUseContextClassLoader(true)
method. So this should also be fixable by adding that call to your code.
It does raise the question of whether there is any time you wouldn't want the
context class loader to be used. Here's info on the ContextClassLoader:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getContextClassLoader()
Here's the Lang ClassUtils.getClass implementation:
public static Class getClass(String className, boolean initialize) throws
ClassNotFoundException {
ClassLoader contextCL = Thread.currentThread().getContextClassLoader();
ClassLoader loader = contextCL == null ?
ClassUtils.class.getClassLoader() : contextCL;
return getClass(loader, className, initialize );
}
That would seem to imply that in the opinion of those who worked on that in
Lang, that there's no reason not to use it, though you still need a backup in
case it's null.
FromXmlRuleSet and SetNextRule classloader issue
---
Key: DIGESTER-109
URL: http://issues.apache.org/jira/browse/DIGESTER-109
Project: Commons Digester
Issue Type: Bug
Reporter: Anna Komaristaia
When I start the application in Unix, there are 2 classes cause the problem:
1) The NullPointerException in FromXmlRuleSet class in the method
addRuleInstances(Digester, String);
2) The NullPointerException in SetNextRule class in the method end();
Temporary solution
---
I recompiled the commons-digester jar with the next changes and it's working
fine in PC and Unix:
Changes in the FromXmlRuleSet class
1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd;
2) in the method addRuleInstances
the line
URL dtdURL =
getClass().getClassLoader().getResource(DIGESTER_DTD_PATH);
changed by
URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH);
Changes In the SetNextRule class
the line
paramTypes[0] = digester.getClassLoader().loadClass(
paramType);
changed by
if( digester.getClassLoader() == null )
paramTypes[0] = Class.forName(paramType);
else
paramTypes[0] = digester.getClassLoader().loadClass(
paramType);
Thanks,
//Anna
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MATH-157) Add support for SVD.
[ http://issues.apache.org/jira/browse/MATH-157?page=comments#action_12446426 ] Tyler Ward commented on MATH-157: - One more thing. I don't think you can just use the Q from the QR reduction (slipped my mind earlier). Try it, you'll see that it doesn't come out tridiagonal. The trick is that you need to do both sides, front and back on each iteration of the householder reduction. The household reduction reduces each column of the matrix my multiplying by a Q matrix that has a single column of values, and the rest is the identity matrix. Like this A2 = Q1A1. You need to do this ... A2 = Q1A1Q1`, on each iteration, so A3 = Q3Q2Q1A1Q1`Q2`Q3`, etc... Make sure it doesn't come out right before doing this, but I think the QR decomposition will compute the matrix wrong, because it's assuming a one sided (forward only) transformation, but check first. Add support for SVD. Key: MATH-157 URL: http://issues.apache.org/jira/browse/MATH-157 Project: Commons Math Issue Type: New Feature Reporter: Tyler Ward Attachments: svd.tar.gz SVD is probably the most important feature in any linear algebra package, though also one of the more difficult. In general, SVD is needed because very often real systems end up being singular (which can be handled by QR), or nearly singular (which can't). A good example is a nonlinear root finder. Often the jacobian will be nearly singular, but it is VERY rare for it to be exactly singular. Consequently, LU or QR produces really bad results, because they are dominated by rounding error. What is needed is a way to throw out the insignificant parts of the solution, and take what improvements we can get. That is what SVD provides. The colt SVD algorithm has a serious infinite loop bug, caused primarily by Double.NaN in the inputs, but also by underflow and overflow, which really can't be prevented. If worried about patents and such, SVD can be derrived from first principals very easily with the acceptance of two postulates. 1) That an SVD always exists. 2) That Jacobi reduction works. Both are very basic results from linear algebra, available in nearly any text book. Once that's accepted, then the rest of the algorithm falls into place in a very simple manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBUTILS-3) [dbutils] Setting bean properties fails silently
[ http://issues.apache.org/jira/browse/DBUTILS-3?page=all ] Henri Yandell resolved DBUTILS-3. - Resolution: Fixed Oops, bad on my part. Your patch for DBUTILS-32 included this fix and I applied that part of it without noticing. So this is resolved as a part of r470003. [dbutils] Setting bean properties fails silently Key: DBUTILS-3 URL: http://issues.apache.org/jira/browse/DBUTILS-3 Project: Commons DbUtils Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Tim Bailen Fix For: 1.1 Attachments: patch-DBUTILS-3.txt I had a property in my bean that wasn't being set by BeanHandler. No matter the value of the matching field name in the database, the value in the bean would always come back as 0. I traced the culprit to BasicRowProcessor.callSetter(), which calls the setter method on the bean corresponding to the same field name in the database. Before it attempts to call the setter, it checks to make sure that the type of the value retrieved from the database is compatible with the type of the bean. This behavior is fair enough, but if the types are determined to be incompatible, DBUtils essentially fails silently. That is, it does not call the setter and it does nothing to inform the developer that this is what happened. This was frustrating for me because I had a field that was type int in my bean and type long in the database, but I didn't realize why it wasn't being set until I stepped through the code. POSSIBLE RESOLUTIONS 1. Start a FAQ for DBUtils and mention that a bean's property will not be initialized if its type is incompatible with the corresponding field in the database 2. Log some message to this effect when it occurs (I don't believe DBUtils has any logging, so this probably isn't viable) 3. Throw an exception when this case occurs. Better that the program fail obviously and with some information about what happened rather than return a bean in an invalid state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBUTILS-1) [dbutils] BeanListHandler and BeanHandler fail to support java.sql.Date()
[ http://issues.apache.org/jira/browse/DBUTILS-1?page=all ]
Henri Yandell updated DBUTILS-1:
Attachment: Proposed-DBUTILS-1.patch
I think it needs a bit more work to support java.sql.Time and Timestamp, and I
think the code can be expressed a bit differently to keep things clear.
Alan, how does the 'Proposed-DBUTILS-1.patch' that I just uploaded look to you?
[dbutils] BeanListHandler and BeanHandler fail to support java.sql.Date()
-
Key: DBUTILS-1
URL: http://issues.apache.org/jira/browse/DBUTILS-1
Project: Commons DbUtils
Issue Type: Bug
Environment: Operating System: Windows 2000
Platform: PC
Reporter: Xinyi-Huang
Fix For: 1.1
Attachments: patch-DBUTILS-1-and-3.txt, Proposed-DBUTILS-1.patch
BeanListHandler or BeanHandler fail to support the java.sql.Date type when
read from database.
I just add some codes to callSetter the method callSetter of BeanProcessor as
--
else if(params[0].getName().equals(java.sql.Date)){
value = (value==null)?null:new java.sql.Date
(((java.util.Date)value).getTime());
setter.invoke(target, new Object[] {value});
--
org.apache.commons.dbutils.BeanProcessor
private void callSetter(Object target, PropertyDescriptor prop, Object value)
throws SQLException {
Method setter = prop.getWriteMethod();
if (setter == null) {
return;
}
Class[] params = setter.getParameterTypes();
try {
// Don't call setter if the value object isn't the right type
if (this.isCompatibleType(value, params[0])) {
setter.invoke(target, new Object[] { value });
}else if(params[0].getName().equals(java.sql.Date)){
value = (value==null)?null:new java.sql.Date
(((java.util.Date)value).getTime());
setter.invoke(target, new Object[] {value});
}
} catch (IllegalArgumentException e) {
throw new SQLException(
Cannot set + prop.getName() + : + e.getMessage());
} catch (IllegalAccessException e) {
throw new SQLException(
Cannot set + prop.getName() + : + e.getMessage());
} catch (InvocationTargetException e) {
throw new SQLException(
Cannot set + prop.getName() + : + e.getMessage());
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBUTILS-31) fillStatement setNull bug with the Derby JDBC driver
[ http://issues.apache.org/jira/browse/DBUTILS-31?page=all ]
Henri Yandell updated DBUTILS-31:
-
Fix Version/s: (was: 1.1)
fillStatement setNull bug with the Derby JDBC driver
Key: DBUTILS-31
URL: http://issues.apache.org/jira/browse/DBUTILS-31
Project: Commons DbUtils
Issue Type: Improvement
Affects Versions: 1.0
Environment: Derby 10.1.2.1
Reporter: Francis Townsend
This has been documented many times before, but I was not happy with the
existing code fixes. The following small code snippet should fix it for all
conforming JDBC drivers.
protected void fillStatement(PreparedStatement stmt, Object[] params)
throws SQLException {
if (params == null) {
return;
}
ParameterMetaData pmd = stmt.getParameterMetaData();
for (int i = 0; i params.length; i++) {
if (params[i] != null) {
stmt.setObject(i + 1, params[i]);
} else {
stmt.setNull(i + 1, pmd.getParameterType(i + 1));
}
}
}
The only difference is that you get the parameter meta data and pass that
type information to the setNull method. This should neatly fix this problem,
with a very slight additional overhead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBUTILS-17) [dbutils] ScalarHandler subclasses that return Integers and Longs
[ http://issues.apache.org/jira/browse/DBUTILS-17?page=all ] Henri Yandell updated DBUTILS-17: - Attachment: DBUTILS-17.patch Unit tests and modified class files to resolve this patch. I'm unsure yet if they should be added. The use-case is to make it easier to work out a count(*), but I'd expect it to only be saving the user a cast in the end (unless there are databases that like to return the result of select count(*) with a non Number type (we convert primitive ints etc up to Numbers). [dbutils] ScalarHandler subclasses that return Integers and Longs - Key: DBUTILS-17 URL: http://issues.apache.org/jira/browse/DBUTILS-17 Project: Commons DbUtils Issue Type: Improvement Environment: Operating System: All Platform: All Reporter: greg hawkes Priority: Minor Fix For: 1.1 Attachments: DBUTILS-17.patch, IntScalarHandler.java, LongScalarHandler.java I (and, looking around, many other people) most often use ScalarHandler to fetch the result of an SQL count(*) column. ScalarHandler works, but I was forever needing to parse the result to create an Integer (and occasionally, a Long) value. Several possible solutions have been proposed to make this task easier. This is mine. I have extended ScalarHandler to create IntScalarHandler and LongScalarHandler, which return Integers and Longs, respectively. Their usage is exactly the same as ScalarHandler. They have been tested on Oracle, MS-SQL Server, and PostgreSQL databases, and have proven to be very effective. I hope that they can be included in the DbUtils distribution, where they fit right alongside the existing ScalarHandler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBUTILS-27) [dbutils] QueryRunner.count(String, ...) methods for SELECT COUNT(...) sql
[
http://issues.apache.org/jira/browse/DBUTILS-27?page=comments#action_12446473 ]
Henri Yandell commented on DBUTILS-27:
--
In comparison to DBUTILS-17, the method name is more focused here (count(..)),
but the method doesn't take care of the select count(*), so you could quite
happily pass something in that is not a count method. This makes it just a
weakly described version of DBUTILS-17.
It does handle the null to 0 semantics that make sense in the case of a count
request, and it is returning an int rather than the Integer/Long that
DBUTILS-17 has to do because it uses the Handler system.
The API could be changed to only have the where clause, but that seems pretty
weak.
Maybe this should be a:
public long QueryRunner.queryForLong(...)
[dbutils] QueryRunner.count(String, ...) methods for SELECT COUNT(...) sql
---
Key: DBUTILS-27
URL: http://issues.apache.org/jira/browse/DBUTILS-27
Project: Commons DbUtils
Issue Type: Improvement
Environment: Operating System: All
Platform: All
Reporter: Michael Heuer
Priority: Minor
Fix For: 1.1
Attachments: count.java, count.java, diff.txt
Found that I was repeating the same bit of code over and over again when
executing SELECT COUNT(...)
sql queries with QueryRunner, so I thought I might code this up into a set of
static methods for possible
inclusion in commons-dbutils.
e.g.
Connection conn;
String sql = select count(*) from tablename where column0 = ? and column1 =
?;
from:
int count = 0;
Object result = QueryRunner.query(conn, sql, new Object[] { foo, bar },
new ScalarHandler());
if (result != null) {
count = ((Integer) result).intValue();
}
to:
int count = QueryRunner.count(conn, sql, new Object[] { foo, bar });
See attached diff.txt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBUTILS-16) [dbutils] ResultSetRowProcessor abstract handler and some classes rework
[
http://issues.apache.org/jira/browse/DBUTILS-16?page=comments#action_12446490 ]
Henri Yandell commented on DBUTILS-16:
--
Negative side of this is that it changes the public 1.0 API by removing
toBeanList in a few places. So not usable for 1.1 in its entirety.
[dbutils] ResultSetRowProcessor abstract handler and some classes rework
Key: DBUTILS-16
URL: http://issues.apache.org/jira/browse/DBUTILS-16
Project: Commons DbUtils
Issue Type: Improvement
Environment: Operating System: All
Platform: All
Reporter: Mikhail Krivoshein
Priority: Minor
Fix For: 1.1
Attachments: GenericListHandler.patch, GenericListHandler_2.patch
Index: ArrayListHandler.java
===
RCS file: /home/cvspublic/jakarta-
commons/dbutils/src/java/org/apache/commons/dbutils/handlers/ArrayListHandler.ja
va,v
retrieving revision 1.4
diff -u -r1.4 ArrayListHandler.java
--- ArrayListHandler.java 28 Feb 2004 00:12:22 - 1.4
+++ ArrayListHandler.java 4 Jun 2004 13:24:00 -
@@ -1,82 +1,68 @@
/*
* Copyright 2003-2004 The Apache Software Foundation
- *
- * Licensed under the Apache License, Version 2.0 (the License);
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may
not
+ * use this file except in compliance with the License. You may obtain a copy
+ * of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
* Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
+ * distributed under the License is distributed on an AS IS BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
*/
package org.apache.commons.dbutils.handlers;
import java.sql.ResultSet;
import java.sql.SQLException;
-import java.util.ArrayList;
-import java.util.List;
-import org.apache.commons.dbutils.ResultSetHandler;
import org.apache.commons.dbutils.RowProcessor;
/**
- * codeResultSetHandler/code implementation that converts the
- * codeResultSet/code into a codeList/code of codeObject[]/codes.
- * This class is thread safe.
+ * codeResultSetHandler/code implementation that converts the
codeResultSet/code
+ * into a codeList/code of codeObject[]/codes. This class is
+ * thread safe.
*
* @see ResultSetHandler
*/
-public class ArrayListHandler implements ResultSetHandler {
-
-/**
- * The RowProcessor implementation to use when converting rows
- * into Object[]s.
- */
-private RowProcessor convert = ArrayHandler.ROW_PROCESSOR;
-
-/**
- * Creates a new instance of ArrayListHandler using a
- * codeBasicRowProcessor/code for conversions.
- */
-public ArrayListHandler() {
-super();
-}
-
-/**
- * Creates a new instance of ArrayListHandler.
- *
- * @param convert The codeRowProcessor/code implementation
- * to use when converting rows into Object[]s.
- */
-public ArrayListHandler(RowProcessor convert) {
-super();
-this.convert = convert;
-}
-
-/**
- * Convert each row's columns into an codeObject[]/code and store
them
- * in a codeList/code in the same order they are returned from the
- * codeResultSet.next()/code method.
- *
- * @return A codeList/code of codeObject[]/codes, never
- * codenull/code.
- *
- * @throws SQLException
- * @see org.apache.commons.dbutils.ResultSetHandler#handle
(java.sql.ResultSet)
- */
-public Object handle(ResultSet rs) throws SQLException {
-
-List result = new ArrayList();
-
-while (rs.next()) {
-result.add(this.convert.toArray(rs));
-}
-
-return result;
-}
+public class ArrayListHandler extends ResultSetRowProcessor {
+ /**
+ * The RowProcessor implementation to use when converting rows into
+ * Object[]s.
+ */
+ private RowProcessor convert = ArrayHandler.ROW_PROCESSOR;
+
+ /**
+ * Creates a new instance of ArrayListHandler using a
codeBasicRowProcessor/code
+ * for conversions.
+ */
+ public ArrayListHandler() {
+
[jira] Updated: (DBUTILS-16) [dbutils] ResultSetRowProcessor abstract handler and some classes rework
[ http://issues.apache.org/jira/browse/DBUTILS-16?page=all ]
Henri Yandell updated DBUTILS-16:
-
Attachment: DBUTILS-16.patch
Version of the patch that does not remove the toBeanList methods.
I'm unsure if they should be deprecated - it feels that there is no reason to
do so.
[dbutils] ResultSetRowProcessor abstract handler and some classes rework
Key: DBUTILS-16
URL: http://issues.apache.org/jira/browse/DBUTILS-16
Project: Commons DbUtils
Issue Type: Improvement
Environment: Operating System: All
Platform: All
Reporter: Mikhail Krivoshein
Priority: Minor
Fix For: 1.1
Attachments: DBUTILS-16.patch, GenericListHandler.patch,
GenericListHandler_2.patch
Index: ArrayListHandler.java
===
RCS file: /home/cvspublic/jakarta-
commons/dbutils/src/java/org/apache/commons/dbutils/handlers/ArrayListHandler.ja
va,v
retrieving revision 1.4
diff -u -r1.4 ArrayListHandler.java
--- ArrayListHandler.java 28 Feb 2004 00:12:22 - 1.4
+++ ArrayListHandler.java 4 Jun 2004 13:24:00 -
@@ -1,82 +1,68 @@
/*
* Copyright 2003-2004 The Apache Software Foundation
- *
- * Licensed under the Apache License, Version 2.0 (the License);
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may
not
+ * use this file except in compliance with the License. You may obtain a copy
+ * of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
* Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an AS IS BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
+ * distributed under the License is distributed on an AS IS BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
*/
package org.apache.commons.dbutils.handlers;
import java.sql.ResultSet;
import java.sql.SQLException;
-import java.util.ArrayList;
-import java.util.List;
-import org.apache.commons.dbutils.ResultSetHandler;
import org.apache.commons.dbutils.RowProcessor;
/**
- * codeResultSetHandler/code implementation that converts the
- * codeResultSet/code into a codeList/code of codeObject[]/codes.
- * This class is thread safe.
+ * codeResultSetHandler/code implementation that converts the
codeResultSet/code
+ * into a codeList/code of codeObject[]/codes. This class is
+ * thread safe.
*
* @see ResultSetHandler
*/
-public class ArrayListHandler implements ResultSetHandler {
-
-/**
- * The RowProcessor implementation to use when converting rows
- * into Object[]s.
- */
-private RowProcessor convert = ArrayHandler.ROW_PROCESSOR;
-
-/**
- * Creates a new instance of ArrayListHandler using a
- * codeBasicRowProcessor/code for conversions.
- */
-public ArrayListHandler() {
-super();
-}
-
-/**
- * Creates a new instance of ArrayListHandler.
- *
- * @param convert The codeRowProcessor/code implementation
- * to use when converting rows into Object[]s.
- */
-public ArrayListHandler(RowProcessor convert) {
-super();
-this.convert = convert;
-}
-
-/**
- * Convert each row's columns into an codeObject[]/code and store
them
- * in a codeList/code in the same order they are returned from the
- * codeResultSet.next()/code method.
- *
- * @return A codeList/code of codeObject[]/codes, never
- * codenull/code.
- *
- * @throws SQLException
- * @see org.apache.commons.dbutils.ResultSetHandler#handle
(java.sql.ResultSet)
- */
-public Object handle(ResultSet rs) throws SQLException {
-
-List result = new ArrayList();
-
-while (rs.next()) {
-result.add(this.convert.toArray(rs));
-}
-
-return result;
-}
+public class ArrayListHandler extends ResultSetRowProcessor {
+ /**
+ * The RowProcessor implementation to use when converting rows into
+ * Object[]s.
+ */
+ private RowProcessor convert = ArrayHandler.ROW_PROCESSOR;
+
+ /**
+ * Creates a new instance of ArrayListHandler using a
codeBasicRowProcessor/code
+ * for conversions.
+ */
+ public
[jira] Commented: (DBUTILS-30) [dbutils] New ResultSetHandler - ObjectHandler
[ http://issues.apache.org/jira/browse/DBUTILS-30?page=comments#action_12446495 ] Henri Yandell commented on DBUTILS-30: -- 33477 is now DBUTILS-28. [dbutils] New ResultSetHandler - ObjectHandler -- Key: DBUTILS-30 URL: http://issues.apache.org/jira/browse/DBUTILS-30 Project: Commons DbUtils Issue Type: Improvement Environment: Operating System: other Platform: All Reporter: Joe Zulli Priority: Minor It would be great to see a ResultSetHandler that populates an existing object (as opposed to the BeanHandler which instantiates a new one, given a class). This woud be useful for implementing simple and easy object relational mapping. For instance, an object that loads it self from the database could use the ObjectHandler and pass in this as the object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Outstanding issues against dbutils-1.1 as of Nov. 1, 2006
On 11/1/06, Alan Canon [EMAIL PROTECTED] wrote: Apologies if this is a duplicate: I sent it in to the list earlier but didn't see it appear. Thanks for this work Alan, it's made it a lot easier for me to dig into it. There are four Major issues listed against the 1.1 release of [dbutils]. DBUTILS-1 BeanListHandler and BeanHandler fail to support java.sql.Date() The reporter of the bug supplied code to fix the issue. I've posted an alternative patch - let me know what you think. DBUTILS-32 Tests fail to build under 1.6, and warning while compiling source Alan Canon has supplied code in a JIRA comment to eliminate the compiler errors and warnings under Java 6 SDK. Applied. DBUTILS-3 Setting bean properties fails silently Alan Canon has supplied code in a JIRA comment to throw a SQLException when the described condition occurs, according to a recommendation made in a previous comment. Applied (accidentally with DBUTILS-32 because I applied the wrong patch - sorry). DBUTILS-31 fillStatement setNull bug with the Derby JDBC driver Code is present in the bug description, however it appears to have been prepared to work against JDBC 3.0. The suggested patch uses java.sql.ParameterMetaData, not present in JDK 1.4.2. Comments on the bug suggest testing the JDBCMajor number to see what the JDBC version is, and acting accordingly. Additionally, another comment states the code would need to fall back to the JDBC 2.1 specification if the Oracle JDBC driver throws an exception. Francis Townsend and Henri Yandell posted comments recommending that this solution be put off for a future release. I've removed the 1.1 fix-version in JIRA for this one. In addition, there are three Minor issues listed: DBUTILS-17 ScalarHandler subclasses that return Integers and Longs Sample implmentations are provided in the JIRA report. This also addresses issues present in DBUTILS-27. I've done the work for this, but saved it as a patch (DBUTILS-17.patch). I don't get why this solution is of use to the user, it just seems that it would stop them having to cast to Number, and handle converting a String to a number if a database returns a String. Especially given that it's targetting the count(*)'s of the world, are there databases that answer that with a String? DBUTILS-27 QueryRunner.count(String, ...) methods for SELECT COUNT(...) sql This one is an improvement with diffs provided. Henri Yandell recommended it for the 1.1 release in a comment. I think I like this approach better than the DBUTILS-17 approach, however the concept of it being a count(..) method doesn't work. I suggest making it a queryForLong that returns a long, though I'm not sure if turning null into 0 makes sense without the semantics. Neither of these solutions seem right :) DBUTILS-16 ResultSetRowProcessor abstract handler and some classes rework There are patches provided. This request for improvement is two years old. Henri Yandell posted a comment earlier this year that says FIX or WONTFIX for 1.1. The patch removes some public API code, so that part is a no-no. I've reworked the patch and I don't see any reason not to apply it. Any thoughts before I do? Does anyone think the toBeanList stuff should be deprecated? These seven issues are all that are scheduled against the 1.1 release of dbutils. Four other unscheduled issues are not described in this message. Two of the issues (DBUTILS-30 and part of DBUTILS-28) deal with a variant of the Bean code that loads an existing bean rather than a new one. I think that would be worth putting in 1.1 - need to compare Kyle and David's implementations and document nicely concerning David's threading worries. What do you think? DBUTILS-29 is good, but someone would need to have the itch. Definitely not 1.1. DBUTILS-14 is also something that should be looked at beyond 1.1. Thanks again, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
