Spring Framework
  1. Spring Framework
  2. SPR-8806

ExtendedBeanInfo raises 'type mismatch' error with covariant property types

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 3.1 RC2
    • Component/s: None
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      Transcribed by cbeams from Paul's original comment on SPR-8347

      I am experiencing an issue with ExtendedBeanInfo and covariante propertytypes i've yet to isolate a simple test but it appears to be due using JDK PropertyDescriptor and the long standing JDK bug that are the cause resulting in

      java.beans.IntrospectionException: type mismatch between read and write methods
      at java.beans.PropertyDescriptor.findPropertyType(PropertyDescriptor.java:603)
      at java.beans.PropertyDescriptor.setWriteMethod(PropertyDescriptor.java:270)
      at java.beans.PropertyDescriptor.<init>(PropertyDescriptor.java:117)
      at org.springframework.beans.ExtendedBeanInfo.addOrUpdatePropertyDescriptor(ExtendedBeanInfo.java:260)
      at org.springframework.beans.ExtendedBeanInfo.addOrUpdatePropertyDescriptor(ExtendedBeanInfo.java:178)
      at org.springframework.beans.ExtendedBeanInfo.<init>(ExtendedBeanInfo.java:95)
      at org.springframework.beans.CachedIntrospectionResults.<init>(CachedIntrospectionResults.java:224)
      ... 124 more

        Issue Links

          Activity

          Hide
          Chris Beams added a comment -

          Hi Paul,

          Are you seeing this behavior against 3.1 RC1?

          You mention a 'well-known JDK bug' - could you provide a link to that issue?

          You also mentioned that you've had a hard time reproducing this - chances are that we will too. We'd certainly like to work it out for RC2, however. If there's any way you can reproduce this, we'll certainly look into it asap.

          By the way, you may find the spring-framework-issues project helpful in putting together a simple reproduction test case. See https://github.com/SpringSource/spring-framework-issues#readme

          Show
          Chris Beams added a comment - Hi Paul, Are you seeing this behavior against 3.1 RC1? You mention a 'well-known JDK bug' - could you provide a link to that issue? You also mentioned that you've had a hard time reproducing this - chances are that we will too. We'd certainly like to work it out for RC2, however. If there's any way you can reproduce this, we'll certainly look into it asap. By the way, you may find the spring-framework-issues project helpful in putting together a simple reproduction test case. See https://github.com/SpringSource/spring-framework-issues#readme
          Hide
          Paul Nardone added a comment -

          Hi Chris,

          Yes I'm seeing this in 3.1 RC1 on Java 1.6

          this is the bug I was thinking of when I was searching for possible causes

          http://bugs.sun.com/view_bug.do?bug_id=6422403

          I have now produced a testcase that reproduces this bug, the class hierarchy and needs to be such to reproduce the error

          Show
          Paul Nardone added a comment - Hi Chris, Yes I'm seeing this in 3.1 RC1 on Java 1.6 this is the bug I was thinking of when I was searching for possible causes http://bugs.sun.com/view_bug.do?bug_id=6422403 I have now produced a testcase that reproduces this bug, the class hierarchy and needs to be such to reproduce the error
          Hide
          Chris Beams added a comment -

          Thanks for the repro project, Paul. I've added this to the issues repository and am looking into it now.

          https://github.com/SpringSource/spring-framework-issues/commit/660a47df481cc103c4a154c8bb00de3e2af9b552

          Show
          Chris Beams added a comment - Thanks for the repro project, Paul. I've added this to the issues repository and am looking into it now. https://github.com/SpringSource/spring-framework-issues/commit/660a47df481cc103c4a154c8bb00de3e2af9b552
          Hide
          Chris Beams added a comment -

          Paul, this is resolved. Please give it a shot against 3.1.0.BUILD-SNAPSHOT and let us know, thanks!

          commit f8f741d0e99531540cec179761407db0983e2060
          Author: Chris Beams <cbeams@vmware.com>
          Date:   Sat Nov 19 21:07:10 2011 +0000
          
              Avoid 'type mismatch' errors in ExtendedBeanInfo
              
              Certain edge cases around return type covariance can trigger an
              IntrospectionException when trying to create a new PropertyDescriptor;
              particularly around the addition of write methods with parameter types
              that do not match read method return types.
              
              These type mismatch exceptions are raised during normal Introspector
              operations as well (i.e. without ExtendedBeanInfo in the mix), but
              the Introspector intentionally supresses them. In covariance cases,
              there is often already a suitable write method present, e.g. discovered
              in a supertype or superinterface, that, with the benefit of bridge
              methods works just fine in practice at runtime.  That is to say, in
              these suppression cases, the rejection of the write method is 'OK' in
              that there is already a write method present that can handle a call.
              
              ExtendedBeanInfo now mirrors this suppression behavior, but does issue
              a WARN-level log message to let the user know.
              
              An important effect of this change is that ExtendedBeanInfo now modifies
              the delegate BeanInfo object, whereas previously it did not. In practice
              this probably matters very little, but it is a design change worth
              noting. The reason for this change was to avoid the need to create new
              PropertyDescriptors wherever possible. It was discovered that by updating
              existing PDs, one can avoid these IntrospectionExceptions a greater
              percentage of the time.
              
              Issue: SPR-8806
          
          Show
          Chris Beams added a comment - Paul, this is resolved. Please give it a shot against 3.1.0.BUILD-SNAPSHOT and let us know, thanks! commit f8f741d0e99531540cec179761407db0983e2060 Author: Chris Beams <cbeams@vmware.com> Date: Sat Nov 19 21:07:10 2011 +0000 Avoid 'type mismatch' errors in ExtendedBeanInfo Certain edge cases around return type covariance can trigger an IntrospectionException when trying to create a new PropertyDescriptor; particularly around the addition of write methods with parameter types that do not match read method return types. These type mismatch exceptions are raised during normal Introspector operations as well (i.e. without ExtendedBeanInfo in the mix), but the Introspector intentionally supresses them. In covariance cases, there is often already a suitable write method present, e.g. discovered in a supertype or superinterface, that, with the benefit of bridge methods works just fine in practice at runtime. That is to say, in these suppression cases, the rejection of the write method is 'OK' in that there is already a write method present that can handle a call. ExtendedBeanInfo now mirrors this suppression behavior, but does issue a WARN-level log message to let the user know. An important effect of this change is that ExtendedBeanInfo now modifies the delegate BeanInfo object, whereas previously it did not. In practice this probably matters very little, but it is a design change worth noting. The reason for this change was to avoid the need to create new PropertyDescriptors wherever possible. It was discovered that by updating existing PDs, one can avoid these IntrospectionExceptions a greater percentage of the time. Issue: SPR-8806
          Hide
          Chris Beams added a comment -

          A general note to watchers of ExtendedBeanInfo-related issues: SPR-10029 is a major refactoring of ExtendedBeanInfo and overall support for non-void returning setter methods.

          If you have submitted a reproduction project with this issue, we have run it through its paces against these new changes, but we would like to ask you to do the same against your actual applications.

          Please consider updating your dev or test builds to work against 3.1.4.BUILD-SNAPSHOT and/or 3.2.0.BUILD-SNAPSHOT to verify, and we would appreciate any feedback, even if it's to let us know that all is well. So that we can consolidate feedback, please add your comments to SPR-10029, and mention the original issue(s) that you were watching.

          Thanks!

          Note also that testing against 3.1.4 is preferable to 3.2.0 because ExtendedBeanInfo is always in the code path in the latter, while in 3.2.0 we've optimized things such that ExtendedBeanInfo is only in play for bean classes that have one or more non-void returning setter methods.

          Show
          Chris Beams added a comment - A general note to watchers of ExtendedBeanInfo -related issues: SPR-10029 is a major refactoring of ExtendedBeanInfo and overall support for non-void returning setter methods. If you have submitted a reproduction project with this issue, we have run it through its paces against these new changes, but we would like to ask you to do the same against your actual applications. Please consider updating your dev or test builds to work against 3.1.4.BUILD-SNAPSHOT and/or 3.2.0.BUILD-SNAPSHOT to verify, and we would appreciate any feedback, even if it's to let us know that all is well. So that we can consolidate feedback, please add your comments to SPR-10029 , and mention the original issue(s) that you were watching. Thanks! Note also that testing against 3.1.4 is preferable to 3.2.0 because ExtendedBeanInfo is always in the code path in the latter, while in 3.2.0 we've optimized things such that ExtendedBeanInfo is only in play for bean classes that have one or more non-void returning setter methods.

            People

            • Assignee:
              Chris Beams
              Reporter:
              Paul Nardone
              Last updater:
              Chris Beams
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 21 weeks, 4 days ago