[
https://issues.apache.org/jira/browse/BEANUTILS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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 properties.
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 2.
> copyProperties() throws conversion exception for null Date
> ----------------------------------------------------------
>
> Key: BEANUTILS-454
> URL: https://issues.apache.org/jira/browse/BEANUTILS-454
> 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
(v6.1#6144)
