Arquivo Discussoes de Programacao e Tecnologia Não entendi teu post. O VRaptor exporta os erros do BeanValidator com as constraints violations.
BeanValidator.validate retorna uma lista de Message, e o DefaultValidator.validate exporta para o atributo errors. Como as mensagens são exportadas para o atributo errors, você pode fazer um foreach no JSP e ler essas mensagens normalmente.
Você tem acesso a ele pelo JSP via atributo errors. Você precisa dele no controller?
Vamos com calma. Antes de mais nada preciso entender as necessidades para saber como te ajudar.
antes de mais nada, se vc usar o:
validator.onErrorSendBadRequest();
e a requisição veio com Accept: application/json ou algo do tipo, ele vai serializar os erros pra json automaticamente.
A gente não disponibiliza os erros na interface Validator, pq geralmente não faz mto sentido vc acessar os erros no controller, é algo que vc só precisa na view.
de qqer forma, vc pode estender o VRaptor:
public interface MeuValidator extends Validator {
List<Message> getErrors();
}
@Component
public class ImplDoMeuValidator extends DefaultValidator implements MeuValidator {
//delega o construtor
//aumenta a visibilidade do getErrors
}
e receber o MeuValidator no construtor…
abre lá uma issue pedindo isso, por favor:
se puder fazer um fork e mandar um pull request com a implementação seria bem legal tb 
abre lá uma issue pedindo isso, por favor:se puder fazer um fork e mandar um pull request com a implementação seria bem legal tb ;)
Será que é legal retornar uma lista imutável de errors?
por exemplo
public List<> getErrors() {
Collections.unmodifiableList(errors)
}
Ao invés de retornar diretamente os errors.
as implementações de Message são imutáveis, então o immutable funcionaria
A minha intenção é evitar fazer getErrors().clear() ou coisas assim.
Ola
Não percebo um clara justificativa para que não possamos recuperar os erros (Message) ocorridos quando usamos alguma implementação da JSR de Bean Validator através do VRaptor, leia-se:
Eu tenho realmente que criar um Interceptor para pegar o parâmetro “errors” (próprio do VRaptor) existente pós validação?
Porque não disponibilizá-las publicamente ?
Simples garcia, a interface br.com.caelum.vraptor.Validator não tem este método.
AbstractValidator marca ele como protegido e é usado por DefaultValidator, este sim contém o método público.
Minha questão é:
Porque este método não é declarado na interface? Eu teria que declarar, no controller, a implementação diretamente (ou fazer CAST), para ter acesso a este método.
Seria o óbvio ululante, garcia.
Mas br.com.caelum.vraptor.Validator não tem o método getErrors()
Estou usando a versão 3.3.1
Obg
Isso, eu preciso no Controller. Meu cliente é um Aplicativo que consome JSON. (de antemão aviso que o Deserializer default do VRaptor não funciona pra mim, eu estou usando o GSon)
O ponto desta thread não é a solução em si, mas o por quê não disponibilizá-lo na interface Validator.
Um cara que valida algo, por definição, deve saber informar os erros encontrados.
@garcia-jj, Lucas
O aplicativo cliente recebe tudo em JSON, inclusive mensagens de erro, ao invés de HTTP CODE e/ou, porventura, uma mensagem no corpo.
O atalho do VRaptor produz um HTTP CODE 400, certo? Não serve para mim. Nem sempre podemos fazer algo mais próximo de Restful.
Trata-se de um aplicativo feito em Flash que consome JSON e envia JSON. Ele será o único cliente, então não posso me prender a diversas good practices de serviços web, REST ou não, pois a plataforma da Adobe é bem limitada e cheia de problemas.
Neste caso específico, ao receber um code 400 ele simplesmente retorna um IOError e não tem como capturar a resposta, quiçá, enviada pelo serviço.
Como é muito simples a solução do Lucas, vou utilizá-la, pois assim meu cliente vai ganhar dinheiro e, da maneira mais responsável possível, irei resolver o problema dele.
Obrigado pessoal!
Vocês não acham que os erros deveriam ser conhecidos no Controller?
Acho natural usar o padrão (colocar o erros no request), porém, por default, não vejo problemas em disponibilizá-los no Controller também.
E se o cara quiser enviar as mensagens em outra formatação, não é normal? Neste caso o VRaptor não estaria tolhendo demais o programador para utilizar o padrão dele ? Enviá-la de outra forma demanda, desnecessariamente, o trabalho de sobrescrever o framework.
O que vocês acham?
Bacana garcia, mas só lembrando que você com unmodifiableXX pode mudar os objetos NA instância da lista de qualquer forma. O que você não pode é, simplesmente, alterar a instância DA PRÓPRIA lista.
Ou seja, não vejo qualquer benefício prático neste caso.
Lucas,
Chegando em casa vou implementar e dar um pull. 