[jira] Created: (BEANUTILS-290) Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project
Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project --- Key: BEANUTILS-290 URL: https://issues.apache.org/jira/browse/BEANUTILS-290 Project: Commons BeanUtils Issue Type: Task Components: Bean-Collections Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 This issue has been discussed in the following thread: http://tinyurl.com/2xdpku For BeanUtils 1.7.0 the following classes which had a dependency on Commons Collections were split into a separate bean-collections sub-module: BeanComparator.java BeanMap.java BeanPredicate.java BeanPropertyValueChangeClosure.java BeanPropertyValueEqualsPredicate.java BeanToPropertyValueTransformer.java Three flavours of jars were released in 1.7.0 commons-beanutils.jar - containing all BeanUtils classes, including above bean-collections ones commons-beanutils-bean-collections.jar - containing just the above bean-collections classes commons-beanutils-core.jar - containing BeanUtils classes excluding above bean-collections ones BeanUtils 1.7.0 was created using ant and (I presume) the maven poms for the above artifacts were manually created - unfortunately with mistakes: 1) The pom for commons-beanutils.jar DOESN'T declare any Commons Collections dependency (which it has for the bean-collections classes) 2) The pom for commons-beanutils-core.jar DOES declare a Commons Collections dependency (which it doesn't actually have) The proposal for BeanUtils 1.8.0 (see http://tinyurl.com/2xdpku) is to merge the bean-collections classes back into core BeanUtils and get rid of the bean-collections sub-module - releasing just a single jar for BeanUtils and marking the Commons Collections dependency as optional in the maven pom (see http://tinyurl.com/2nm2bu). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-290) Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project
[ https://issues.apache.org/jira/browse/BEANUTILS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-290. --- Resolution: Fixed I have merged the classes and unit tests back into core BeanUtils and removed the bean-collections sub-module. Ant, Maven1 and Maven2 builds all work. Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project --- Key: BEANUTILS-290 URL: https://issues.apache.org/jira/browse/BEANUTILS-290 Project: Commons BeanUtils Issue Type: Task Components: Bean-Collections Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 This issue has been discussed in the following thread: http://tinyurl.com/2xdpku For BeanUtils 1.7.0 the following classes which had a dependency on Commons Collections were split into a separate bean-collections sub-module: BeanComparator.java BeanMap.java BeanPredicate.java BeanPropertyValueChangeClosure.java BeanPropertyValueEqualsPredicate.java BeanToPropertyValueTransformer.java Three flavours of jars were released in 1.7.0 commons-beanutils.jar - containing all BeanUtils classes, including above bean-collections ones commons-beanutils-bean-collections.jar - containing just the above bean-collections classes commons-beanutils-core.jar - containing BeanUtils classes excluding above bean-collections ones BeanUtils 1.7.0 was created using ant and (I presume) the maven poms for the above artifacts were manually created - unfortunately with mistakes: 1) The pom for commons-beanutils.jar DOESN'T declare any Commons Collections dependency (which it has for the bean-collections classes) 2) The pom for commons-beanutils-core.jar DOES declare a Commons Collections dependency (which it doesn't actually have) The proposal for BeanUtils 1.8.0 (see http://tinyurl.com/2xdpku) is to merge the bean-collections classes back into core BeanUtils and get rid of the bean-collections sub-module - releasing just a single jar for BeanUtils and marking the Commons Collections dependency as optional in the maven pom (see http://tinyurl.com/2nm2bu). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-280) Check binary compatibility is still good
[ https://issues.apache.org/jira/browse/BEANUTILS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-280: -- Attachment: (was: CLIRR.txt) Check binary compatibility is still good Key: BEANUTILS-280 URL: https://issues.apache.org/jira/browse/BEANUTILS-280 Project: Commons BeanUtils Issue Type: Task Reporter: Henri Yandell Fix For: 1.8.0 Attachments: CLIRR.txt Clirr/jardiff/whatever. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-280) Check binary compatibility is still good
[ https://issues.apache.org/jira/browse/BEANUTILS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-280: -- Attachment: CLIRR.txt Attach latest CLIRR report showing BeanUtils trunk is binary compatible with version 1.7.0 Check binary compatibility is still good Key: BEANUTILS-280 URL: https://issues.apache.org/jira/browse/BEANUTILS-280 Project: Commons BeanUtils Issue Type: Task Reporter: Henri Yandell Fix For: 1.8.0 Attachments: CLIRR.txt Clirr/jardiff/whatever. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-280) Check binary compatibility is still good
[ https://issues.apache.org/jira/browse/BEANUTILS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-280. --- Resolution: Fixed Assignee: Niall Pemberton Check binary compatibility is still good Key: BEANUTILS-280 URL: https://issues.apache.org/jira/browse/BEANUTILS-280 Project: Commons BeanUtils Issue Type: Task Reporter: Henri Yandell Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: CLIRR.txt Clirr/jardiff/whatever. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-92. -- Resolution: Fixed Looks good to me, thanks :) Closing this as resolved. PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: Beanutils-92-updated.patch, fixCopyPropertyException, Jira92TestCase.java I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Fix Version/s: (was: 1.8.0) LATER THAN 1.8.0 Moving to post 1.8.0 Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: LATER THAN 1.8.0 Attachments: ArrayIndexedProperty.patch, BEANUTILS-35-PropertyUtilsBean-getPropertyType.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-142) RowSetDynaClass fails to copy ResultSet to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-142: -- Affects Version/s: 1.7.0 Summary: RowSetDynaClass fails to copy ResultSet to DynaBean with Oracle 10g JDBC driver (was: [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver) RowSetDynaClass fails to copy ResultSet to DynaBean with Oracle 10g JDBC driver --- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Assignee: Henri Yandell Fix For: 1.8.0 Attachments: beanutils-142-oracle-bug.patch, Beanutils-142.patch, Play.java Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-142) RowSetDynaClass fails to copy ResultSet to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-142. --- Resolution: Fixed RowSetDynaClass fails to copy ResultSet to DynaBean with Oracle 10g JDBC driver --- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Assignee: Henri Yandell Fix For: 1.8.0 Attachments: beanutils-142-oracle-bug.patch, Beanutils-142.patch, Play.java Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-18) PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
[ https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-18: - Affects Version/s: 1.7.0 Summary: PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent (was: [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent) PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent - Key: BEANUTILS-18 URL: https://issues.apache.org/jira/browse/BEANUTILS-18 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: Windows 2000 Platform: PC Reporter: Maarten Coene Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: BEANUTILS-18-PropertyUtilsBean.patch, patch-PropertyUtilsBean.txt, patch-PropertyUtilsTestCase.txt, PropertyUtilsTest.java Hi, When the object passed to PropertyUtils is a non-public class, the PropertyUtils.isReadable() method returns true for an existing property while the PropertyUtils.getProperty() method for the same property throws a NoSuchMethodException. I'll attach a junit test that illustrates the problem. regards, Maarten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-18) PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
[ https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-18. -- Resolution: Fixed Fixed http://svn.apache.org/viewvc?view=revrevision=556237 PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent - Key: BEANUTILS-18 URL: https://issues.apache.org/jira/browse/BEANUTILS-18 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: Windows 2000 Platform: PC Reporter: Maarten Coene Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: BEANUTILS-18-PropertyUtilsBean.patch, patch-PropertyUtilsBean.txt, patch-PropertyUtilsTestCase.txt, PropertyUtilsTest.java Hi, When the object passed to PropertyUtils is a non-public class, the PropertyUtils.isReadable() method returns true for an existing property while the PropertyUtils.getProperty() method for the same property throws a NoSuchMethodException. I'll attach a junit test that illustrates the problem. regards, Maarten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-92: - Attachment: Jira35TestCase.java The changes for BEANUTILS-18 does prevent some of the scenrios that caused NoSuchMethodException to be thrown in the past - unfortunately not the one reportted by Will (i.e. only indexed setter in the target bean). Attaching a test case that demonstrates Will's issue is not yet resolved. So IMO we should go with Will's original suggestion of catching NoSuchMethodException. PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: fixCopyPropertyException, Jira35TestCase.java I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation
[ https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-91: - Summary: PropertyUtils.copyProperties throws exceptions contrary to documentation (was: [beanutils] PropertyUtils.copyProperties throws exceptions contrary to documentation) PropertyUtils.copyProperties throws exceptions contrary to documentation Key: BEANUTILS-91 URL: https://issues.apache.org/jira/browse/BEANUTILS-91 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.5 Environment: Operating System: other Platform: Other Reporter: Arun Mammen Thomas Priority: Minor Fix For: 1.8.0 Attachments: PropertyUtilsTest.java, temp.java 1) The copyProperties method is documented as throwing IllegalAccessException when access to a particular method is not available. In fact, because internally the methods to be invoked are filtered for accessiblity (MethodUtils.getAccessibleMethod) before invocation, the possible sources of the IllegalAccessException will never actually throw an IllegalAccessException. Worse, however, is that the result of a failure to return an accessible method is actually taken as occasion to throw a NoSuchMethodException instead. 2) The copyProperties method is also documented as throwing NoSuchMethodException when a method cannot be found. I'm not sure if this is an error or not, but a NoSuchMethodException is not thrown when a property of the same name but a different type is found. (This would, to my mind, be an occasion of not finding an appropriate method for the setter to function properly). Unfortunately, again, there is something worse. In this case, instead of throwing NoSuchMethodException, an IllegalArgumentException is thrown. IllegalArgumentException, as a runtime exception, might have been appropriateexcept for the fact that it is explicitly documented as being thrown when either the source or the destination arguments are null - no other reasons for throwing this are detailed. (Wouldn't NullPointerException be more appropriate anyway? Curious about the decision to recast this to IllegalArgumentException) While this is certainly allowed for RuntimeExceptions, in this case, the documentation is quite misleading about what is actually to be expected. I'll attach a JUnitTestCase that captures both of these items. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) [beanutils] Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Attachment: Beanutils-35-updated.patch Attaching updated patch for PropertyUtilsBean's copyProperties() to catch NoSuchMethodException. Because Maps and DynaBeans can be used as a facade to wrap a regular bean I think NoSuchMethodException should be caught in all three cases. [beanutils] Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, Beanutils-35-updated.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation
[ https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512767 ] Niall Pemberton commented on BEANUTILS-91: -- If the proposed changes for BEANUTILS-35 get implemented (catching NoSuchMethodException) then that will mean NoSuchMethodException is not thrown. Plus the use of isReadable() / isWriteable() should mean IllegalAccessException is never thrown as well. Suggest we remove both these exceptions as being declared thrown - is that considered an incompatible change to the method signature? PropertyUtils.copyProperties throws exceptions contrary to documentation Key: BEANUTILS-91 URL: https://issues.apache.org/jira/browse/BEANUTILS-91 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.5 Environment: Operating System: other Platform: Other Reporter: Arun Mammen Thomas Priority: Minor Fix For: 1.8.0 Attachments: PropertyUtilsTest.java, temp.java 1) The copyProperties method is documented as throwing IllegalAccessException when access to a particular method is not available. In fact, because internally the methods to be invoked are filtered for accessiblity (MethodUtils.getAccessibleMethod) before invocation, the possible sources of the IllegalAccessException will never actually throw an IllegalAccessException. Worse, however, is that the result of a failure to return an accessible method is actually taken as occasion to throw a NoSuchMethodException instead. 2) The copyProperties method is also documented as throwing NoSuchMethodException when a method cannot be found. I'm not sure if this is an error or not, but a NoSuchMethodException is not thrown when a property of the same name but a different type is found. (This would, to my mind, be an occasion of not finding an appropriate method for the setter to function properly). Unfortunately, again, there is something worse. In this case, instead of throwing NoSuchMethodException, an IllegalArgumentException is thrown. IllegalArgumentException, as a runtime exception, might have been appropriateexcept for the fact that it is explicitly documented as being thrown when either the source or the destination arguments are null - no other reasons for throwing this are detailed. (Wouldn't NullPointerException be more appropriate anyway? Curious about the decision to recast this to IllegalArgumentException) While this is certainly allowed for RuntimeExceptions, in this case, the documentation is quite misleading about what is actually to be expected. I'll attach a JUnitTestCase that captures both of these items. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Comment: was deleted Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Attachment: (was: Beanutils-35-updated.patch) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Attachment: Beanutils-35-updated.patch Attaching updated patch for PropertyUtilsBean's copyProperties() to catch NoSuchMethodException. Because Maps and DynaBeans can be used as a facade to wrap a regular bean I think NoSuchMethodException should be caught in all three cases. Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, Beanutils-35-updated.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-92: - Attachment: Jira92TestCase.java PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: Beanutils-92-updated.patch, fixCopyPropertyException, Jira92TestCase.java I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-92: - Attachment: (was: Jira35TestCase.java) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: Beanutils-92-updated.patch, fixCopyPropertyException, Jira92TestCase.java I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-92: - Attachment: Beanutils-92-updated.patch Attaching updated patch for PropertyUtilsBean's copyProperties() to catch NoSuchMethodException. Because Maps and DynaBeans can be used as a facade to wrap a regular bean I think NoSuchMethodException should be caught in all three cases. PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: Beanutils-92-updated.patch, fixCopyPropertyException, Jira92TestCase.java I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Comment: was deleted Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Attachment: (was: Beanutils-35-updated.patch) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation
[ https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512767 ] Niall Pemberton edited comment on BEANUTILS-91 at 7/14/07 6:43 PM: --- If the proposed changes for BEANUTILS-92 get implemented (catching NoSuchMethodException) then that will mean NoSuchMethodException is not thrown. Plus the use of isReadable() / isWriteable() should mean IllegalAccessException is never thrown as well. Suggest we remove both these exceptions as being declared thrown - is that considered an incompatible change to the method signature? was: If the proposed changes for BEANUTILS-35 get implemented (catching NoSuchMethodException) then that will mean NoSuchMethodException is not thrown. Plus the use of isReadable() / isWriteable() should mean IllegalAccessException is never thrown as well. Suggest we remove both these exceptions as being declared thrown - is that considered an incompatible change to the method signature? PropertyUtils.copyProperties throws exceptions contrary to documentation Key: BEANUTILS-91 URL: https://issues.apache.org/jira/browse/BEANUTILS-91 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.5 Environment: Operating System: other Platform: Other Reporter: Arun Mammen Thomas Priority: Minor Fix For: 1.8.0 Attachments: PropertyUtilsTest.java, temp.java 1) The copyProperties method is documented as throwing IllegalAccessException when access to a particular method is not available. In fact, because internally the methods to be invoked are filtered for accessiblity (MethodUtils.getAccessibleMethod) before invocation, the possible sources of the IllegalAccessException will never actually throw an IllegalAccessException. Worse, however, is that the result of a failure to return an accessible method is actually taken as occasion to throw a NoSuchMethodException instead. 2) The copyProperties method is also documented as throwing NoSuchMethodException when a method cannot be found. I'm not sure if this is an error or not, but a NoSuchMethodException is not thrown when a property of the same name but a different type is found. (This would, to my mind, be an occasion of not finding an appropriate method for the setter to function properly). Unfortunately, again, there is something worse. In this case, instead of throwing NoSuchMethodException, an IllegalArgumentException is thrown. IllegalArgumentException, as a runtime exception, might have been appropriateexcept for the fact that it is explicitly documented as being thrown when either the source or the destination arguments are null - no other reasons for throwing this are detailed. (Wouldn't NullPointerException be more appropriate anyway? Curious about the decision to recast this to IllegalArgumentException) While this is certainly allowed for RuntimeExceptions, in this case, the documentation is quite misleading about what is actually to be expected. I'll attach a JUnitTestCase that captures both of these items. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-35: - Attachment: BEANUTILS-35-PropertyUtilsBean-getPropertyType.patch I agree there are IMO flaws in how BeanUtilsBean's setProperty() method determines the type to convert to for simple properties that have indexed or mapped descriptors. I started work on a new getPropertyType() method for PropertyUtilsBean that I believe resolves these and could be used to replace that logic in BeanUtilsBean's setProperty() method. Attaching a patch to demonstrate the idea - I haven't yet tested this method or tried plugging it into BeanUtilsBean's setProperty() method. Also need to review if there are any adverse implications on compatibility of implementing this. P.S. If this approach is OK then also use for LocaleBeanUtils. Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, BEANUTILS-35-PropertyUtilsBean-getPropertyType.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
JDBCDynaClass lowerCase option causes problems in RowSetDynaClass --- Key: BEANUTILS-289 URL: https://issues.apache.org/jira/browse/BEANUTILS-289 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Reporter: Niall Pemberton Fix For: 1.8.0 JDBCDynaClass / RowSetDynaClass has an option to convert the column names to lower case when creating the associated DynaProperty - this causea a problem in RowSetDynaClass's rows() method which uses the DynaProperty name to access the column value in the ResultSet. I can only think no-one is really using this since its been this way since created (over 4 years ago) - otherwise everyone is using lower case column names in the database anyway! The proxy TestResultSet and TestResultSetMetaData implementations used by DynaRowSetTestCase are hacked by using normal case in the meta data - but lower case in the result set. Since the DynaProperties are created in column index order - I suggest changing rows() to use the column index, rather than DynaProperty name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512504 ] Niall Pemberton commented on BEANUTILS-142: --- I've added a test case which uses a proxy ResultSetMetaData impl. which returns the wrong class name (i.e. java.sql.Timestamp instead of java.sql.Date) and everything works fine for me. I can only get the ConversionException: Cannot assign value... issue you do when I remove my change to RowSetDynaClass which calls ConvertUtils. So the only explanation I have ATM is that you're using a version of bean utils prior to that change? Also looking at your test results above - there seems to be two issues? 1) Oracles driver is incorrectly returning java.sql.Timestamp as the column class name for date columns (should be java.sql.Date) 2) Oracles driver is incorrectly returning oracle.sql.TIMESTAMP as the column class name for timestamp columns (should be java.sql.Timestamp); So even if my ConvertUtils fix works to stop issue #1 from causing an exception - the end result (java.sql.Timestamp values instead of java.sql.Date in the DynaBean) still seems wrong to me. And for issue #2 we don't have a solution. I would be interested to know what the ResultSetMetaData's getColumnType(idx) returned for the above - since if they return java.sql.Types.DATE and java.sql.Types.TIMESTAMP correctly then we could use that as the basis for a solution? [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver -- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Assignee: Henri Yandell Fix For: 1.8.0 Attachments: Beanutils-142.patch, Play.java Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-289: -- Attachment: beanutils-289.patch JDBCDynaClass lowerCase option causes problems in RowSetDynaClass --- Key: BEANUTILS-289 URL: https://issues.apache.org/jira/browse/BEANUTILS-289 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Reporter: Niall Pemberton Fix For: 1.8.0 Attachments: beanutils-289.patch JDBCDynaClass / RowSetDynaClass has an option to convert the column names to lower case when creating the associated DynaProperty - this causea a problem in RowSetDynaClass's rows() method which uses the DynaProperty name to access the column value in the ResultSet. I can only think no-one is really using this since its been this way since created (over 4 years ago) - otherwise everyone is using lower case column names in the database anyway! The proxy TestResultSet and TestResultSetMetaData implementations used by DynaRowSetTestCase are hacked by using normal case in the meta data - but lower case in the result set. Since the DynaProperties are created in column index order - I suggest changing rows() to use the column index, rather than DynaProperty name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-289: -- Attachment: beanutils-289-revision1.patch Revised patch attached - also affects ResultSetIterator JDBCDynaClass lowerCase option causes problems in RowSetDynaClass --- Key: BEANUTILS-289 URL: https://issues.apache.org/jira/browse/BEANUTILS-289 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Reporter: Niall Pemberton Fix For: 1.8.0 Attachments: beanutils-289-revision1.patch JDBCDynaClass / RowSetDynaClass has an option to convert the column names to lower case when creating the associated DynaProperty - this causea a problem in RowSetDynaClass's rows() method which uses the DynaProperty name to access the column value in the ResultSet. I can only think no-one is really using this since its been this way since created (over 4 years ago) - otherwise everyone is using lower case column names in the database anyway! The proxy TestResultSet and TestResultSetMetaData implementations used by DynaRowSetTestCase are hacked by using normal case in the meta data - but lower case in the result set. Since the DynaProperties are created in column index order - I suggest changing rows() to use the column index, rather than DynaProperty name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-289: -- Attachment: (was: beanutils-289-revision1.patch) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass --- Key: BEANUTILS-289 URL: https://issues.apache.org/jira/browse/BEANUTILS-289 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Reporter: Niall Pemberton Fix For: 1.8.0 Attachments: beanutils-289-revision1.patch JDBCDynaClass / RowSetDynaClass has an option to convert the column names to lower case when creating the associated DynaProperty - this causea a problem in RowSetDynaClass's rows() method which uses the DynaProperty name to access the column value in the ResultSet. I can only think no-one is really using this since its been this way since created (over 4 years ago) - otherwise everyone is using lower case column names in the database anyway! The proxy TestResultSet and TestResultSetMetaData implementations used by DynaRowSetTestCase are hacked by using normal case in the meta data - but lower case in the result set. Since the DynaProperties are created in column index order - I suggest changing rows() to use the column index, rather than DynaProperty name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-289: -- Attachment: beanutils-289-revision1.patch Woops - attaching revised patch again after deleteing it by mistake instead of the older version JDBCDynaClass lowerCase option causes problems in RowSetDynaClass --- Key: BEANUTILS-289 URL: https://issues.apache.org/jira/browse/BEANUTILS-289 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Reporter: Niall Pemberton Fix For: 1.8.0 Attachments: beanutils-289-revision1.patch JDBCDynaClass / RowSetDynaClass has an option to convert the column names to lower case when creating the associated DynaProperty - this causea a problem in RowSetDynaClass's rows() method which uses the DynaProperty name to access the column value in the ResultSet. I can only think no-one is really using this since its been this way since created (over 4 years ago) - otherwise everyone is using lower case column names in the database anyway! The proxy TestResultSet and TestResultSetMetaData implementations used by DynaRowSetTestCase are hacked by using normal case in the meta data - but lower case in the result set. Since the DynaProperties are created in column index order - I suggest changing rows() to use the column index, rather than DynaProperty name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-289: -- Attachment: (was: beanutils-289.patch) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass --- Key: BEANUTILS-289 URL: https://issues.apache.org/jira/browse/BEANUTILS-289 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Reporter: Niall Pemberton Fix For: 1.8.0 Attachments: beanutils-289-revision1.patch JDBCDynaClass / RowSetDynaClass has an option to convert the column names to lower case when creating the associated DynaProperty - this causea a problem in RowSetDynaClass's rows() method which uses the DynaProperty name to access the column value in the ResultSet. I can only think no-one is really using this since its been this way since created (over 4 years ago) - otherwise everyone is using lower case column names in the database anyway! The proxy TestResultSet and TestResultSetMetaData implementations used by DynaRowSetTestCase are hacked by using normal case in the meta data - but lower case in the result set. Since the DynaProperties are created in column index order - I suggest changing rows() to use the column index, rather than DynaProperty name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-142: -- Attachment: beanutils-142-oracle-bug.patch I tested with Oracle (version 10.2.0.1 express edition) and I get the same results as you for the meta data and the types returned by ResultSet getObject() - but I don't see the exception you're getting - the date column is converted to a java.sql.Timestamp. Also the getColumnType(idx) does return the correct types for date and timestamp columns - so this could be used as a solution. Whether we do that or not - IMO we should remove my ConvertUtils change for the reason I put in my previous post. Attaching a patch for possible solution using sql type [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver -- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Assignee: Henri Yandell Fix For: 1.8.0 Attachments: beanutils-142-oracle-bug.patch, Beanutils-142.patch, Play.java Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-289. --- Resolution: Fixed Assignee: Niall Pemberton Implemented something slightly different: http://svn.apache.org/viewvc?view=revrevision=556221 - added a Cross Reference for DynaProperty name to column name to JDBCDynaClass - added lookup methods for column names and values - modified RowSetDynaClass and ResultSetIterator to use the new methods JDBCDynaClass lowerCase option causes problems in RowSetDynaClass --- Key: BEANUTILS-289 URL: https://issues.apache.org/jira/browse/BEANUTILS-289 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: beanutils-289-revision1.patch JDBCDynaClass / RowSetDynaClass has an option to convert the column names to lower case when creating the associated DynaProperty - this causea a problem in RowSetDynaClass's rows() method which uses the DynaProperty name to access the column value in the ResultSet. I can only think no-one is really using this since its been this way since created (over 4 years ago) - otherwise everyone is using lower case column names in the database anyway! The proxy TestResultSet and TestResultSetMetaData implementations used by DynaRowSetTestCase are hacked by using normal case in the meta data - but lower case in the result set. Since the DynaProperties are created in column index order - I suggest changing rows() to use the column index, rather than DynaProperty name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-284) Locale aware Converters doesn't handle conversion direction Object-String
[ https://issues.apache.org/jira/browse/BEANUTILS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-284: -- Fix Version/s: (was: 1.8.0) LATER THAN 1.8.0 The new Object--String conversion used by the ConvertUtilsBean lookup has been made a configurable option for compatibility reasons - so the need to do this is lower and I'm moving this to post 1.8.0 Locale aware Converters doesn't handle conversion direction Object-String --- Key: BEANUTILS-284 URL: https://issues.apache.org/jira/browse/BEANUTILS-284 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: sources from SVN head Reporter: Josef Cacek Assignee: Niall Pemberton Fix For: LATER THAN 1.8.0 Attachments: Test.java Locale aware Converters doesn't handle conversion direction Object-String according to new implementation of lookup method in ConvertUtilsBean class. E.g. BigDecimalLocaleConverter handles conversion String-BigDecimal but not BigDecimal-String -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-10) [beanutils] StringLocaleConverter uses same pattern for numbers and dates
[ https://issues.apache.org/jira/browse/BEANUTILS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-10: - Fix Version/s: (was: 1.8.0) LATER THAN 1.8.0 Affects Version/s: 1.7.0 [beanutils] StringLocaleConverter uses same pattern for numbers and dates - Key: BEANUTILS-10 URL: https://issues.apache.org/jira/browse/BEANUTILS-10 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: Brian Rodgers Fix For: LATER THAN 1.8.0 Attachments: mixed-bean-test.zip StringLocaleConverter doesn't appear to allow for the fact that you need separate patterns when converting a date field than you do when converting a number field. Hence, when copying values from a typed bean to a String bean (such as when copying data into an ActionForm), if the typed bean has both numbers and dates, one or the other will be corrupted. To reproduce: 1. Create a bean that contains a java.util.Date field and a number (any numeric object or primative) field. 2. Create another bean with matching String fields. 3. Populate data into the typed bean from step 1. 4. Register a StringLocaleConverter using a date pattern. 5. User LocalBeanUtils.copyProperties to copy from the typed bean (step 1) to the String bean (step 2). 6. Print the fields in the String bean. The date field will be properly converted, but the number field will be formatted (to the extent that it can be) using the date pattern. Of course, it also works the other way -- specify a number pattern and the date field will be corrupted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-263) Improve ClassConverter robustness
[ https://issues.apache.org/jira/browse/BEANUTILS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-263. --- Resolution: Fixed Assignee: Niall Pemberton Improve ClassConverter robustness - Key: BEANUTILS-263 URL: https://issues.apache.org/jira/browse/BEANUTILS-263 Project: Commons BeanUtils Issue Type: Improvement Components: ConvertUtils Converters Affects Versions: 1.7.0 Reporter: Alex Albu Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 Attachments: ClassConverter.java.patch.txt To load a class by name, ClassConverter attempts to use (in order) the current thread's context class loader and the class loader that loaded the class itself. But in my opinion it is a little inconsistent in the way it does it. Basically, it will use the second class loader as a fallback *only* if the first one (context class loader) is not set (null). That causes the converter to fail in environments where the context class loader is set but does not have access to the class it's trying to load (Weblogic 9.2 is an example). I think a more robust behavior would be to try the second class loader *any* time using the context one fails (be it because it's not set, or it cannot load the class for some reason). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-288) Don't try parsing values that are already Dates/Numbers in Date/Number locale Converters
Don't try parsing values that are already Dates/Numbers in Date/Number locale Converters Key: BEANUTILS-288 URL: https://issues.apache.org/jira/browse/BEANUTILS-288 Project: Commons BeanUtils Issue Type: Improvement Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Fix For: 1.8.0 DateLocaleConverter shouldn't try and parse values that are already Date or Calendar objects DecimalLocaleConverter shouldn't try and parse values that are alreadyjava.lang.Number objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-288) Don't try parsing values that are already Dates/Numbers in Date/Number locale Converters
[ https://issues.apache.org/jira/browse/BEANUTILS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-288. --- Resolution: Fixed Don't try parsing values that are already Dates/Numbers in Date/Number locale Converters Key: BEANUTILS-288 URL: https://issues.apache.org/jira/browse/BEANUTILS-288 Project: Commons BeanUtils Issue Type: Improvement Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Fix For: 1.8.0 DateLocaleConverter shouldn't try and parse values that are already Date or Calendar objects DecimalLocaleConverter shouldn't try and parse values that are alreadyjava.lang.Number objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-271) DateLocaleConverter does not always throw an Exception for invalid dates
[ https://issues.apache.org/jira/browse/BEANUTILS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-271. --- Resolution: Fixed Fixed thanks! DateLocaleConverter does not always throw an Exception for invalid dates Key: BEANUTILS-271 URL: https://issues.apache.org/jira/browse/BEANUTILS-271 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: jdk1.5 Reporter: Nico Hoogervorst Priority: Minor Fix For: 1.8.0 Attachments: DateConverter.java example pattern: MMdd example value : 2007011x is accepted. The 'x' is ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-271) DateLocaleConverter does not always throw an Exception for invalid dates
[ https://issues.apache.org/jira/browse/BEANUTILS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-271: -- Summary: DateLocaleConverter does not always throw an Exception for invalid dates (was: [beanutils] converters - DateLocaleConverter does not always throw an Exception for invalid dates) DateLocaleConverter does not always throw an Exception for invalid dates Key: BEANUTILS-271 URL: https://issues.apache.org/jira/browse/BEANUTILS-271 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: jdk1.5 Reporter: Nico Hoogervorst Priority: Minor Fix For: 1.8.0 Attachments: DateConverter.java example pattern: MMdd example value : 2007011x is accepted. The 'x' is ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-92: - Affects Version/s: (was: Nightly Builds) 1.7.0 Assignee: Niall Pemberton Summary: PropertyUtilsBean.copyProperties does not catch NoSuchMethodException (was: [beanutils] PropertyUtilsBean.copyProperties does not catch NoSuchMethodException) I believe this will be fixed when the proposed changes for BEANUTILS-18 are implemented - will re-check this after that PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: fixCopyPropertyException I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-255) Date and Calendar Converter implementations
[ https://issues.apache.org/jira/browse/BEANUTILS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-255: -- Issue Type: New Feature (was: Bug) Affects Version/s: 1.7.0 Summary: Date and Calendar Converter implementations (was: ConvertUtilsBean does not support converts to a java.util.Date) Date and Calendar Converter implementations --- Key: BEANUTILS-255 URL: https://issues.apache.org/jira/browse/BEANUTILS-255 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.7.0 Reporter: Henri Yandell Assignee: Niall Pemberton Fix For: 1.8.0 It's impossible to convert a String to a java.util.Date (see commons-user mail thread 'Digester and using of java.util.Date'). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-185) Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL
[ https://issues.apache.org/jira/browse/BEANUTILS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-185: -- Issue Type: New Feature (was: Improvement) Summary: Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL (was: New Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL) Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL Key: BEANUTILS-185 URL: https://issues.apache.org/jira/browse/BEANUTILS-185 Project: Commons BeanUtils Issue Type: New Feature Components: DynaBean Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Gabriel Belingueres Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 Attachments: AbstractRowSetDynaClass.java, BasicDirectAccessDynaBean.java, BasicDirectAccessDynaBeanTestCase.java, BasicIndirectAccessDynaBean.java, beanutil-diff.txt, DirectAccessDynaBean.java, DirectRowSetDynaClass.java, DynaBeanMapDecorator.java, DynaBeanMapDecoratorTestCase.java, IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java Hi, I've done some modifications to the beanutils package to better support the use of DynaBeans with the JSTL tags. Some of the changes are discussed in this thread of the commons-user mailing list: http://marc.theaimsgroup.com/?l=jakarta-commons-userm=114669123403779w=2 I attach the diff file that comprises changes to the RowSetDynaClass.java file and build.xml file (since I added a TestCase.) Note: Please try to filter carefully the diffs in the build.xml file since they include some local settings I have for compilation on my machine. :-( Together with the diff file, I attach the new java files added to the package. Regards, Gabriel Belingueres [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-259) Plugable Property Name Expression Resolver
[ https://issues.apache.org/jira/browse/BEANUTILS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-259: -- Issue Type: New Feature (was: Improvement) Plugable Property Name Expression Resolver -- Key: BEANUTILS-259 URL: https://issues.apache.org/jira/browse/BEANUTILS-259 Project: Commons BeanUtils Issue Type: New Feature Components: Expression Syntax Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 Attachments: BasicResolver.java, BasicResolverTestCase.java, Resolver.java There are a number of outstanding bugs against the BeanUtils expression syntax with people wanting BeanUtils to support different variations. There is also a duplication of the expression evaluation code in various methods which can't be tested in isolation and is difficult to maintain as changes have to be applied uniformly to various places. The main places where the code is duplicated: PropertyUtilsBean - getNestedProperty - setNestedProperty - getPropertyDescriptor BeanUtilsBean - copyProperty - setProperty LocaleBeanUtils has also implemented an alternative mechanism - using a Descriptor object to resolve references. BeanUtils and PropertyUtils also work in slightly different ways. There are also other methods (e.g. PropertyUtilsBean's getIndexedProperty() method) which also have related code. I propose to add a new expression resolver interface, which would be a singleton and everywhere would delegate to to resolve property expressions. This will allow easy testing as it can be tested in isolation and provide a uniform mechanism accross BeanUtils. It will also allow alternative syntax to be implemented if the resolver implementation can be configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-254) Run Checkstyle/PMD on the source and get things fixed up
[ https://issues.apache.org/jira/browse/BEANUTILS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-254. --- Resolution: Fixed Assignee: Niall Pemberton Run Checkstyle/PMD on the source and get things fixed up Key: BEANUTILS-254 URL: https://issues.apache.org/jira/browse/BEANUTILS-254 Project: Commons BeanUtils Issue Type: Task Reporter: Henri Yandell Assignee: Niall Pemberton Fix For: 1.8.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-18) [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
[ https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-18: - Attachment: BEANUTILS-18-PropertyUtilsBean.patch As well as PropertyUtilsBean's isReadable() and isWriteable() methods the indexed and mapped get/set methods are also missing the checks that the simple get/set methods use. Attaching a patch for review [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent - Key: BEANUTILS-18 URL: https://issues.apache.org/jira/browse/BEANUTILS-18 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Environment: Operating System: Windows 2000 Platform: PC Reporter: Maarten Coene Fix For: 1.8.0 Attachments: BEANUTILS-18-PropertyUtilsBean.patch, patch-PropertyUtilsBean.txt, patch-PropertyUtilsTestCase.txt, PropertyUtilsTest.java Hi, When the object passed to PropertyUtils is a non-public class, the PropertyUtils.isReadable() method returns true for an existing property while the PropertyUtils.getProperty() method for the same property throws a NoSuchMethodException. I'll attach a junit test that illustrates the problem. regards, Maarten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-41) Provide better error message for No value specified
[ https://issues.apache.org/jira/browse/BEANUTILS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-41: - Issue Type: Improvement (was: Bug) Summary: Provide better error message for No value specified (was: [beanutils] Provide better error message for No value specified) Changing to improvement Provide better error message for No value specified - Key: BEANUTILS-41 URL: https://issues.apache.org/jira/browse/BEANUTILS-41 Project: Commons BeanUtils Issue Type: Improvement Components: ConvertUtils Converters Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Fix For: LATER THAN 1.8.0 Got org.apache.commons.beanutils.ConversionException: No value specified at org.apache.commons.beanutils.converters.SqlDateConverter.convert(SqlDateConverter.java:103) at org.apache.commons.beanutils.BeanUtilsBean.copyProperty(BeanUtilsBean.java:444) at org.apache.commons.beanutils.BeanUtilsBean.copyProperties(BeanUtilsBean.java:261) at org.apache.commons.beanutils.BeanUtils.copyProperties(BeanUtils.java:114) Suggestion: 1) cite the propName and the bean className this probably implies that the interface org.apache.commons.beanutils.Converter.convert(Class type, Object value) is extended to org.apache.commons.beanutils.Converter.convert(Class type, Object value, String propName, String beanClassName) 2) also cite the concerned class name (probably java.sql.Date) 3) mention that there is the possibility to use a default value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-95) Handling exceptions during BeanUtils.populate()
[ https://issues.apache.org/jira/browse/BEANUTILS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-95: - Issue Type: Improvement (was: Bug) Summary: Handling exceptions during BeanUtils.populate() (was: [beanutils] Handling exceptions during BeanUtils.populate()) Changing to improvement Handling exceptions during BeanUtils.populate() --- Key: BEANUTILS-95 URL: https://issues.apache.org/jira/browse/BEANUTILS-95 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Environment: Operating System: other Platform: Other Reporter: Xavier Dury Fix For: LATER THAN 1.8.0 Hi, I know this has been asked already before but could there be a way to handle exceptions that occur during population? The populate() function could either return a map(property, exception), take that kind of map as argument or -even better- take a PopulateExceptionHandler as argument. The reason I would like to see this feature implemented is to allow struts to use this mechanism to convert parameters from the request to actionform's properties without *falling apart* when encountering one that is not well- formed. It would be nice too if we were not *forced* to use string-only properties for actionforms (which in fact is a way to circumvent this conversion problem). I would like my ActionForm or DynaActionForm declare strongly-typed properties (maybe custom classes), register proper Converters into ConvertUtils in the ActionServlet.initServlet() for example, and then maybe get back conversion errors from within my action (maybe the PopulateExceptionHandler could add some ActionErrors to the request). What do you think? I know this issue is tightly coupled to struts but well... ;-) Thanks a lot, Xavier -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-140) LocaleBeanUtils setProperty does not work on nested property
[ https://issues.apache.org/jira/browse/BEANUTILS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-140: -- Assignee: Niall Pemberton Affects Version/s: 1.7.0 Summary: LocaleBeanUtils setProperty does not work on nested property (was: [beanutils] LocaleBeanUtils setProperty does not work on nested property) LocaleBeanUtils setProperty does not work on nested property Key: BEANUTILS-140 URL: https://issues.apache.org/jira/browse/BEANUTILS-140 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: Marco La Porta Assignee: Niall Pemberton Fix For: 1.8.0 LocaleBeanUtils setProperty does not work on nested property. I think the problem is in the method definePropertyType(Object target, String name, String propName). When property is a nested property (prop1.propnested) target is the result of a call of the prop1 getter on the oroginal bean, name is the property name complete (prop1.propnested) and propName is the property name in target object (propnested). At line 601 the property descriptor is defined as descriptor = PropertyUtils.getPropertyDescriptor(target, name); and in case of nested propery it is never found (null) I think the correct line 601 is descriptor = PropertyUtils.getPropertyDescriptor(target, propName); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-140) LocaleBeanUtils setProperty does not work on nested property
[ https://issues.apache.org/jira/browse/BEANUTILS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-140. --- Resolution: Invalid I added a test case for this but can't reproduce this in either the current trunk or BeanUtils 1.7.0 LocaleBeanUtils setProperty does not work on nested property Key: BEANUTILS-140 URL: https://issues.apache.org/jira/browse/BEANUTILS-140 Project: Commons BeanUtils Issue Type: Bug Components: Locale BeanUtils / Converters Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: Marco La Porta Assignee: Niall Pemberton Fix For: 1.8.0 LocaleBeanUtils setProperty does not work on nested property. I think the problem is in the method definePropertyType(Object target, String name, String propName). When property is a nested property (prop1.propnested) target is the result of a call of the prop1 getter on the oroginal bean, name is the property name complete (prop1.propnested) and propName is the property name in target object (propnested). At line 601 the property descriptor is defined as descriptor = PropertyUtils.getPropertyDescriptor(target, name); and in case of nested propery it is never found (null) I think the correct line 601 is descriptor = PropertyUtils.getPropertyDescriptor(target, propName); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-204) [beanutils] LocaleBeanUtils.copyProperties() does not use Locale aware converions
[ https://issues.apache.org/jira/browse/BEANUTILS-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-204: -- Fix Version/s: (was: 1.8.0) LATER THAN 1.8.0 Needs someone to provide a copyProperties() implementation for LocaleBeanUtilsBean (currently just inheriting from BeanUtilsBean) - punting to post 1.8.0 since no one has stepped up to do this. [beanutils] LocaleBeanUtils.copyProperties() does not use Locale aware converions - Key: BEANUTILS-204 URL: https://issues.apache.org/jira/browse/BEANUTILS-204 Project: Commons BeanUtils Issue Type: Improvement Components: Locale BeanUtils / Converters Affects Versions: 1.5 Environment: Operating System: other Platform: Other Reporter: Robert Burrell Donkin Priority: Minor Fix For: LATER THAN 1.8.0 for more details see http://marc.theaimsgroup.com/?l=jakarta-commons-userm=104239393332710w=2 this functionality would be a little tricky to add and can wait until after the 1.6 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-44) FloatLocaleConverter cannot parse negative values
[
https://issues.apache.org/jira/browse/BEANUTILS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-44:
-
Affects Version/s: 1.7.0
Summary: FloatLocaleConverter cannot parse negative values (was:
[beanutils] FloatLocaleConverter cannot parse negative values)
FloatLocaleConverter cannot parse negative values
-
Key: BEANUTILS-44
URL: https://issues.apache.org/jira/browse/BEANUTILS-44
Project: Commons BeanUtils
Issue Type: Bug
Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Environment: Operating System: All
Platform: All
Reporter: Paul Jenkins
Fix For: 1.8.0
Problem found in Build 1.7
LocaleBeanUtils.setProperty(bean, name, value);
Does not handle negative values. When processing negative values the
FloatLocaleConverter.parse(value, pattern) throws a ConversionException
because
of the following if test: -
if(Math.abs(parsed.doubleValue() - parsed.floatValue())
parsed.floatValue() * 0.1) {
throw new ConversionException(...);
}
This test will always fail for a valid negative value because the
multiplication by 0.1 will result in a negative value which will be less
then the abs subtraction.
A solution to this problem would be to check Math.abs(parsed.floatValue() *
0.1)
We also suffer from the previously reported problem of the locale converters
not supporting boolean to get round this problem we have to determine the
property type and call either LocaleBeanUtils.setProperty() or
BeanUtils.setProperty() this would be made easier if the: -
protected Descriptor calculate(Object bean, String name)
method was made public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-44) FloatLocaleConverter cannot parse negative values
[
https://issues.apache.org/jira/browse/BEANUTILS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-44.
--
Resolution: Fixed
Assignee: Niall Pemberton
FloatLocaleConverter cannot parse negative values
-
Key: BEANUTILS-44
URL: https://issues.apache.org/jira/browse/BEANUTILS-44
Project: Commons BeanUtils
Issue Type: Bug
Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Environment: Operating System: All
Platform: All
Reporter: Paul Jenkins
Assignee: Niall Pemberton
Fix For: 1.8.0
Problem found in Build 1.7
LocaleBeanUtils.setProperty(bean, name, value);
Does not handle negative values. When processing negative values the
FloatLocaleConverter.parse(value, pattern) throws a ConversionException
because
of the following if test: -
if(Math.abs(parsed.doubleValue() - parsed.floatValue())
parsed.floatValue() * 0.1) {
throw new ConversionException(...);
}
This test will always fail for a valid negative value because the
multiplication by 0.1 will result in a negative value which will be less
then the abs subtraction.
A solution to this problem would be to check Math.abs(parsed.floatValue() *
0.1)
We also suffer from the previously reported problem of the locale converters
not supporting boolean to get round this problem we have to determine the
property type and call either LocaleBeanUtils.setProperty() or
BeanUtils.setProperty() this would be made easier if the: -
protected Descriptor calculate(Object bean, String name)
method was made public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-233) Update location of dojo compressor library
[ https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511380 ] Niall Pemberton commented on VALIDATOR-233: --- Unfortunately changing the URL in the ant build script (i.e. build-javascript.xml) produces the following error: java.net.UnknownHostException: svn.dojotoolkit.org So it looks like the automated download can't be fixed ATM. I opened a ticket 10 months ago asking dojo to add the jar to the maven repo - but no progress so far: http://trac.dojotoolkit.org/ticket/910 Update location of dojo compressor library -- Key: VALIDATOR-233 URL: https://issues.apache.org/jira/browse/VALIDATOR-233 Project: Commons Validator Issue Type: Task Components: JavaScript Affects Versions: 1.4 Reporter: Paul Benedict Fix For: 1.4 build-javascript.xml no longer has a valid URL to the compressor library. It is now located at: http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511390 ] Niall Pemberton commented on VALIDATOR-232: --- Out of interest what's your use case for this? The only one I've seen in the past is for password fields, where people don't want things such as min/max length and regular expression rules revealed in javascript. One way to do this currently would be to configure additional non-script equivalent validators - or in the case of password validation its probably better to develop a custom password validator. Anyway STR-1888 doesn't give a use-case and its not something that I recall being much requested in Struts - so I'd be interested to hear yours. Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-233) Update location of dojo compressor library
[ https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511429 ] Niall Pemberton commented on VALIDATOR-233: --- Yes sorry, this was a firewall issue on my end Update location of dojo compressor library -- Key: VALIDATOR-233 URL: https://issues.apache.org/jira/browse/VALIDATOR-233 Project: Commons Validator Issue Type: Task Components: JavaScript Affects Versions: 1.4 Reporter: Paul Benedict Fix For: 1.4 build-javascript.xml no longer has a valid URL to the compressor library. It is now located at: http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-233) Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo
[ https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-233: -- Summary: Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo (was: Update location of dojo compressor library) The Dojo Compressor has been added to the maven repo - which is good news since now we can use a versioned version - updating the title of this ticket to reflect that Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo Key: VALIDATOR-233 URL: https://issues.apache.org/jira/browse/VALIDATOR-233 Project: Commons Validator Issue Type: Task Components: JavaScript Affects Versions: 1.4 Reporter: Paul Benedict Fix For: 1.4 build-javascript.xml no longer has a valid URL to the compressor library. It is now located at: http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-233) Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo
[ https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-233: -- Priority: Minor (was: Major) Affects Version/s: (was: 1.4) 1.3.1 Release Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo Key: VALIDATOR-233 URL: https://issues.apache.org/jira/browse/VALIDATOR-233 Project: Commons Validator Issue Type: Task Components: JavaScript Affects Versions: 1.3.1 Release Reporter: Paul Benedict Priority: Minor Fix For: 1.4 build-javascript.xml no longer has a valid URL to the compressor library. It is now located at: http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-233) Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo
[ https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-233. --- Resolution: Fixed Assignee: Niall Pemberton Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo Key: VALIDATOR-233 URL: https://issues.apache.org/jira/browse/VALIDATOR-233 Project: Commons Validator Issue Type: Task Components: JavaScript Affects Versions: 1.3.1 Release Reporter: Paul Benedict Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 build-javascript.xml no longer has a valid URL to the compressor library. It is now located at: http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511455 ] Niall Pemberton commented on VALIDATOR-232: --- Not sure what you mean by Because I don't have this ability, neither do I use javascript at all on my Struts apps - are you saying the lack of this feature prevents you using javascript validation? If theres a bug in one of the javascript validators then people would presumably want to turn it off for all validations of that type (or override it with their own custom javascript version with the bug fixed). I also don't really see how switching on/off individual field's client validation has a use for different intranet/internet deployments. If the only use-case is the password scenario - then IMO would be more useful to provide a password validator (combination of required, mix/max length and mask) than this enhancement. If none of us have any other use case and the users are not clamouring for it - then my preference is to not bother and focus on other things instead. Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-232) Add script attribute to control script generation
[ https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511625 ] Niall Pemberton commented on VALIDATOR-232: --- OK fair enough, not a priority IMO, but if you want it I'll stop arguing :) On the name of the attribute - I agree we shouldn't use script - but I don't really like scripting either and was wondering if we could come up with something better - unfortunately I could only come up with ignoreScript, skipScript, doScript, execScript, useScript, noScript and I'm not sure if they're any better - got any ideas? ATM I'd probably go for noScript. Add script attribute to control script generation - Key: VALIDATOR-232 URL: https://issues.apache.org/jira/browse/VALIDATOR-232 Project: Commons Validator Issue Type: New Feature Components: Framework Reporter: Paul Benedict Priority: Minor Fix For: 1.4 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch Add a script=true|false attribute to field to control whether JavaScript should be generated. Also see: https://issues.apache.org/struts/browse/STR-1888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-273) Public methods overriden in anonymous or private subclasses are not recognized by PropertyUtils
[
https://issues.apache.org/jira/browse/BEANUTILS-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-273.
---
Resolution: Fixed
Assignee: Niall Pemberton
Thanks for taking the time to provide a patch and test case - although I
decided to use a slightly different approach - leave the interface checking
alone and provide and additional check through the parent class hierarchy if
all else failed.
Public methods overriden in anonymous or private subclasses are not
recognized by PropertyUtils
---
Key: BEANUTILS-273
URL: https://issues.apache.org/jira/browse/BEANUTILS-273
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Reporter: Marcelo Liberato
Assignee: Niall Pemberton
Fix For: 1.8.0
Attachments: anonymous-subclass-override-patch.txt
When you do something like:
TestBean anonymous = new TestBean() {
public String getStringProperty() {
return foo;
}
};
PropertyUtils.getProperty(anonymous, stringProperty);
PropertyUtils fails as:
java.lang.NoSuchMethodException: Property 'stringProperty' has no getter
method in class 'class org.apache.commons.beanutils.PropertyUtilsTestCase$1'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-18) [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
[ https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511662 ] Niall Pemberton commented on BEANUTILS-18: -- IMO isReadable() returning true for properties which throw an exception when getProperty() is called is a bug - so I don't agree with Simon that we need to retain backward compatibility - bugs just need to be fixed. I have changes ready to commit for this, but I'll hold off to allow for comments/objections before committing anything. [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent - Key: BEANUTILS-18 URL: https://issues.apache.org/jira/browse/BEANUTILS-18 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Environment: Operating System: Windows 2000 Platform: PC Reporter: Maarten Coene Fix For: 1.8.0 Attachments: patch-PropertyUtilsBean.txt, patch-PropertyUtilsTestCase.txt, PropertyUtilsTest.java Hi, When the object passed to PropertyUtils is a non-public class, the PropertyUtils.isReadable() method returns true for an existing property while the PropertyUtils.getProperty() method for the same property throws a NoSuchMethodException. I'll attach a junit test that illustrates the problem. regards, Maarten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-176) Exception if property doesn't exist in BeanUtilsBean.setProperty()
[ https://issues.apache.org/jira/browse/BEANUTILS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-176: -- Fix Version/s: (was: 1.8.0) LATER THAN 1.8.0 Summary: Exception if property doesn't exist in BeanUtilsBean.setProperty() (was: [beanutils]: Exception if property doesn't exist in BeanUtilsBean.setProperty()) Exception if property doesn't exist in BeanUtilsBean.setProperty() -- Key: BEANUTILS-176 URL: https://issues.apache.org/jira/browse/BEANUTILS-176 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Environment: Operating System: other Platform: Other Reporter: Lars Beuster Priority: Minor Fix For: LATER THAN 1.8.0 I'd like a have an exception thrown if I use BeanUilsBean.setProperty()/populate()/... with an invalid property name, so that I can see immediately if I've done something wrong. An optional boolean parameter for these methods would be nice. Thanks Lars -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-49) Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[
https://issues.apache.org/jira/browse/BEANUTILS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-49.
--
Resolution: Fixed
Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Key: BEANUTILS-49
URL: https://issues.apache.org/jira/browse/BEANUTILS-49
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: Operating System: other
Platform: Other
Reporter: Jesper Richter-Reichhelm
Assignee: Niall Pemberton
Fix For: 1.8.0
Attachments: beanutils-49-ContextClassLoaderLocale.patch,
BEANUTILS-49.patch
Commons Beanutils 1.7 introduced a new problem:
During high traffic times threads begin to wait at the synchronized method
org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
complete thread pool to be used up in our Struts 1.2.7 based web application.
In
our live environment this caused all 70 threads to be blocked by the same
lock.
This behaviour can be easily reproduced by a calling a test JSP provided below
with multiple threads. Using the tool siege to concurrently call the JSP with
two threads is enough to reproduce the lock scenario, the situation gets worse
the more concurrent threads are used (i.e. the throughput decreases).
!-- begin of test JSP --
%@ taglib uri=/struts-logic.tld prefix=logic %
%@ taglib uri=/struts-bean.tld prefix=bean %
%@ taglib uri=/struts-tiles.tld prefix=tiles %
%@ taglib uri=/struts-html.tld prefix=html %
%@ taglib uri=/JLog.tld prefix=jlog %
%@ page import=java.util.*%
%
final long t0 = System.currentTimeMillis();
Collection col = new ArrayList();
for(int i = 0; i5; i++)
{
org.apache.struts.util.LabelValueBean lvb = new
org.apache.struts.util.LabelValueBean(col+i, col+i);
col.add(lvb);
}
pageContext.setAttribute(col, col);
%
logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
name=col id=test2logic:iterate name=col id=test3logic:iterate
name=col id=test3logic:iterate name=col id=test4logic:iterate
name=col id=test4
bean:define id=foo name=test4 property=value/bean:define id=bar
name=test4 property=label/
/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
Finished!
!-- end of test JSP --
A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock
(in
this example with 10 concurrent threads):
siege -c10 -r20 localhost:1701/dcw/test.jsp
= Thread dump is full with threads like this:
ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
at
org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- waiting to lock 0x6c86eab0 (a java.lang.Class)
at
org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
at
org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
at jsp_servlet.__test._jspService(__test.java:309)
...
This behaviour is new to version 1.7. The same test using Commons Beanutils
1.6.1 showed no problems: By falling back to the old version we could
temporarily solve our live problems and could continue to use Struts 1.2.7.
Nevertheless this should be fixed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-251) PropertyUtils.describe() returns wrong fields names
[
https://issues.apache.org/jira/browse/BEANUTILS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-251.
---
Resolution: Invalid
PropertyUtils.describe() returns wrong fields names
---
Key: BEANUTILS-251
URL: https://issues.apache.org/jira/browse/BEANUTILS-251
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: WinXP SP2
Reporter: Oleg Timoshenko
Assignee: Henri Yandell
Fix For: 1.8.0
I have the following bean:
public class SumTestBean2 {
private int iVal;
public int getIVal() {
return iVal;
}
public void setIVal(int val) {
iVal = val;
}
}
... and the following snippet of code:
SumTestBean2 stb = new SumTestBean2();
stb.setIVal(12);
Map map = PropertyUtils.describe(stb);
for(Object o : map.keySet()) System.out.println(o);
.. prints out the following:
IVal
class
Note that instead of IVal there should be iVal - uppercase letter appears
instead of lowercase.
This happens only when field has first letter - in lower case followed by
uppercase letter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-156) Memory leak on webapp undeploy in MappedPropertyDescriptor
[ https://issues.apache.org/jira/browse/BEANUTILS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-156: -- Summary: Memory leak on webapp undeploy in MappedPropertyDescriptor (was: [beanutils] Memory leak on webapp undeploy in MappedPropertyDescriptor) Memory leak on webapp undeploy in MappedPropertyDescriptor -- Key: BEANUTILS-156 URL: https://issues.apache.org/jira/browse/BEANUTILS-156 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Simon Kitching Assignee: Niall Pemberton Fix For: 1.8.0 Class MappedPropertyDescriptor has a Hashtable declaredMethodCache containing a mapping from Class to Method[]. If this class were to be deployed via a shared webapp, then any reference in there to a class loaded via the webapp classloader will prevent the webapp classloader from being garbage-collected when the webapp is undeployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-156) Memory leak on webapp undeploy in MappedPropertyDescriptor
[ https://issues.apache.org/jira/browse/BEANUTILS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-156. --- Resolution: Fixed Memory leak on webapp undeploy in MappedPropertyDescriptor -- Key: BEANUTILS-156 URL: https://issues.apache.org/jira/browse/BEANUTILS-156 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Simon Kitching Assignee: Niall Pemberton Fix For: 1.8.0 Class MappedPropertyDescriptor has a Hashtable declaredMethodCache containing a mapping from Class to Method[]. If this class were to be deployed via a shared webapp, then any reference in there to a class loaded via the webapp classloader will prevent the webapp classloader from being garbage-collected when the webapp is undeployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-157) Beanutils's describe() method cannot determine reader methods for anonymous class
[
https://issues.apache.org/jira/browse/BEANUTILS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-157:
--
Assignee: Niall Pemberton
Priority: Minor (was: Major)
Affects Version/s: 1.6.1
Summary: Beanutils's describe() method cannot determine reader
methods for anonymous class (was: [beanutils] 1.6.1 cannot determine reader
methods for anonymous class)
Beanutils's describe() method cannot determine reader methods for anonymous
class
-
Key: BEANUTILS-157
URL: https://issues.apache.org/jira/browse/BEANUTILS-157
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.6.1
Environment: Operating System: Windows XP
Platform: PC
Reporter: Thorbjørn Ravn Andersen
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.8.0
I have the following snippet in a JSP-page which uses BeanUtils 1.6.1 and I
get
an exception.
Code snippet (the anonymous class is to get a JavaBean defined in the
JSP-page):
---
List l = new ArrayList();
for(int i = 1; i 10; i++) {
final int i2 = i;
Object o = new Serializable() {
String x = + i2;
String y = + (100+i2) ;
public String getX() {
return x;
}
public String getY() {
return y;
}
public String toString() {
return getX() + + getY();
}
};
l.add(o);
Map map = BeanUtils.describe(o);
---
which gives me the following exception:
---
javax.servlet.ServletException: Property 'y' has no getter method
at
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:825)
at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:758)
at org.apache.jsp.main_jsp._jspService(main_jsp.java:257)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:474)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312)
at
com.transaxiom.axsWHSweb.servlet.GetCurrentStock.doPost(GetCurrentStock.java:31)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jira] Updated: (BEANUTILS-61) PropertyUtilsBean isReadable() and isWriteable() methods do not work correctly for WrapDynaBean
[
https://issues.apache.org/jira/browse/BEANUTILS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-61:
-
Assignee: Niall Pemberton
Summary: PropertyUtilsBean isReadable() and isWriteable() methods do not
work correctly for WrapDynaBean (was: [beanutils] PropertyUtilsBean does not
work correctly for WrapDynaBean)
PropertyUtilsBean isReadable() and isWriteable() methods do not work
correctly for WrapDynaBean
---
Key: BEANUTILS-61
URL: https://issues.apache.org/jira/browse/BEANUTILS-61
Project: Commons BeanUtils
Issue Type: Bug
Components: DynaBean
Affects Versions: Nightly Builds
Environment: Operating System: other
Platform: All
Reporter: Brian Ewins
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.8.0
Try this: given any pojo class MyBean.java,
MyBean orig = new MyBean();
MyBean dest = new MyBean();
DynaBean db = new WrapDynaBean(dest);
PropertyUtils.copyProperties(db, orig);
You'll see an exception like:
java.lang.IllegalArgumentException: Property 'class' has no write method
at
org.apache.commons.beanutils.WrapDynaBean.set(WrapDynaBean.java:266)
This surprised me because 'copyProperties()' does an 'isWritable()' check
before
it sets properties. However, what PropertyUtilsBean.isWritable actually does
is
this:
if (bean instanceof DynaBean) {
// All DynaBean properties are writeable
return (((DynaBean) bean).getDynaClass().getDynaProperty(name) !=
null);
} ...
That's plainly wrong for a WrapDynaBean, since pretty much every wrapped
object
has a non-writable 'class' property.
A workaround for the immediate problem:
if (db instanceof WrapDynaBean) {
PropertyUtils.copyProperties(((WrapDynaBean) db).getInstance(), src);
} else {
PropertyUtils.copyProperties(dest, src);
}
... the problem affects isReadable and isWritable, and hence copyProperties;
to
fix it for all cases would (I think) require unwrapping any WrapDynaBeans
passed
into those calls.
I guess having a situation where you'd use PropertyUtils /and/ WrapDynaBeans
is
fairly unusual so this is just a minor bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-61) PropertyUtilsBean isReadable() and isWriteable() methods do not work correctly for WrapDynaBean
[
https://issues.apache.org/jira/browse/BEANUTILS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-61.
--
Resolution: Fixed
I have made the following changes:
PropertyUtilsBean:
- isReadable() and isWriteable() methods now unwrap any WrapDynaBean as
you suggest.
- copyProperties() now checks isReadable() when the source is a DynaBean
(it already checked isWriteable() for target DynaBean)
BeanUtilsBean
- copyProperties() now checks isReadable() when the source is a DynaBean
(it already checked isWriteable() for target DynaBean)
http://svn.apache.org/viewvc?view=revrevision=553357
PropertyUtilsBean isReadable() and isWriteable() methods do not work
correctly for WrapDynaBean
---
Key: BEANUTILS-61
URL: https://issues.apache.org/jira/browse/BEANUTILS-61
Project: Commons BeanUtils
Issue Type: Bug
Components: DynaBean
Affects Versions: Nightly Builds
Environment: Operating System: other
Platform: All
Reporter: Brian Ewins
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.8.0
Try this: given any pojo class MyBean.java,
MyBean orig = new MyBean();
MyBean dest = new MyBean();
DynaBean db = new WrapDynaBean(dest);
PropertyUtils.copyProperties(db, orig);
You'll see an exception like:
java.lang.IllegalArgumentException: Property 'class' has no write method
at
org.apache.commons.beanutils.WrapDynaBean.set(WrapDynaBean.java:266)
This surprised me because 'copyProperties()' does an 'isWritable()' check
before
it sets properties. However, what PropertyUtilsBean.isWritable actually does
is
this:
if (bean instanceof DynaBean) {
// All DynaBean properties are writeable
return (((DynaBean) bean).getDynaClass().getDynaProperty(name) !=
null);
} ...
That's plainly wrong for a WrapDynaBean, since pretty much every wrapped
object
has a non-writable 'class' property.
A workaround for the immediate problem:
if (db instanceof WrapDynaBean) {
PropertyUtils.copyProperties(((WrapDynaBean) db).getInstance(), src);
} else {
PropertyUtils.copyProperties(dest, src);
}
... the problem affects isReadable and isWritable, and hence copyProperties;
to
fix it for all cases would (I think) require unwrapping any WrapDynaBeans
passed
into those calls.
I guess having a situation where you'd use PropertyUtils /and/ WrapDynaBeans
is
fairly unusual so this is just a minor bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VALIDATOR-231) Missing unit tests using maven
[ https://issues.apache.org/jira/browse/VALIDATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved VALIDATOR-231. --- Resolution: Invalid MultipleTests has already been renamed to MultipleTest in January (revision 493905) Missing unit tests using maven -- Key: VALIDATOR-231 URL: https://issues.apache.org/jira/browse/VALIDATOR-231 Project: Commons Validator Issue Type: Bug Affects Versions: 1.3.1 Release Reporter: Gail Badner The maven build uses the file pattern **/*Test.java, so it misses org.apache.commons.validator.MultipleTests. This test is run when using ant. MultipleTests should probably be renamed to MultipleTest. When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-287) Missing unit tests using ant and unit test errors using maven
[ https://issues.apache.org/jira/browse/BEANUTILS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509964 ] Niall Pemberton commented on BEANUTILS-287: --- -1 to generating the build.xml using maven ant - IMO it creates a right mess and theres no point ruining a working ant build.xml Missing unit tests using ant and unit test errors using maven -- Key: BEANUTILS-287 URL: https://issues.apache.org/jira/browse/BEANUTILS-287 Project: Commons BeanUtils Issue Type: Bug Affects Versions: 1.7.0 Reporter: Gail Badner When running unit tests with ant, 402 tests are executed and all are successful. The following test cases are are not executed with ant: ConstructorUtilsTestCase FileConverterTestCase URLConverterTestCase When running unit tests with maven, 413 tests are executed, but 2 fail: BeanificationTestCase.testMemoryTestMethodology LocaleBeanificationTestCase.testMemoryTestMethodology Both errors are due to java.lang.ClassNotFoundException: org.apache.commons.beanutils.BetaBean When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509364 ] Niall Pemberton commented on BEANUTILS-285: --- OK I have reverted the behaviour in BeanUtils (and Martin's change to betwixt, as the method used by betwixt is now nack to how it was in BeanUtils 1.7.0). If I find the time and desire to provide the new behaviour I'll do it as new additional implementations (BeanUtilsBean2 / ConvertUtilsBean2) that people can chose to configure if they want. BeanUtils: http://svn.apache.org/viewvc?view=revrevision=552279 Betwixt: http://svn.apache.org/viewvc?view=revrevision=552283 Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-178) New implementation in commons-beanutils
[ https://issues.apache.org/jira/browse/BEANUTILS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-178: -- Fix Version/s: (was: 1.8.0) LATER THAN 1.8.0 Punting to post 1.8.0 The issue with swallowing the SQLExcepton in the createDynaProperty() method still exists - although its been refactored into JDBCDynaClass New implementation in commons-beanutils --- Key: BEANUTILS-178 URL: https://issues.apache.org/jira/browse/BEANUTILS-178 Project: Commons BeanUtils Issue Type: Improvement Components: DynaBean Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Fabio Lourencetti Gonçalves Priority: Minor Fix For: LATER THAN 1.8.0 typing... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-285. --- Resolution: Fixed Fix Version/s: 1.8.0 I have added new BeanUtilsBean (BeanUtilsBean2) and ConvertUtilsBean (ConvertUtilsBean2) implementations which take full davantage of the improved Converter implementations. The default behaviour is compatible with BeanUtils 1.7.0, but these new implementations can be configured by calling BeanUtilsBean.setInstance(new BeanUtilsBean2()). http://svn.apache.org/viewvc?view=revrevision=552381 Closing this as resolved Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-247) Arrays with multiple dimension are not supported
[ https://issues.apache.org/jira/browse/BEANUTILS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-247. --- Resolution: Fixed Assignee: Niall Pemberton Also see BEANUTILS-43 (improved mapped property support) Arrays with multiple dimension are not supported Key: BEANUTILS-247 URL: https://issues.apache.org/jira/browse/BEANUTILS-247 Project: Commons BeanUtils Issue Type: Bug Components: Expression Syntax Affects Versions: 1.7.0 Environment: I run BeanUtils on Windows XP with Eclipse 3.1.1. Reporter: Christian Poitras Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: beanerror.zip, PropertyUtilsBean.java When an array with multiple dimension is used, accessing and setting properties is not supported. For instance, the call to PropertyUtils.getNestedProperty(myObject, multiArray[0][0].id) fails since the second array index is never used. This raises the following exception. Exception in thread main java.lang.NoSuchMethodException: Unknown property 'id' at org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1122) at org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:686) at org.apache.commons.beanutils.PropertyUtils.getNestedProperty(PropertyUtils.java:272) at Test.main(Test.java:24) The id property does exists in the object multiArray[0][0] and if I make a call to multiArray[0][0].getId(), the correct value is returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-43) Mapped property inside a mapped property is not populated on submit
[ https://issues.apache.org/jira/browse/BEANUTILS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-43. -- Resolution: Fixed Assignee: Niall Pemberton Also see BEANUTILS-247 (improved indexed property support) Mapped property inside a mapped property is not populated on submit --- Key: BEANUTILS-43 URL: https://issues.apache.org/jira/browse/BEANUTILS-43 Project: Commons BeanUtils Issue Type: Bug Components: Expression Syntax Affects Versions: 1.7.0 Environment: Operating System: Windows XP Platform: PC Reporter: Firepica Assignee: Niall Pemberton Fix For: 1.8.0 Hi, everyone. Suppose, I have a Map in my form, called person: private Map person; That Map has (besides other entries), a entry called addresses, which is in turn a Map again. This addresses Map has several addresses of the person. One of those addresses has key home and String value of home address. I want to render a text input field for the home address - I use EL syntax, no brackets (it renders element correctly): nested:text property=person.addresses.home/ In html this element is _being rendered correctly_, including correctly displayed value of home address, taken from the addresses Map. However, if I submit this form with changed value of address, it's not being populated. I wrote my own implementation of addresses Map to see what's happening, and I saw that no put method is called at all (only get() while rendering the element). So then I also made custom implementation of person Map and saw there, that while submitting, it calls get(addresses) (which returns addresses Map) and that's all. So apparently, BeanUtils sees, that it retrieved a Map and stops processing, not generating any exceptions BTW. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-113) [beanutils] Indexed property inside a mapped property cannot be accessed
[ https://issues.apache.org/jira/browse/BEANUTILS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-113. --- Resolution: Fixed Resolved by the changes for BEANUTILS-247 (improved indexed property support) and BEANUTILS-43 (improved mapped property support). [beanutils] Indexed property inside a mapped property cannot be accessed Key: BEANUTILS-113 URL: https://issues.apache.org/jira/browse/BEANUTILS-113 Project: Commons BeanUtils Issue Type: Bug Components: Expression Syntax Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Firepica Fix For: 1.8.0 Hi, guys. Suppose I have a Map, let's call it building, inside that map I have an entry with key rooms, which is a Collection. If I try to access room number 20 like this: building.rooms[20].type it doesn't work (throws IllegalArgumentException). I made a custom implementation of building Map so that I can see what param is passed to the get() method. Surprisingly I see, that PropertyUtilsBean.getInstance().getProperty(bean, name) calls get() method on my Map with parameter rooms[20] (including index part). This is definitely a bug, because getProperty() should recognize, that rooms is an indexed property (because it has []), so it should cut off [20], call get(rooms) and then obtain element with index 20 from the retrieved Collection. Please have a look. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-215) BeanUtilsBean: Set a mapped/indexed property, for example property(time)[0]
[
https://issues.apache.org/jira/browse/BEANUTILS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-215.
---
Resolution: Duplicate
Resolved by the changes for BEANUTILS-247 (improved indexed property support)
and BEANUTILS-43 (improved mapped property support).
BeanUtilsBean: Set a mapped/indexed property, for example property(time)[0]
-
Key: BEANUTILS-215
URL: https://issues.apache.org/jira/browse/BEANUTILS-215
Project: Commons BeanUtils
Issue Type: Improvement
Components: Expression Syntax
Environment: Operating System: other
Platform: Other
Reporter: Ludwig Wensauer
Priority: Minor
Fix For: 1.8.0
Attachments: BEANUTILS-215.patch
From line 1014 ff there is the following piece of code:
try {
if (index = 0) {
getPropertyUtils().setIndexedProperty(target, propName,
index, newValue);
} else if (key != null) {
getPropertyUtils().setMappedProperty(target, propName,
key, newValue);
} else {
getPropertyUtils().setProperty(target, propName, newValue);
}
...
That's good for mapped OR indexed properties, but unfortunatly i have both at
the same time. So index is = 0 and key is also != null.
My property-name looks like this one here:
property(time)[0]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-171) [beanutils] Nested Bean Collection
[ https://issues.apache.org/jira/browse/BEANUTILS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-171. --- Resolution: Duplicate [beanutils] Nested Bean Collection -- Key: BEANUTILS-171 URL: https://issues.apache.org/jira/browse/BEANUTILS-171 Project: Commons BeanUtils Issue Type: Improvement Components: Expression Syntax Affects Versions: 1.1 Environment: Operating System: All Platform: All Reporter: scott sadlo Priority: Minor Fix For: 1.8.0 I work for a company currently using struts. Struts relies upon Commons Bean Utilities. My enhancement involves the setting of values in Collection properties of a bean. In struts, i create an HTML input element with the name syntax property_of_the_bean[0] where [0] indicates which element of the collection will have its setProperty_of_the_bean() method called. The issue is with nested Collections. I would like to be able to set my HTML input element name to match the form property_of_the_bean[x][y] so that the setProperty_of_the_bean() method of the Yth bean of the collection from the Xth bean of the last parent's collection will be called. Can you please respond to my inquiry stating your understanding of my wishes and any possible suggestions for action? Thank You. Sincerely, sjs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-211) [beanutils] Multiple mapped properties not possible / Direct maps and indexes not possible
[ https://issues.apache.org/jira/browse/BEANUTILS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-211. --- Resolution: Duplicate Resolved by the changes for BEANUTILS-247 (improved indexed property support) and BEANUTILS-43 (improved mapped property support). [beanutils] Multiple mapped properties not possible / Direct maps and indexes not possible -- Key: BEANUTILS-211 URL: https://issues.apache.org/jira/browse/BEANUTILS-211 Project: Commons BeanUtils Issue Type: Improvement Components: Expression Syntax Affects Versions: Nightly Builds Environment: Operating System: other Platform: All Reporter: Thomas Jacob Priority: Minor Fix For: 1.8.0 Within a property of any tag, it is not possible to map twice, such as property=customers(5)(3), or to map and index (property=customers(5)[3]. This is sometimes useful. Workarounds with bean:define are difficult, because the property tag is not able to map or index a Map or Collection directly, such as name=customers property=(3). This would be nice, too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-49) Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
[
https://issues.apache.org/jira/browse/BEANUTILS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509489
]
Niall Pemberton commented on BEANUTILS-49:
--
Where are we at with this? I agree with you improvments without numbers is not
good and like you am not 100% happy with the patch. IMO we should just leave it
for now at removing the uncessary synchronization that Kenneth Xu suggested
(already committed). We could punt for review again post 1.8.0.
Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
Key: BEANUTILS-49
URL: https://issues.apache.org/jira/browse/BEANUTILS-49
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: Operating System: other
Platform: Other
Reporter: Jesper Richter-Reichhelm
Assignee: Niall Pemberton
Fix For: 1.8.0
Attachments: beanutils-49-ContextClassLoaderLocale.patch,
BEANUTILS-49.patch
Commons Beanutils 1.7 introduced a new problem:
During high traffic times threads begin to wait at the synchronized method
org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
complete thread pool to be used up in our Struts 1.2.7 based web application.
In
our live environment this caused all 70 threads to be blocked by the same
lock.
This behaviour can be easily reproduced by a calling a test JSP provided below
with multiple threads. Using the tool siege to concurrently call the JSP with
two threads is enough to reproduce the lock scenario, the situation gets worse
the more concurrent threads are used (i.e. the throughput decreases).
!-- begin of test JSP --
%@ taglib uri=/struts-logic.tld prefix=logic %
%@ taglib uri=/struts-bean.tld prefix=bean %
%@ taglib uri=/struts-tiles.tld prefix=tiles %
%@ taglib uri=/struts-html.tld prefix=html %
%@ taglib uri=/JLog.tld prefix=jlog %
%@ page import=java.util.*%
%
final long t0 = System.currentTimeMillis();
Collection col = new ArrayList();
for(int i = 0; i5; i++)
{
org.apache.struts.util.LabelValueBean lvb = new
org.apache.struts.util.LabelValueBean(col+i, col+i);
col.add(lvb);
}
pageContext.setAttribute(col, col);
%
logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
name=col id=test2logic:iterate name=col id=test3logic:iterate
name=col id=test3logic:iterate name=col id=test4logic:iterate
name=col id=test4
bean:define id=foo name=test4 property=value/bean:define id=bar
name=test4 property=label/
/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
Finished!
!-- end of test JSP --
A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock
(in
this example with 10 concurrent threads):
siege -c10 -r20 localhost:1701/dcw/test.jsp
= Thread dump is full with threads like this:
ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
at
org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
- waiting to lock 0x6c86eab0 (a java.lang.Class)
at
org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
at
org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
at
org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
at jsp_servlet.__test._jspService(__test.java:309)
...
This behaviour is new to version 1.7. The same test using Commons Beanutils
1.6.1 showed no problems: By falling back to the old version we could
temporarily solve our live problems and could continue to use Struts 1.2.7.
Nevertheless this should be fixed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-251) PropertyUtils.describe() returns wrong fields names
[
https://issues.apache.org/jira/browse/BEANUTILS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509490
]
Niall Pemberton commented on BEANUTILS-251:
---
Henri, do you have time/plans to do the FAQ or can we just close as invalid (or
punt to post 1.8.0)?
PropertyUtils.describe() returns wrong fields names
---
Key: BEANUTILS-251
URL: https://issues.apache.org/jira/browse/BEANUTILS-251
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: WinXP SP2
Reporter: Oleg Timoshenko
Assignee: Henri Yandell
Fix For: 1.8.0
I have the following bean:
public class SumTestBean2 {
private int iVal;
public int getIVal() {
return iVal;
}
public void setIVal(int val) {
iVal = val;
}
}
... and the following snippet of code:
SumTestBean2 stb = new SumTestBean2();
stb.setIVal(12);
Map map = PropertyUtils.describe(stb);
for(Object o : map.keySet()) System.out.println(o);
.. prints out the following:
IVal
class
Note that instead of IVal there should be iVal - uppercase letter appears
instead of lowercase.
This happens only when field has first letter - in lower case followed by
uppercase letter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-176) [beanutils]: Exception if property doesn't exist in BeanUtilsBean.setProperty()
[ https://issues.apache.org/jira/browse/BEANUTILS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509491 ] Niall Pemberton commented on BEANUTILS-176: --- Without a patch/tests I propose we punt this to post 1.8.0 [beanutils]: Exception if property doesn't exist in BeanUtilsBean.setProperty() --- Key: BEANUTILS-176 URL: https://issues.apache.org/jira/browse/BEANUTILS-176 Project: Commons BeanUtils Issue Type: Improvement Components: Bean / Property Utils Environment: Operating System: other Platform: Other Reporter: Lars Beuster Priority: Minor Fix For: 1.8.0 I'd like a have an exception thrown if I use BeanUilsBean.setProperty()/populate()/... with an invalid property name, so that I can see immediately if I've done something wrong. An optional boolean parameter for these methods would be nice. Thanks Lars -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CHAIN-38) Unable to select file system resource at org.apache.commons.chain.web.ChainListener
[ https://issues.apache.org/jira/browse/CHAIN-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509219 ] Niall Pemberton commented on CHAIN-38: -- Hi Julio Thanks for the patch - tests for your new parseFileResources() methods in ChainResources would be really good. Niall Unable to select file system resource at org.apache.commons.chain.web.ChainListener --- Key: CHAIN-38 URL: https://issues.apache.org/jira/browse/CHAIN-38 Project: Commons Chain Issue Type: Improvement Affects Versions: 1.2 Reporter: Julio Shnaider Gejer Priority: Minor Attachments: chain-38-patch.diff The commons-chain listener (org.apache.commons.chain.web.ChainListener) that can be configured at web.xml only accept files that are relative to web application directory or classpath directory. It'll be very useful if we can use file system resources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated BEANUTILS-285: -- Attachment: betwixt-beanutils-gump-fix.patch Attaching a patch for Betwixt for mvdb to review that fixes the gump failures Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509228 ] Niall Pemberton commented on BEANUTILS-285: --- I understand you're trying to avoid issues - but the more I think about it the more issues I see. I believe you're probably creating as many issues(if not more) as you're resolving. For example the BeanUtils DoubleConverter can now be configured for a French Locale - using a comma as the decimal separtor. It would convert to and from a String value using a comma. Problem now is for betwixt - conversion from String to BigDecimal by DoubleConverter would expect a comma - which if DoubleConverter had handled the conversion to a String it would have - in Betwixt though it will delegate the conversion to String to the converter registered for Strng - which the default registerd implementation would just use the Double's toString() method (and therefore have a period for the decimal separator). Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (BEANUTILS-286) New Facade converter implementation - hide non-Converter public APIs
New Facade converter implementation - hide non-Converter public APIs Key: BEANUTILS-286 URL: https://issues.apache.org/jira/browse/BEANUTILS-286 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 Provide a facade Converter implementation that delegates to a specified Converter, but hides any public API other than that defined in the Converter interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-286) New Facade converter implementation - hide non-Converter public APIs
[ https://issues.apache.org/jira/browse/BEANUTILS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-286. --- Resolution: Fixed Added the new implementation and wrapped the set of standard registered converters New Facade converter implementation - hide non-Converter public APIs Key: BEANUTILS-286 URL: https://issues.apache.org/jira/browse/BEANUTILS-286 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.7.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.8.0 Provide a facade Converter implementation that delegates to a specified Converter, but hides any public API other than that defined in the Converter interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-344) CollatorUtils - equivalent of StringUtils, but using Collators
CollatorUtils - equivalent of StringUtils, but using Collators -- Key: LANG-344 URL: https://issues.apache.org/jira/browse/LANG-344 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Stephen Kestle has pointed out that equalsIgnoreCase is an English/ASCII hack and that using the Collator class provides a more robust String comparison mechanism. - Most recently this came up when adding new ignore case methods to StringUtils for LANG-326 (also http://tinyurl.com/3d2jjk ) - Raised in regarding case insensitivity for EqualsBuilder and HashCodeBuilder in LANG-316 Creating this issue ticket so this doesn't get forgotten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509246 ] Niall Pemberton commented on LANG-326: -- OK patch applied - just noticed the fix version is 3.0 - is that the next planned release? - I've used @since Lang 2.4 in the JavaDoc for new methods StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508854 ] Niall Pemberton commented on LANG-326: -- Its been a while since I posted this - in the absence of anyone stepping with alternatives [CaseInsensitiveStringUtils / Collators] I plan to commit this unless someone objects StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508954 ] Niall Pemberton commented on LANG-326: -- I implemented these methods using str.regionMatches() with brevity and correctness in mind and not optimization. Looking at other existing case insensitive String comparrison implementations in StringUtils - they achieved brevity by using str.toUpperCase() and then calling the case sensitive flavour of the method. IMO these are not quite correct since the case insensitive functionality provided by the String class (which IMO StringUtils should be compatible with) do more than that (with a comment that upper case comparison has issues with the Georgian alphabet). Using regionMatches() allowed the same code to be (re-)used for both the case sensitive and insensitive implementations and for them to be compatible with the case insensitive functionality provided by String. So optimization was just a nice by-product. On your Collator implementation IMO it would be better as a new utility class for those that need that functionality (I18NStringUtils?) - which would give people a choice and ties in nicely with what java provides - i.e. a choice of 2 different mechanisms. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508623 ] Niall Pemberton commented on BEANUTILS-142: --- Thanks for spotting this - I've corrected this so should be available in the next (20060728) nightly build [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver -- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Fix For: 1.8.0 Attachments: Beanutils-142.patch Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BEANUTILS-282) BigDecimalLocaleConverter returns Long object
[
https://issues.apache.org/jira/browse/BEANUTILS-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-282.
---
Resolution: Duplicate
Fix Version/s: 1.8.0
BigDecimalLocaleConverter returns Long object
-
Key: BEANUTILS-282
URL: https://issues.apache.org/jira/browse/BEANUTILS-282
Project: Commons BeanUtils
Issue Type: Bug
Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Reporter: Josef Cacek
Fix For: 1.8.0
BigDecimalLocaleConverter returns Long object instead of BigDecimal when no
decimal places are in the parsed number.
Problem is in the method DecimalLocaleConverter.parse(Object, String) which
uses DecimalFormat.getInstance(locale).parse(String). The getInstance method
is factory method from NumberFormat and not DecimalFormat, so there is no
guarantee of returned type.
Here is the sample which shows the problem:
import java.math.BigDecimal;
import java.text.NumberFormat;
import java.util.Locale;
import
org.apache.commons.beanutils.locale.converters.BigDecimalLocaleConverter;
public class Test {
public static void main(String args[]) {
Locale tmpLoc = new Locale(de,AT);
NumberFormat nf = NumberFormat.getNumberInstance(tmpLoc);
String tmpNr = nf.format(new BigDecimal(5));
BigDecimalLocaleConverter tmpBdlc = new
BigDecimalLocaleConverter(tmpLoc);
Object tmpConverted = tmpBdlc.convert(tmpNr);
System.out.println(String value: + tmpNr);
System.out.println(Number value: + tmpConverted);
System.out.println(tmpConverted==null?No class:Class: +
tmpConverted.getClass());
}
}
Output is:
String value: 5
Number value: 5
Class: class java.lang.Long
Correct handling is implemented e.g. in BigDecimalValidator class of
commons-validator package. It uses an additional method processParsedValue to
convert number to the right type:
/**
* Convert the parsed value to a codeBigDecimal/code.
*
* @param value The parsed codeNumber/code object created.
* @param formatter The Format used to parse the value with.
* @return The parsed codeNumber/code converted to a
* codeBigDecimal/code.
*/
protected Object processParsedValue(Object value, Format formatter) {
BigDecimal decimal = null;
if (value instanceof Long) {
decimal = BigDecimal.valueOf(((Long)value).longValue());
} else {
decimal = new BigDecimal(value.toString());
}
int scale = determineScale((NumberFormat)formatter);
if (scale = 0) {
decimal = decimal.setScale(scale, BigDecimal.ROUND_DOWN);
}
return decimal;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508634 ] Niall Pemberton commented on BEANUTILS-142: --- OK I don't have strong opnions on this issue - in the absence of other opnions I'll leave the change I committed accidently in. If anyone thinks that it should be removed then I don't have a problem with that either. Either way (or alternative solutions) I'd like to get to a point where we can close this. P.S. dyna bean - please don't delete previous comments you made - it makes the thread of comment confusing [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver -- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Fix For: 1.8.0 Attachments: Beanutils-142.patch Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MODELER-22) ant.properties is missing from the Modeler jar
ant.properties is missing from the Modeler jar -- Key: MODELER-22 URL: https://issues.apache.org/jira/browse/MODELER-22 Project: Commons Modeler Issue Type: Bug Affects Versions: 2.0 Reporter: Niall Pemberton Priority: Minor Fix For: 2.1 ant.properties is missing from the Modeler 2.0 jar (was in Modeler 1.1 release) - from the following thread on Tomcat dev list http://tinyurl.com/2ev4qt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
