This is the problem as it was described to me by Yannik Hampe.
Consider the following action bean:
public class DemoAction implements ActionBean
private ActionBeanContext context;
public List<MyClass> myProperty;
public Resolution demo() throws Exception
return new StreamingResolution("text/plain", Integer.toString(myProperty.get(0).i));
public static class MyClass
public Integer i;
public void setContext(ActionBeanContext context)
this.context = context;
public ActionBeanContext getContext()
There are two ways to call this actionBean and pass a value i:
Using the first method will be caught by Stripes' validation system. Using the second URL will print "-5" in the Browser, proving that the @Validate annotation has been bypassed.
This happens, because in net.sourceforge.stripes.controller.ParameterName the "strippedName" is generated by using the matcher Pattern.compile("\\[.*?
]") to remove indexes on indexed properties. But this will also remove the [i] in the example above, causing Stripes to use the @Validate tag that is attached to myProperty instead of the corresponding @Validate tag in the @ValidateNestedProperties annotation. Since in the example above the former tag is not present, Stripes will not perform any validation at all, but binding still works.
In the example above the consequences don't matter. But in other situations the validation tags may be used to protect the system from malicious input, for example if someone uses mask="^[a-z]$" and expects the string then to be safe to be used in certain parsers, such as SQL-parsers without further escaping.