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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981300#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...