[ https://issues.jboss.org/browse/JBWS-3812?page=com.atlassian.jira.plugin.... ] Alessio Soldano edited comment on JBWS-3812 at 9/24/14 11:08 AM: ----------------------------------------------------------------- John, I'd need a reproducer for this, or at least some additional information and/or a stacktrace from where the string property value for the ut validator causes issue. While the CXF documentation indeed says "Validator *instance*", most of the code dealing with those props is able to get the String value and use it to create an instance of the specified class name. When it comes to the ut.validator, in current CXF master that's processed in 3 points, in UsernameTokenInterceptor, WSS4JInInterceptor.CXFRequestData and WSS4JStaxInInterceptor. The first of the three is the only one that does not seem to be able to deal with a String value. I could simply fix that, but I'd need a testcase stressing this issue. I've tried modifying some of the systests in CXF sources to use a String value for custom ut validators, but could not reproduce the issue. was (Author: asoldano): John, I'd need a reproducer for this, or at least some additional information and/or a stacktrace from where the string property value for the ut validator causes issue. While the CXF documentation indeed says "Validator *instance*", the most of the code dealing with those props is able to get the String value and use it to create an instance of the specified class name. When it comes to the ut.validator, in current CXF master that's processed in 3 points, in UsernameTokenInterceptor, WSS4JInInterceptor.CXFRequestData and WSS4JStaxInInterceptor. The first of the three is the only one that does not seem to be able to deal with a String value. I could simply fix that, but I'd need a testcase stressing this issue. I've tried modifying some of the systests in CXF sources to use a String value for custom ut validators, but could not reproduce the issue. -- This message was sent by Atlassian JIRA (v6.3.1#6329)