There is a limit to how much type conversion XWork can do automatically when it works with collections. Internally, XWork uses XWorkList and XWorkMap. They basically extend ArrayList and HashMap respectively to support type conversion. Anything that gets inserted into them are automatically converted if they're not already the required type. In situations where the collection is null, XWork will create either an XWorkList or an XWorkMap and set it back on to the target (see Null Property Access for details), and everything works beautifully. However, if the collection is not null, and the collections returned are neither an XWorkList nor an XWorkMap, there's no way type conversion can be performed. In this case, the you want type conversion to work, you will have to seriously consider using XWorkList or XWorkMap instead of ArrayList or HashMap. ExampleImagine a User object that has a Collection of e-mail addresses. Now, suppose the input is a String array [ "foo@bar.com" ], and the target is "emails[1]". What we'd really like XWork to do is convert that String array into a String before inserting it into the collection. The first thing we'd do is create a User-conversion.properties with the line: Collection_emails = java.lang.String If User.getEmails() returns null, then XWork will create a new XWorkList and call User.setEmails() with it. It will then add an empty string at position [0] and insert "foo@bar.com" at position [1] (the array is automatically converted into a String). If User.getEmails() returns something other than XWorkList, when XWork tries to set emails[1] to [ "foo@bar.com" ], no type conversion will occur. In addition, if the array is empty, ArrayList will throw an IndexOutOfBoundsException. |