Commons BeanUtils
  1. Commons BeanUtils
  2. BEANUTILS-387

[beanutils] copyProperties() throws a ConversionException : No value specified for 'Date' when the field is a java.util.Date with a null value

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.8.3
    • Fix Version/s: None
    • Component/s: Bean / Property Utils
    • Labels:
      None

      Description

      We have migrated the library from version 1.6.0 to 1.8.0 and the copyProperties() method fails when copying a java.util.Date attribute with a null value.

      Here is a simple testcase :

      public class Test {
      
      	private Date date;
      	
      	public Date getDate() { return date;	}
      	public void setDate(Date date) { this.date = date; }
      
      	public static void main(String[] args) throws Exception {
      
      		Test dest = new Test();
      		Test source = new Test();
      		BeanUtils.copyProperties(dest, source);
      	}
      }
      

      As a workaround, we can do this :
      ConvertUtils.register(new DateConverter(null), Date.class);

      When can also use PropertyUtils.copyProperties() because in this case no conversion is required but the impact is unknown on our big application.

      The problem is that there seems to be a regression between version 1.6.0 and 1.8.0.

        Issue Links

          Activity

          Hide
          Markus Stahl added a comment -

          Opened a new Jira for this one, since I do not think, that anybody else than us reporters receives notifications about this issue.

          Show
          Markus Stahl added a comment - Opened a new Jira for this one, since I do not think, that anybody else than us reporters receives notifications about this issue.
          Hide
          Jarrar added a comment -

          I also agree that this method should not do any kind of conversion or parsing because here I expect just a 1:1 copy nothing else. Please reopen this issue and ...

          Show
          Jarrar added a comment - I also agree that this method should not do any kind of conversion or parsing because here I expect just a 1:1 copy nothing else. Please reopen this issue and ...
          Hide
          Timm Frenzel added a comment -

          For me it's also a big issue. We are using a third-party software that allows for customization by just extending from the provided Bean classes and configuring those in the software system. In our extension we use a bean property of type 'Calendar' (which produces the same issue as a Date). The software uses copyProperties() to handle those extensions. It was recently upgraded by the manufacturer and now uses the beanutils 1.8 package. But now the software fails due to this changed behavior in copyProperties(). We cannot register any custom converter in this software. So the changed behavior of copyProperties() breaks our software. Therefore I strongly vote for not throwing exception by default when copying null values.

          Show
          Timm Frenzel added a comment - For me it's also a big issue. We are using a third-party software that allows for customization by just extending from the provided Bean classes and configuring those in the software system. In our extension we use a bean property of type 'Calendar' (which produces the same issue as a Date). The software uses copyProperties() to handle those extensions. It was recently upgraded by the manufacturer and now uses the beanutils 1.8 package. But now the software fails due to this changed behavior in copyProperties(). We cannot register any custom converter in this software. So the changed behavior of copyProperties() breaks our software . Therefore I strongly vote for not throwing exception by default when copying null values.
          Hide
          Tomasz Bartczak added a comment -

          That's right. a converter should be used whenever there is a different type, and if not - no need for a converter that does not allow nulls. I think you should reopen this issue

          Show
          Tomasz Bartczak added a comment - That's right. a converter should be used whenever there is a different type, and if not - no need for a converter that does not allow nulls. I think you should reopen this issue
          Hide
          Markus Stahl added a comment -

          I agree. It's unexpected that a null-value raises the need for a convertor, especially if the other data types seemingly just work fine with null.

          In my case, the bean to be copied has been enhanced with an optional Date property in a latest release. Suddenly the copyProperties method throws ConversionExceptions.

          Show
          Markus Stahl added a comment - I agree. It's unexpected that a null-value raises the need for a convertor, especially if the other data types seemingly just work fine with null. In my case, the bean to be copied has been enhanced with an optional Date property in a latest release. Suddenly the copyProperties method throws ConversionExceptions.
          Hide
          Hubert Grininger added a comment -

          I'd like to back Marcin's point here.. For me the sole reason to use BeanUtils.copyProperties is copy over all the properties from object A to object B, if it's null in A it should be null in B as well.
          Introducing the need for some boilerplate code really make things worse.

          Show
          Hubert Grininger added a comment - I'd like to back Marcin's point here.. For me the sole reason to use BeanUtils.copyProperties is copy over all the properties from object A to object B, if it's null in A it should be null in B as well. Introducing the need for some boilerplate code really make things worse.
          Hide
          Marcin Cinik added a comment -

          'Registering a DateConverter with a default value of null is the correct solution to your issue'.

          I reckon that the default behaviour of BeanUtilsBean.copyProperties should be just to copy properties from one bean to another bean without introducing to much hassle, especially that both source and destination beans are of the same class. Currently that method is not working for beans of the same class out of the box.
          Shall you justify your previous comment and clarify why the Date is exeptional in this case please ?

          Show
          Marcin Cinik added a comment - 'Registering a DateConverter with a default value of null is the correct solution to your issue'. I reckon that the default behaviour of BeanUtilsBean.copyProperties should be just to copy properties from one bean to another bean without introducing to much hassle, especially that both source and destination beans are of the same class. Currently that method is not working for beans of the same class out of the box. Shall you justify your previous comment and clarify why the Date is exeptional in this case please ?
          Hide
          Niall Pemberton added a comment -

          Prior to BeanUtils 1.8.0 there was no converter for java.util.Date and date properties were copied unchanged - so null didn't cause any issue. BeanUtils 1.8.0 introduced a date converter (BEANUTILS-255), but as you discovered the default behaviour for null is to throw an exception. Registering a DateConverter with a default value of null is the correct solution to your issue.

          This is working as intended, so closing this issue as WONT FIX.

          Show
          Niall Pemberton added a comment - Prior to BeanUtils 1.8.0 there was no converter for java.util.Date and date properties were copied unchanged - so null didn't cause any issue. BeanUtils 1.8.0 introduced a date converter ( BEANUTILS-255 ), but as you discovered the default behaviour for null is to throw an exception. Registering a DateConverter with a default value of null is the correct solution to your issue. This is working as intended, so closing this issue as WONT FIX.

            People

            • Assignee:
              Unassigned
              Reporter:
              Daniel Marchese
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development