3 Replies Latest reply on Oct 27, 2006 9:39 AM by Adrian Brock

    Parameter matching issue?

    Scott Stark Master

      It seems like I have seen this a few times now. I updated the SuffixMatchFilter to include two new ctors SuffixMatchFilter(List) and SuffixMatchFilter(List, VisitorAttributes) in addition to the previous SuffixMatchFilter(String) and SuffixMatchFilter(String, VisitorAttributes). This should be a compatible change, but the existing WARStructure deployment:

       <!-- WAR Structure -->
       <bean name="WARStructure" class="org.jboss.deployers.plugins.structure.vfs.war.WARStructure">
       <property name="webInfLibFilter">
       <!-- We accept all .jar files in WEB-INF/lib -->
       <bean name="WebIInfLibFilter" class="org.jboss.virtual.plugins.vfs.helpers.SuffixMatchFilter">
       <constructor><parameter>.jar</parameter></constructor>
       </bean>
       </property>
       </bean>
      


      started failing:
      13:44:34,650 ERROR [AbstractKernelController] Error installing to Instantiated: name=WebIInfLibFilter state=Described
      java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.util.List] actual=[java.lang.String]
       at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:224)
       at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:140)
       at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:104)
       at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
       at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:71)
       at org.jboss.kernel.plugins.dependency.InstantiateAction.installAction(InstantiateAction.java:52)
       at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:96)
       at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
       at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
       at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
       at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
       at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
       at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
       at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:300)
       at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:270)
       at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:117)
       at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
       at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
      


      I'm guessing the type of the ctor arg is not being used?


        • 1. Re: Parameter matching issue?
          Ales Justin Master

          Add

          <parameter class="java.lang.String">.jar</parameter>
          


          so that you are more specific which ctor you want to use.

          There is a TODO (JIRA task) on better ctor/setter matching.

          • 2. Re: Parameter matching issue?
            Scott Stark Master

            Right, I knew the workaround. We should just have consistent resolution logic such that a deployment that works with version 1 of a class, continues to work with version 2 provided that version 2 is backward compatibile. The case of adding single argument ctors to a class is guarenteed to be backward compatibile.

            I see this related issue:
            http://jira.jboss.com/jira/browse/JBMICROCONT-40

            but its not about trying to have consistent resolution. Its really about telling the user that the current configuration is amiguous, and the choice made by the mc needs to be validated. Is there another issue I'm missing that uses the parameter type in the ctor selection?

            • 3. Re: Parameter matching issue?
              Adrian Brock Master

              There is no such task, we have discussed this before.
              The problem is that it doesn't know the type.

              The logic is as follows:

              1) Guess the constructor based on the number of args
              (explicit type declarations help to filter this).
              2) Use the real parameter types from the constructor
              to determine the values (property editors).

              In this case, it doesn't know

              <constructor><parameter>.jar</parameter></constructor>
              

              is a java.lang.String rather than say an integer or something else.

              Without explicit declaration of the parameter type,
              it can only guess what it is from the constructor parameter type.

              Of course, it could iterate all the constructors (if there are multiple parameters it would need to perm them) and find the "best match".

              The result might still be ambigous, e.g.
              <constructor><parameter>4</parameter></constructor>

              does this match
              public MyObject(String string) or MyObject(int integer)

              On consistent resolution logic, that also seems unachievable
              (given that the information on what changed is not stored anywhere).

              You could have rules that like prefer a java.lang.String parameter
              if there is no explicit declaration. But then the addition of a constructor
              that contains a String would cause the resolution to change, leaving
              you in exactly in the same position as when you started.

              As an aside, there is also a TODO in the code somwhere to
              implement integer progression. e.g. being able to use a
              <value class="int">4</value>

              to match a
              public MyObject(long x) {}
              constructor.