4 Replies Latest reply on Nov 6, 2008 3:17 PM by Ales Justin

    JBMICROCONT-380; constructor (property) matching

    Ales Justin Master

      Carlo is complaining about how we match which constructor to use:
      - https://jira.jboss.org/jira/browse/JBMICROCONT-380

      Thinking about it, what is really the reason we don't do better
      - more exact matching - in InstantiateAction?

      As constructor parameter dependencies should already be resolved,
      we could eventually pre-invoke that ValueMetaData's to get real parameter values,
      and do matching based on that?

      Same with other parametrized metadata - property, lifecycle, installs, ...

      I'm probably missing something obvious. :-)

        • 1. Re: JBMICROCONT-380; constructor (property) matching
          Adrian Brock Master

          Like I said on the JIRA issue, its not possible in general.

          The only way to get close would be for the ValueMetaData to say
          that it doesn't need the type before you can get the value.

          Then you could invoke getValue(TypeInfo, ClassLoader)
          (with null for the TypeInfo) before you determine the constructor.

          But you'd still need to extend the fuzzy match processing
          to not only look at the exact type but also all the interfaces
          of the value returned.

          Even then you could still get an ambiguity, e.g. in the example on the JIRA issue
          if the injection implemented both Kernel and Controller.

          This particular issue would probably be better resolved if we just
          changed the BeanMetaDataDeployer to use @Inject for the controller
          so you don't have to specify it in the xml.
          The only reason all the different config mechanisms exist
          (constructors/setters) is supposedly for backwards compatiblity
          but the example from embedded shows that the ambiguous constructor
          breaks that anyway. ;-)

          • 2. Re: JBMICROCONT-380; constructor (property) matching
            Carlo de Wolf Master

            Can we then have an exception if the parameter type is unspecified and there are multiple constructors to choose from?

            • 3. Re: JBMICROCONT-380; constructor (property) matching
              Adrian Brock Master

               

              "wolfc" wrote:
              Can we then have an exception if the parameter type is unspecified and there are multiple constructors to choose from?


              I know we used to issue a WARNing, because Scott asked me to add it.
              But I can't find it in the current code?

              Ales, did you remove it during one of your refactorings? :-)

              • 4. Re: JBMICROCONT-380; constructor (property) matching
                Ales Justin Master

                 

                "adrian@jboss.org" wrote:
                Ales, did you remove it during one of your refactorings? :-)

                Where was it?
                In Config class?

                I'll check history to find the true culprit,
                as I doubt it was me. ;-)