Parameter matching issue?

[starksm64]

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?

[alesj]

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.

[starksm64]

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?

[adrian.brock]

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.