2015-03-02 15 views
6

Quindi voglio modificare i messaggi di convalida utilizzati per convalidare un modello tramite una risorsa DropWizard.Override DropWizard ConstraintViolation message

Sto usando le annotazioni di convalida dei bean java. Per esempio ecco uno dei campi che voglio validare:

@NotEmpty(message = "Password must not be empty.") 

Posso testare questo funziona come previsto utilizzando un validatore.

Tuttavia, quando utilizzo DropWizard per eseguire la convalida sulla risorsa, aggiunge alcune informazioni aggiuntive a tale messaggio. Quello che vedo è questa - password Password must not be empty. (was null) e ho trovato il codice che fa questo qui - https://github.com/dropwizard/dropwizard/blob/master/dropwizard-validation/src/main/java/io/dropwizard/validation/ConstraintViolations.java

In particolare questo metodo -

public static <T> String format(ConstraintViolation<T> v) { 
    if (v.getConstraintDescriptor().getAnnotation() instanceof ValidationMethod) { 
     final ImmutableList<Path.Node> nodes = ImmutableList.copyOf(v.getPropertyPath()); 
     final ImmutableList<Path.Node> usefulNodes = nodes.subList(0, nodes.size() - 1); 
     final String msg = v.getMessage().startsWith(".") ? "%s%s" : "%s %s"; 
     return String.format(msg, 
          Joiner.on('.').join(usefulNodes), 
          v.getMessage()).trim(); 
    } else { 
     return String.format("%s %s (was %s)", 
          v.getPropertyPath(), 
          v.getMessage(), 
          v.getInvalidValue()); 
    } 
} 

C'è un modo per ignorare questo comportamento? Voglio solo visualizzare il messaggio che ho impostato nell'annotazione ...

risposta

5

ConstraintViolationExceptionMapper è quello che utilizza tale metodo. Per sovrascriverlo, devi cancellarlo e registrare il tuo ExceptionMapper.

Rimuovere il mapper eccezione (s)

Dropwizard 0.8

Aggiungere il seguente al file YAML. Si noti che rimuoverà tutti i mappatori delle eccezioni predefiniti aggiunti da dropwizard.

server: 
    registerDefaultExceptionMappers: false 

Dropwizard 0.7.x

environment.jersey().getResourceConfig().getSingletons().removeIf(singleton -> singleton instanceof ConstraintViolationExceptionMapper); 

creare e aggiungere la tua eccezione mapper

public class ConstraintViolationExceptionMapper implements ExceptionMapper<ConstraintViolationException> { 

    @Override 
    public Response toResponse(ConstraintViolationException exception) { 
     // get the violation errors and return the response you want. 
    } 
} 

e aggiungere il mapper eccezione nella classe di applicazione.

public void run(T configuration, Environment environment) throws Exception { 
    environment.jersey().register(ConstraintViolationExceptionMapper.class); 
} 
+0

mi piace [risposta di Lukasz Wiktor] (http://stackoverflow.com/a/30799426/1891566) meglio perche' ri-instates gli altri mappatori eccezione che il primo passo di questo la risposta rimuove, cambiando efficacemente * solo il mappatore per 'ConstraintValidationException's * –

6

Ecco una soluzione programmatica in dropwizard 0.8:

public void run(final MyConfiguration config, final Environment env) { 
    AbstractServerFactory sf = (AbstractServerFactory) config.getServerFactory(); 
    // disable all default exception mappers 
    sf.setRegisterDefaultExceptionMappers(false); 
    // register your own ConstraintViolationException mapper 
    env.jersey().register(MyConstraintViolationExceptionMapper.class) 
    // restore other default exception mappers 
    env.jersey().register(new LoggingExceptionMapper<Throwable>() {}); 
    env.jersey().register(new JsonProcessingExceptionMapper()); 
    env.jersey().register(new EarlyEofExceptionMapper()); 
} 

Penso che sia più affidabile di un file di configurazione. E come puoi vedere, abilita anche tutti gli altri default exception mappers.

+1

Questa dovrebbe essere la risposta accettata poiché quella corrente rimuove più mappatori di eccezioni rispetto a quanto richiesto dall'OP. –