java - How to validate overridden methods parameters with Hibernate Validator? -

regarding this doc understand if have groupservice implements groupmanager , overrides methods, cannot annotate validation constraints since hibernate validator doesn't allow (which turns out known liskov substitution principle). mean doing like

public class groupservice implements groupmanager{      @override     public list<string> findusersingroup(@notnull string groupname) {         ...     } } 

then constraintdeclarationexception raised, right? solution apparently put these constraints on interface, in case:

1. i not have access modificate interface (as case groupmanager belongs spring security). how can then?
2. i think these validation constraints should not affect interface since part of implementation, in case i'd want have other service implementation, shouldn't have hook these validations. maybe new 1 i'd want implement kind of validation, , hibernate validator forces me 'dirty up' interface

i not have access modificate interface (as case groupmanager belongs spring security). how should in case?

you can use xml configuration since jsr-303 (bean validation) supports it. e.g.

<constraint-mappings xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"                      xsi:schemalocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd"                      xmlns="http://jboss.org/xml/ns/javax/validation/mapping">     <default-package>org.springframework.security.provisioning</default-package>     <bean class="groupmanager" ignore-annotations="true">         <method name="findusersingroup">             <parameter type="java.lang.string">                 <constraint annotation="javax.validation.constraints.notnull"/>             </parameter>         </method>     </bean> </constraint-mappings> 

see xml configuration chapter in hibernate doc.

i have thought these validation constraints should not affect interface since part of implementation

as hibernate documentation says

when method overridden in sub-types method parameter constraints can declared @ base type. reason restriction preconditions fulfilled type's client must not strengthened in sub-types (which may not known base type's client).

the methods preconditions should not strengthened sub-types. if sub-type groupservice not allow null parameter might strengthened precondition. e.g. client uses groupmanager might not know (and should not know) groupservice. groupmanager interface not make restrictions parameter. if break formerly leagal client code. violates liskov substitution principle.

sadly groupmanager javadoc not restrict parameter. legal implementation must handle every situation.

in general... when define methodes apply these rules

• if method defines parameter must not null.
• if parameters optional - create overloaded methods , handle optional parameters internally. e.g. using null object pattern.

these simple rules me create clear api clients.

edit

i think possible have impl "a" , impl "b" (both implementing same interface) impl "a" has more (and different) validations "b"

if not have same interface or api. see both have same method signature. 2 equal method signatures must not share same api contract. when talk interface think contract , not signature. imagine following interface:

public class container {      /**      * @return non-empty collection of elements.       */      public collection<element> getelements(); } 

in case legal client code be

container container = ....; element firstelement = container.getelements().iterator().next(); 

because contract says returns non-empty collection.

if change javadoc , therefore post-condition...

 /**   * @return collection of elements.    */   public collection<element> getelements(); 

the formerly legal client code not work anymore.

i made example show difference between contract , method signature.

a detailed , explanation can found here.

as groupmanager javadoc doesn't restrict parameter ,a legal impl must handle every situation'? validating params inside method?

yes. if interface not add restriction parameters implementation must handle every state, because client might pass arguments in state.