Hola usuario de nuestro sitio, descubrimos la solución a tu interrogante, desplázate y la hallarás aquí.
Solución:
Un malentendido común entre los titulares es que piensan que la llamada de un forward(), sendRedirect()o sendError() saldría mágicamente y “saltaría” del bloque de método, ignorando así el remanente del código. Por ejemplo:
protected void doXxx()
if (someCondition)
sendRedirect();
forward(); // This is STILL invoked when someCondition is true!
Por lo tanto, esto en realidad no es true. Ciertamente no se comportan de manera diferente a cualquier otro método de Java (excepto de System#exit() por supuesto). Cuando el someCondition en el ejemplo anterior es true y tu estas llamando asi forward() después sendRedirect() o sendError() en la misma solicitud/respuesta, entonces la posibilidad es grande que obtendrá la excepción:
java.lang.IllegalStateException: no se puede reenviar después de que se haya confirmado la respuesta
Si el if declaración llama a forward() y luego estas llamando sendRedirect() o sendError()entonces se lanzará la siguiente excepción:
java.lang.IllegalStateException: no se puede llamar a sendRedirect() después de confirmar la respuesta
Para solucionar esto, debe agregar un return; declaración después
protected void doXxx()
if (someCondition)
sendRedirect();
return;
forward();
… o para introducir un bloque else.
protected void doXxx()
if (someCondition)
sendRedirect();
else
forward();
Para precisar la causa raíz en su código, simplemente busque cualquier línea que llame a un forward(), sendRedirect() o sendError() sin salir del bloque de método ni saltarse el remanente del código. Esto puede estar dentro del mismo servlet antes de la línea de código en particular, pero también en cualquier servlet o filtro que haya sido llamado antes del servlet en particular.
En caso de sendError()si su único propósito es establecer el estado de respuesta, utilice setStatus() en lugar de.
Otra causa probable es que el servlet escribe en la respuesta mientras un forward() será llamado, o ha sido llamado en el mismo método.
protected void doXxx()
out.write("some string");
// ...
forward(); // Fail!
El tamaño predeterminado del búfer de respuesta en la mayoría de los servidores es de 2 KB, por lo que si escribe más de 2 KB, se confirmará y forward() fallará de la misma manera:
java.lang.IllegalStateException: no se puede reenviar después de que se haya confirmado la respuesta
La solución es obvia, simplemente no escriba la respuesta en el servlet. Esa es la responsabilidad del JSP. Acabas de configurar una solicitud attribute al igual que request.setAttribute("data", "some string") y luego imprimirlo en JSP así $data. Vea también nuestra página wiki de Servlets para aprender a usar Servlets de la manera correcta.
Otra causa probable es que el servlet escriba una descarga de archivo en la respuesta, después de lo cual, por ejemplo, un forward() se llama.
protected void doXxx()
out.write(bytes);
// ...
forward(); // Fail!
Esto no es técnicamente posible. Necesitas quitar el forward() llamada. El usuario final permanecerá en la página abierta actualmente. Si realmente tiene la intención de cambiar la página después de la descarga de un archivo, debe mover la lógica de descarga de archivos a la página de carga de la página de destino.
Otra causa probable es que el forward(), sendRedirect() o sendError() los métodos se invocan a través del código Java incrustado en un archivo JSP a la antigua usanza <% scriptlets %>una práctica que fue desaconsejada oficialmente desde 2001. Por ejemplo:
...
...
<% sendRedirect(); %>
...
El problema aquí es que JSP escribe internamente de inmediato el texto de la plantilla (es decir, el código HTML) a través de out.write(" ... etc ...") tan pronto como se encuentra. Por lo tanto, este es esencialmente el mismo problema que se explicó en la sección anterior.
La solución es obvia, simplemente no escriba código Java en un archivo JSP. Esa es la responsabilidad de una clase Java normal como un Servlet o un Filtro. Vea también nuestra página wiki de Servlets para aprender a usar Servlets de la manera correcta.
Ver también:
- ¿Qué significa exactamente “Respuesta ya confirmada”? ¿Cómo manejar las excepciones entonces?
No relacionado a su problema concreto, su código JDBC está perdiendo recursos. Arregla eso también. Para obtener sugerencias, consulte también ¿Con qué frecuencia se deben cerrar Connection, Statement y ResultSet en JDBC?
incluso agregar una declaración de devolución genera esta excepción, para la cual la única solución es este código:
if(!response.isCommitted())
// Place another redirection
Por lo general, verá este error después de haber realizado una redirección y luego intentar enviar algunos datos más a la secuencia de salida. En los casos en los que he visto esto en el pasado, a menudo es uno de los filtros que está tratando de redirigir la página y luego reenvía al servlet. No puedo ver nada malo inmediatamente con el servlet, por lo que es posible que desee intentar echar un vistazo a los filtros que tiene en su lugar también.
Editar: Un poco más de ayuda para diagnosticar el problema…
El primer paso para diagnosticar este problema es determinar exactamente dónde se lanza la excepción. Suponemos que está siendo arrojado por la línea.
getServletConfig().getServletContext()
.getRequestDispatcher("/GroupCopiedUpdt.jsp")
.forward(request, response);
Pero es posible que descubra que se lanza más adelante en el código, donde está tratando de generar el flujo de salida después de haber intentado hacer el reenvío. Si proviene de la línea anterior, significa que en algún lugar antes de esta línea tiene:
- enviar datos al flujo de salida, o
- hecho otra redirección de antemano.
¡Buena suerte!
Reseñas y puntuaciones
Si piensas que ha sido de ayuda este artículo, sería de mucha ayuda si lo compartieras con otros programadores y nos ayudes a extender este contenido.