commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <>
Subject [jira] [Updated] (BEANUTILS-454) copyProperties() throws conversion exception for null Date
Date Wed, 27 Nov 2013 21:32:36 GMT


Oliver Heger updated BEANUTILS-454:

    Attachment: beanutils-454.patch

This is a proposed patch. It changes the {{copyProperty()}} method to handle *null* values
on copying in a special way, i.e. returning them directly without performing any conversion.

My first attempt to fix this problem was to change the {{ConvertUtils.deregister()}} method
in a way so that "other" converters get the same default settings as standard converters.
This means that they would not throw an exception when encountering a *null* value. However,
this had the undesired side effect that conversion failures (e.g. when trying to convert a
string to a Class which does not point to an existing class) were silently ignored and resulted
in *null* values. So I had to add the fix directly in the method which does the copying of

I think it is a problem in the design of converters that missing values are basically handled
the same way as conversion errors. So if you set a default value, it is returned if the converter
is passed *null* or if conversion fails. If no default value is set, exceptions are also thrown
for *null* values to be converted.

It would make sense to handle these cases differently. However, this is a story for BeanUtils

> copyProperties() throws conversion exception for null Date
> ----------------------------------------------------------
>                 Key: BEANUTILS-454
>                 URL:
>             Project: Commons BeanUtils
>          Issue Type: Bug
>    Affects Versions: 1.8.0
>            Reporter: Markus Stahl
>            Priority: Critical
>             Fix For: 1.8.4
>         Attachments: beanutils-454.patch
> This issue had been reported earlier and rejected too soon. 
> Since 1.8.0, BeanUtils.copyProperties suddenly throws an Exception, if the property is
of type Date. It did not do so in prior releases, that's why properly running software is
nowadays broken. There is a workaround if the BeanUtils are used in my own code, but if it
is used in 3rd party code, I am screwed.
> Please, treat null for Date the same as null for any other type and copy null from source
to destination.
> For more reasons, see the comments of people who move now to new releases of BeanUtils
facing the same problem. The issue gets more and more attention, but I think, nobody except
the reporters are notified about it. Therefore this issue.

This message was sent by Atlassian JIRA

View raw message