2015-05-05 6 views
16

Utilizzo il framework MVC a molla. Voglio registrare gli stati degli errori ogni volta che viene lanciata un'eccezione, quindi il metodo afterCompletion viene utilizzato in HanlderInterceptor.HandlerInterceptor.afterCompletion() in primavera MVC modifica il codice di risposta

@Override 
public void afterCompletion(final HttpServletRequest request, final HttpServletResponse response, final Object handler, final Exception ex) 
{ 
    final int responseCode = response.getStatus(); 
    s_logger_error.error("status code: " + responseCode); 
} 

Questo codice funziona correttamente se lo eseguo come applicazione sul computer locale. Ma quando lo ospitiamo sul server jetty, l'interfaccia utente riceve la risposta corretta (nel mio caso 409), ma in questo metodo viene registrato come 200.

[Immagine da debug remoto dove mostra status=200 ma in risposta è 409] enter image description here

Qualcuno può aiutare a capire il motivo per cui non v'è un cambiamento nel codice di risposta?

Sto usando sprint 1.1.7.RELEASE versione di avvio a molla e jetty-distribution-9.2.10.v20150310.

+0

casi in cui è impostato il codice 409 di stato? È possibile che sia impostato dopo che HandlerInterceptor.afterCompletion() – medvedev1088

+0

409 viene impostato prima che venga chiamato HandlerInterceptor.afterCompletion(). – subhashlg26

+0

Hai implementato 'HandlerInterceptor' o sottoclasse una delle implementazioni? – Leon

risposta

1

È necessario assicurarsi di chiamare il metodo setStatus sull'oggetto response in caso di eccezione.

Se si asserisce che, l'aggiornamento alla versione di avvio di primavera 1.1.11 può risolvere il problema. Riguarda questo fix. Prima della correzione, lo ErrorPageFilter mascherava lo stato di risposta della risposta incapsulata nei casi in cui il metodo sendError non viene chiamato esplicitamente su ErrorWrapperResponse.

Il codice dopo il fisso changed dal semplice return this.status a

 if (this.errorToSend) { 
      return this.status; 
     } 
     else { 
      // If there was no error we need to trust the wrapped response 
      return super.getStatus(); 
     } 

è per questo che credo che l'aggiornamento risolverà il problema.

Infine, se si emette persistere, il debug attraverso ErrorPageFilter dovrebbe indicare l'origine del problema