Tutorial Java WEB

Capítulo 1. El modelo de la tecnología Servlet

Para cada uno de los métodos HTTP (como GET, POST, HEAD, y así sucesivamente) describir el propósito del método y las características técnicas del protocolo HTTP método, la lista de factores desencadenantes que pueden causar un cliente (normalmente un navegador Web) para utilizar el método e identificar el método HttpServlet que se corresponde con el método HTTP.

La subclase abstracta HttpServlet añade métodos adicionales más allá de la interfaz básica de Servlets que se llama automáticamente por el método de servicio en la clase HttpServlet para ayudar en la tramitación de solicitudes basadas en HTTP.Estos métodos son (HTTP 1.1):

doGet para el manejo de solicitudes HTTP GET.

protegidas doGet void (HttpServletRequest req, HttpServletResponse resp) lanza ServletException, IOException

Llamado por el servidor (a través del método de servicio) para permitir un servlet para manejar una petición GET. Reemplazar este método para apoyar una solicitud GET también admite automáticamente una petición HTTP HEAD. Una petición HEAD es una solicitud GET que devuelve ningún cuerpo en la respuesta, sólo los campos de encabezado de la solicitud. Al reemplazar este método, lea la solicitud de datos, escriba los encabezados de respuesta, recibe la respuesta del escritor o un objeto stream de salida, y, por último, escriba los datos de respuesta. Lo mejor es incluir el tipo de contenido y codificación. Cuando se utiliza un objeto PrintWriter para devolver la respuesta, establecer el tipo de contenido antes de acceder al objeto PrintWriter.

import java.io. *; importación javax.servlet .*; importación javax.servlet.http .*;

public class DisplayServlet extiende HttpServlet { public void doGet (HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException { resp.setContentType ("text / html"); a cabo PrintWriter = resp.getWriter (); out.println ("<html> <title> pantalla de información"); out.println ("</ title> </ head> <body>"); out.println ("Hola, mundo"); out.println ("</ body> </ HTML>"); } }

El contenedor de servlets debe escribir los encabezados de la respuesta antes de comprometerse, porque en los encabezados HTTP deben ser enviados antes de que el cuerpo de la respuesta.

El método GET debe ser seguro, es decir, sin efectos secundarios para que los usuarios son responsables. Por ejemplo, la mayoría de las consultas de forma no tienen efectos secundarios. Si una solicitud de cliente es la intención de cambiar los datos almacenados, la solicitud debe utilizar otro método HTTP (por ejemplo, el método POST).

El método GET también debe ser idempotente, lo que significa que puede repetirse de forma segura. A veces toma un seguro método también hace que sea idempotente. Por ejemplo, la repetición de las consultas es seguro y idempotente, pero la compra de un producto en línea o la modificación de los datos no es ni seguro ni idempotente.

GET propósito método.

El EEG se entenderá el método recuperar toda la información (en forma de una entidad) es identificado por el Request-URI. Si Request-URI se refiere a un proceso de producción de datos, es la información producida que se volvió como la entidad en la respuesta y no el texto original del proceso, a menos que el texto pasa a ser el resultado del proceso.

En resumen, este método se debe utilizar para conseguir (recuperar) los datos solamente. No se debe utilizar para almacenar datos en el PP.

GET características del método técnico.

datos de la cadena de consulta o la forma en que este método es simplemente adjunta a la dirección como pares de nombre y valor separados por '&'.

nombre1 = valor1 y nombre2 = valor2 y nombre3 = valor3

longitud de consulta es limitado (que depende de Plaform contenedor de servlets, pero por lo general no debe superar los 1024 bytes). Los usuarios pueden ver los datos en la barra de direcciones del navegador.

http://some-server.com/some-script?name1=value1&name2=value2&name3=value3

Sólo ASCII (texto) los datos pueden ser enviados al servidor con el método GET.

Fácil de marcador.

GET método activa.

El explorador Web envía una solicitud HTTP GET cuando:

El usuario escribe una dirección URL en la barra de direcciones del navegador.

El usuario hace clic en un enlace.

Recuperar un recurso que se definió en src (imagen) o href (hoja de estilos en cascada) los atributos.

<img src="image.gif">

href="style.css" <link rel="stylesheet" type="text/css">

El usuario (o JavaScript) envía un formulario que especifica el método de atributo = "GET":

<form method="GET"> action="/servlet/display" Nombre: <input type="text" name="firstName"> <p> Apellido: <input type="text" name="lastName"> <p> <input type="submit" value="Display"> </ Form>

El usuario (o JavaScript) envía un formulario que especifica NO atributo method (método GET formas de aplicación por defecto):

<form action="/servlet/display"> Nombre: <input type="text" name="firstName"> <p> Apellido: <input type="text" name="lastName"> <p> <input type="submit" value="Display"> </ Form>

doPost para el manejo de solicitudes HTTP POST.

protected void doPost (HttpServletRequest req, HttpServletResponse resp) lanza ServletException, IOException

Llamado por el servidor (a través del método de servicio) para permitir un servlet para manejar una petición POST. El método HTTP POST permite al cliente enviar datos de longitud ilimitada en el servidor Web de una sola vez y es útil al publicar la información tal como números de tarjetas de crédito. Al reemplazar este método, lea la solicitud de datos, escriba los encabezados de respuesta, recibe la respuesta del escritor o un objeto stream de salida, y, por último, escriba los datos de

respuesta. Lo mejor es incluir el tipo de contenido y codificación. Cuando se utiliza un objeto PrintWriter para devolver la respuesta, establecer el tipo de contenido antes de acceder al objeto PrintWriter.

import java.io. *; importación javax.servlet .*; importación javax.servlet.http .*;

public class DisplayServlet extiende HttpServlet { public void doPost (HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException { resp.setContentType ("text / html"); a cabo PrintWriter = resp.getWriter (); out.println ("<html> <title> pantalla de información"); out.println ("</ title> </ head> <body>"); out.println ("Hola, mundo"); out.println ("</ body> </ HTML>"); } }

El contenedor de servlets debe escribir los encabezados de la respuesta antes de comprometerse, porque en los encabezados HTTP deben ser enviados antes de que el cuerpo de la respuesta.

Este método no tiene que ser segura o idempotente. Operaciones solicitadas por POST puede tener efectos adversos para los que el usuario puede ser responsable, por ejemplo, la actualización de los datos almacenados o comprar artículos en línea.

POST propósito método.

El método POST se utiliza para solicitar que el servidor de origen de aceptar la entidad incluida en la solicitud como un subordinado de nuevo el recurso identificado por el URI en la Solicitud de línea. POST está diseñado para permitir un método uniforme para cubrir las siguientes funciones:

Anotación de los recursos existentes;

Publicar un mensaje a un tablón de anuncios, grupos de noticias, listas de correo, o grupo de artículos similares;

Proporcionar un bloque de datos, como el resultado de la presentación de un formulario, a un proceso de manipulación de datos;

Ampliación de una base de datos a través de una operación de anexión.

En resumen, este método se debe utilizar para enviar mensajes grupos de noticias, la presentación de los campos de datos de largo a una base de datos (por ejemplo, una inserción de SQL de cadena larga), o el envío de archivos binarios con el servidor.

POST características del método técnico.

Envía información al servidor, tales como los campos de formulario, grandes cuerpos de texto, y los pares de clave y valor.

Oculta los datos de forma de los usuarios, ya que no se pasa como una cadena de consulta, pero en el cuerpo del mensaje.

Envía ilimitado de datos de longitud como parte de su cuerpo de la petición HTTP.

Para el envío de ASCII (texto) o datos binarios.

Impide favoritos.

método POST desencadenantes.

El navegador envía una petición HTTP POST cuando:

El usuario (o JavaScript) envía un formulario que especifica el método de atributo = "POST":

<form method="POST"> action="/servlet/display" Nombre: <input type="text" name="firstName"> <p> Apellido: <input type="text" name="lastName"> <p> <input type="submit" value="Display"> </ Form>

doPut para el manejo de solicitudes HTTP PUT.

protegidas doPut void (HttpServletRequest req, HttpServletResponse resp) lanza ServletException, IOException

Llamado por el servidor (a través del método de servicio) para permitir un servlet para manejar un requerimiento. La operación de venta permite a un cliente para colocar un archivo en el servidor y es similar a enviar un archivo por FTP. Al reemplazar este método, dejará intacta cualquier encabezado contenidos enviados con la solicitud (incluyendo Content-Length, Content-Type, Content-Transfer-Encoding, Content-Encoding, Content-Base, contenido del lenguaje, contenido en la localización, Content-MD5, y Content-Range). Si el método no puede manejar un encabezado de contenido, que debe emitir un mensaje de error y deseche la petición.

Este método no tiene que ser segura o idempotente. Las operaciones que realiza doPut puede tener efectos adversos para los que el usuario puede ser considerado responsable. Cuando se utiliza este método, puede ser útil para guardar una copia de la URL afectados en depósito temporal.

La diferencia fundamental entre el poste y peticiones PUT se refleja en el significado de la petición-URI. El URI de una petición POST identifica el recurso que se encargará de la entidad cerrada. Ese recurso puede ser un proceso de datos que se acepta, una puerta de entrada a otro protocolo, o una entidad independiente que acepta anotaciones. Por el contrario, el URI en una solicitud PUT identifica la entidad adjunta a la solicitud - el agente de usuario sabe lo que tiene por objeto URI y el servidor NO DEBE intento de aplicar la solicitud de algún otro recurso.

<form enctype="multipart/form-data" action="some_url" method="PUT"> name="fileToUpload" <input type="file" value="Select File"> <input type="submit" value="Upload"> <input type="reset" value="Reset"> </ Form>

doDelete para el manejo de solicitudes HTTP DELETE.

protected void doDelete (HttpServletRequest req, HttpServletResponse resp) lanza ServletException, IOException

Llamado por el servidor (a través del método de servicio) para permitir un servlet para manejar un requerimiento. La operación DELETE permite a un cliente para eliminar un documento o página Web del servidor. Este método no tiene que ser segura o idempotente. Operaciones solicitadas a través BORRAR puede tener efectos adversos para los usuarios que pueden ser considerados responsables. Cuando se utiliza este método, puede ser útil para guardar una copia de la URL afectados en depósito temporal.

doHead para el manejo de solicitudes HTTP HEAD.

doHead protected void (HttpServletRequest req, HttpServletResponse resp) lanza ServletException, IOException

Recibe una solicitud HTTP HEAD del método de servicios protegidos y se ocupa de la solicitud. El cliente envía una solicitud HEAD cuando se quiere ver sólo los encabezados de una respuesta, por ejemplo, Content-Type o Content-Length. El método HTTP HEAD cuenta los bytes de salida en la respuesta para establecer el encabezado Content-Length precisión. El método doHead en HttpServlet es una forma especializada del método doGet que devuelve sólo los encabezados producido por el método doGet.

doOptions para el manejo de solicitudes HTTP OPTIONS.

doOptions protected void (HttpServletRequest req, HttpServletResponse resp) lanza ServletException, IOException

Llamado por el servidor (a través del método de servicio) para permitir un servlet para controlar una solicitud de OPCIONES. La solicitud de OPCIONES determina qué métodos HTTP del servidor de soportes y devuelve un encabezado apropiado. Por ejemplo, si un servlet doGet anulaciones, este método devuelve el siguiente encabezado:

Permitir: GET, HEAD, TRACE, OPCIONES doTrace para el manejo de solicitudes HTTP TRACE.

protegidas doTrace void (HttpServletRequest req, HttpServletResponse resp) lanza ServletException, IOException

Llamado por el servidor (a través del método de servicio) para permitir un servlet para manejar una petición TRACE. El método doTrace genera una respuesta que contiene todas las instancias de las cabeceras enviadas en la solicitud TRACE al cliente, para que puedan ser utilizados en la depuración. No hay necesidad de reemplazar este método.

Por lo general en el desarrollo de servlets basado en HTTP, un desarrollador de Servlet solo se preocupa con los métodos doGet y doPost. Los otros métodos son considerados como los métodos para el uso de programadores muy familiarizado con la programación HTTP.

Uso de la interfaz HttpServletRequest, escribir código para recuperar los parámetros de formulario HTML de la petición, recuperar la información del encabezado de solicitud HTTP, o recuperar las cookies de la petición.

Los parámetros del protocolo HTTP.

Solicitud de parámetros para el servlet son las cadenas enviadas por el cliente a un contenedor de servlets como parte de su solicitud. Cuando la solicitud es un objeto HttpServletRequest, el contenedor se llena los parámetros de la cadena de consulta URI y datos POST-ed.

Los parámetros se almacenan como un conjunto de pares nombre-valor. parámetro de múltiples valores pueden existir para cualquier nombre de parámetro dado. Los siguientes métodos de la interfaz de ServletRequest están disponibles para los parámetros de acceso:

getParameter

Devuelve el valor de un parámetro de la petición como una cadena, o null si el parámetro no existe. Solicitar los parámetros son la información adicional enviada con la solicitud. Para los servlets HTTP, los parámetros figuran en la cadena de consulta o publicado los datos del formulario.

Sólo debe utilizar este método cuando se está seguro de que el parámetro tiene un único valor. Si el parámetro puede tener más de un valor, getParameterValues uso (String).

Si utiliza este método con un parámetro de varios valores, el valor devuelto es igual al primer valor de la matriz devuelta por getParameterValues.

Si los datos de los parámetros se envían en el cuerpo de la solicitud, tal como ocurre con una petición HTTP POST, luego de leer el cuerpo directamente a través de getInputStream () o getReader () puede interferir con la ejecución de este método.

getParameterNames

Devuelve una enumeración de objetos String que contiene los nombres de los parámetros contenidos en esta solicitud. Si la solicitud no tiene parámetros, el método devuelve una enumeración VACÍA.

getParameterValues

Devuelve una matriz de objetos String que contiene todos los valores del parámetro de la petición se ha dado, o null si el parámetro no existe. Si el parámetro tiene un valor único, la matriz tiene una longitud de 1.

getParameterMap

Devuelve un java.util.Map inmutable que contiene los nombres de parámetros como claves y valores de los parámetros como los valores del mapa. Las claves en el mapa de parámetros son de tipo String. Los valores en el mapa de parámetros son de tipo de matriz de cadena.

ServletRequest pública interfaz {

getParameter pública java.lang.String (java.lang.String nombre); getParameterNames pública java.util.Enumeration (); pública java.lang.String [] getParameterValues (java.lang.String nombre); getParameterMap java.util.Map público ();

}

El método getParameterValues devuelve un array de objetos String que contiene todos los valores de los parámetros asociados a un nombre de parámetro. El valor devuelto por el método getParameter debe ser el primer valor de la matriz de objetos String devuelto por getParameterValues. El método devuelve un getParameterMap java.util.Map del parámetro de la solicitud, que contiene nombres como claves y valores de los parámetros como los valores del mapa.

public void doPost (HttpServletRequest solicitud, HttpServletResponse res) throws IOException, ServletException { Enumeración e = request.getParameterNames ();

a cabo PrintWriter = res.getWriter (); while (e.hasMoreElements ()) { String nombre = (String) e.nextElement (); Valor de cadena = request.getParameter (nombre); out.println (nombre + "=" + valor); } } Los datos de la cadena de consulta y el cuerpo de la entrada se agregan en el conjunto de parámetro de la petición. datos de cadena de consulta se presenta antes de los datos del cuerpo de correos. Por ejemplo, si una solicitud se hace con una cadena de consulta de a = "hola" y un cuerpo después de un adiós = = y un mundo, el conjunto de parámetros resultantes se ordenó a = (hola, adiós, mundo).

Las siguientes son las condiciones que deben cumplirse antes de los datos de envío de formulario se rellenará con el conjunto de parámetros:

La solicitud es una solicitud HTTP o HTTPS.

El método HTTP POST es.

El tipo de contenido es application / x-www-form-urlencoded.

El servlet ha hecho una convocatoria inicial de cualquiera de la familia "getParameter 'de los métodos con el objeto de solicitud.

Si las condiciones no se cumplen y los datos del formulario de envío no está incluido en el conjunto de parámetros, los datos enviados todavía debe estar disponible para el servlet a través de flujo de entrada del objeto de la petición de. Si se cumplen las condiciones, los datos de envío de formulario ya no esté disponible para la lectura directa de la corriente de entrada del objeto de la petición de. Cabeceras.

Un servlet puede acceder a las cabeceras de una petición HTTP a través de los siguientes métodos de la interfaz HttpServletRequest:

getHeader

Devuelve el valor del encabezado de la solicitud se especifica como una cadena. Si la solicitud no incluye un encabezado con el nombre especificado, este método devuelve null. Si hay varios encabezados con el mismo nombre, este método devuelve el primer jefe en la solicitud. El nombre de encabezado de mayúsculas y minúsculas. Usted puede utilizar este método con cualquier encabezado de la solicitud.

getHeaders

Devuelve todos los valores del encabezado de la solicitud se especifica como una enumeración de objetos String.

Algunas de las cabeceras, como Accept-Language pueden ser enviados por los clientes como los encabezados de varios, cada uno con un valor diferente en lugar de enviar la cabecera como una lista separada por comas. Si la solicitud no incluye todos los encabezados con el nombre especificado, este método devuelve una enumeración VACÍA. El nombre de la cabecera es sensible a mayúsculas. Usted puede utilizar este método con cualquier encabezado de la solicitud.

getHeaderNames

Devuelve una enumeración de todos los nombres de encabezado de la solicitud contiene. Si la solicitud no tiene cabeceras, este método devuelve una enumeración vacía.

El método getHeader devuelve un encabezado con el nombre de la cabecera. No puede haber varios encabezados con el mismo nombre, por ejemplo, Cache-Control de las cabeceras, en una solicitud HTTP. Si hay varios encabezados con el mismo nombre, el método getHeader devuelve el primer jefe en la solicitud. El método getHeaders permite el acceso a toda la cabecera de los valores asociados a un nombre de encabezado en particular, devolver un recuento de objetos String. {Public interface HttpServletRequest

getHeader pública java.lang.String (java.lang.String nombre); getHeaders pública java.util.Enumeration (java.lang.String nombre); getHeaderNames pública java.util.Enumeration ();

}

Encabezados pueden contener representaciones de cadena de datos int o Fecha.Los siguientes métodos de conveniencia de la interfaz HttpServletRequest proporcionar acceso a los datos de cabecera en un uno de estos formatos:

getIntHeader

Devuelve el valor del encabezado de la solicitud se especifica como un entero. Si la solicitud no tiene un encabezado con el nombre especificado, este método devuelve -1. Si la cabecera no se puede convertir en un entero, este método produce una NumberFormatException.

El nombre de la cabecera es sensible a mayúsculas.

getDateHeader

Devuelve el valor del encabezado de la solicitud se especifica como un valor de tiempo que representa un objeto Date. Utilice este método con cabeceras que contienen fechas, tales como If-Modified-Since ".

La fecha se devuelve como el número de milisegundos desde el 1 de enero 1970 GMT. El nombre de encabezado de mayúsculas y minúsculas.

Si la solicitud no tiene un encabezado con el nombre especificado, este método devuelve -1. Si el encabezado no puede ser convertido a una fecha, el método produce una IllegalArgumentException.

Si el método getIntHeader no puede traducir el valor de encabezado a un int, un NumberFormatException se produce. Si el método getDateHeader no puede traducir el encabezado de un objeto Date, una IllegalArgumentException se produce. {Public interface HttpServletRequest

getIntHeader public int (java.lang.String nombre); getDateHeader públicas de largo (java.lang.String nombre);

}

public void doGet (HttpServletRequest petición, la respuesta de HttpServletResponse) throws IOException, ServletException { response.setContentType ("text / html"); a cabo PrintWriter = response.getWriter (); Enumeración e = request.getHeaderNames (); while (e.hasMoreElements ()) { String nombre = (String) e.nextElement (); valor String = request.getHeader (nombre); out.println (nombre + "=" + valor); } }

Las cookies.

La interfaz HttpServletRequest proporciona el método getCookies para obtener una gran variedad de cookies que están presentes en la solicitud. Este método devuelve null si no se envían las cookies.

Las cookies son datos que se envían desde el cliente al servidor en cada petición que realiza el cliente. Normalmente, la única información que el cliente envía como parte de una "cookie" es el nombre de la cookie y el valor de la cookie. Otros atributos de cookies que se pueden establecer cuando la cookie es enviada al navegador, tales como comentarios, no suelen ser devueltos. Varios cookies podría tener el mismo nombre pero con diferentes atributos camino.

{public interface HttpServletRequest

public Cookie [] getCookies ();

}

package javax.servlet.http;

public class Cookie implements java.lang.Cloneable { ... public Cookie (java.lang.String nombre, java.lang.String valor); java.lang.String getName público (); getPath java.lang.String público (); getValue java.lang.String público (); ... }

Utilizando la interfaz HttpServletResponse, escribir código para configurar un encabezado de respuesta HTTP, establecer el tipo de contenido de la respuesta, adquirir una secuencia de texto para la respuesta, adquirir una secuencia binaria para la respuesta, redireccionar una petición HTTP a otra URL o añadir cookies para la respuesta.

Cabeceras.

Un servlet puede establecer los encabezados de respuesta HTTP a través de los siguientes métodos de la interfaz HttpServletResponse:

setHeader

Establece un encabezado de respuesta con el nombre y valor. Si la cabecera ya había sido establecido, el nuevo valor sobrescribe la anterior. El método containsHeader se puede utilizar para detectar la presencia de una cabecera antes de su valor.

addHeader

Agrega un encabezado de respuesta con el nombre y valor. Este método permite a los encabezados de respuesta para tener varios valores.

public interface HttpServletResponse extiende javax.servlet.ServletResponse {

setHeader public void (java.lang.String nombre, java.lang.String valor); addHeader public void (java.lang.String nombre, java.lang.String valor);

}

El método setHeader establece un encabezado con un nombre y valor. Un encabezado anterior se sustituye por el nuevo encabezado. Cuando un conjunto de valores de la cabecera existen para el nombre, los valores se borran y se reemplaza con el nuevo valor.

El método addHeader agrega un valor de cabecera a la serie con un nombre determinado. Si no hay cabeceras ya está asociado con el nombre, un nuevo conjunto se ha creado.

Encabezados pueden contener datos que representa un int o un objeto Date. Los siguientes métodos de conveniencia de la interfaz HttpServletResponse permite un servlet para establecer un encabezado con el formato correcto para el tipo de datos adecuado:

setIntHeader

Establece un encabezado de respuesta con el nombre y valor entero. Si la cabecera ya se habían establecido, el nuevo valor sobrescribe la anterior. El método containsHeader se puede utilizar para detectar la presencia de una cabecera antes de su valor.

setDateHeader

Establece un encabezado de respuesta con el nombre y valor de fecha. La fecha se expresa en términos de milisegundos desde la época. Si la cabecera ya se habían establecido, el nuevo valor sobrescribe la anterior. El método containsHeader se puede utilizar para detectar la presencia de una cabecera antes de su valor.

addIntHeader

Agrega un encabezado de respuesta con el nombre y valor entero. Este método permite a los encabezados de respuesta para tener varios valores.

addDateHeader

Agrega un encabezado de respuesta con el nombre y valor de fecha. La fecha se expresa en términos de milisegundos desde la época. Este método permite a los encabezados de respuesta para tener varios valores.


setIntHeader public void (java.lang.String nombre, int valor); setDateHeader public void (java.lang.String nombre, fecha de largo); addIntHeader public void (java.lang.String nombre, int valor); addDateHeader public void (java.lang.String nombre, fecha de largo);

}

Para ser transmitido correctamente al cliente, los encabezados se debe establecer antes de la respuesta se ha comprometido. Encabezados fijará después de la respuesta se ha comprometido a ser ignorado por el contenedor de servlets.

Tipo de contenido.

El juego de caracteres de la respuesta del cuerpo MIME puede especificarse explícitamente usando la setContentType (String). especificaciones explícitos tienen prioridad sobre las especificaciones implícitas. Si no se especifica juego de caracteres ISO-8859-1 se utilizará. El método setContentType debe ser llamada antes getWriter y ANTES de cometer la respuesta para la codificación de caracteres a utilizar.

Hay dos maneras de definir el tipo de contenido:

ServletResponse.setContentType (String);

HttpServletResponse.setHeader ("Content-Type", "text / html");

Adquirir una secuencia de texto.

Para enviar los datos de caracteres, utilice el objeto devuelto por ServletResponse.getWriter PrintWriter ()

public interface ServletResponse {

getWriter java.io.PrintWriter público () throws IOException;

}

Devuelve un objeto PrintWriter que pueden enviar mensajes de texto de caracteres para el cliente. El PrintWriter utiliza la codificación de caracteres devueltos por getCharacterEncoding (). Llamar a flush () en el PrintWriter compromete la respuesta.

O bien este método o getOutputStream () puede ser llamado a escribir el cuerpo, NO TANTO.

Adquirir una secuencia binaria.

ServletResponse.getOutputStream () proporciona un flujo de salida para el envío de datos binarios en el cliente. Un objeto ServletOutputStream normalmente se recuperan a través de este método.

public interface ServletResponse {

pública getOutputStream ServletOutputStream () throws IOException;

}

El contenedor de servlets no codifica los datos binarios.

Llamar a flush () en el ServletOutputStream compromete la respuesta. O bien este método o getWriter () puede ser llamado a escribir el cuerpo, NO TANTO.

Redirigir una petición HTTP a otra URL.

El método HttpServletResponse.sendRedirect establecerá las cabeceras adecuadas y el cuerpo de contenido para redirigir el cliente a un URL diferente. Es legal para llamar a este método con una dirección URL relativa, sin embargo, el contenedor subyacente debe traducir la ruta de acceso relativa a una dirección URL completa para la transmisión de vuelta al cliente. Si una URL parcial se da y, por cualquier razón, no se puede convertir en una dirección URL válida, este método debe lanzar una IllegalArgumentException.


public void sendRedirect (ubicación java.lang.String) throws IOException;

}

Envía una redirección temporal respuesta al cliente mediante el redireccionamiento de URL se especifica la ubicación. Este método puede aceptar direcciones URL relativas, el contenedor de servlets debe convertir la dirección URL relativa a una dirección URL absoluta antes de enviar la respuesta al cliente. Si la ubicación es relativa, sin que uno de los principales '/' el contenedor lo interpreta como relativa a la solicitud actual URI. Si la ubicación es relativa a una de las principales '/' el contenedor lo interpreta como relativa a la raíz contenedor de servlets.

Si la respuesta ya se ha comprometido, este método produce una IllegalStateException. Después de usar este método, la respuesta debe ser considerado como cometido y no se debe escribir.

Este método tiene como efecto colateral de la comisión de la respuesta, si no se ha cometido, y darlo por terminado. No hay salida de más al cliente debe ser hecha por el servlet después de que estos métodos son llamados. Si los datos se escriben en la respuesta después de este método son los llamados, los datos se ignoran.

Si los datos se hayan escrito en el búfer de respuesta, pero no se devuelve al cliente (es decir, la respuesta es no comprometidos), los datos en el búfer de respuesta debe ser reemplazada por el conjunto de datos con estos métodos. Si la respuesta se ha comprometido, este método debe lanzar una IllegalStateException.

Añadir las cookies para la respuesta.

El servlet envía las cookies en el navegador mediante el HttpServletResponse.addCookie (Cookie), el cual agrega campos a las cabeceras de respuesta HTTP para enviar las cookies en el navegador, de uno en uno. El navegador se espera apoyar a 20 cookies para cada servidor Web, cookies total de 300, y puede limitar el tamaño de cada cookie a 4 KB cada una.


addCookie public void (cookie Cookie);

}

Ciclo de vida de un servlet

Describir la secuencia de objetivos y eventos del ciclo de vida del servlet: (1) la carga de clases servlet, (2) creación de instancias de servlet, (3) llamar al método init, (4) llamar al método de servicio, y (5) llamado método destroy.

Un servlet es administrado a través de un ciclo de vida bien definido que define la forma en que se carga y se crea una instancia, se inicializa, se ocupa de las peticiones de los clientes, y está fuera de servicio. Este ciclo de vida se expresa en el API por el inicio, el servicio, y destruir los métodos de la interfaz javax.servlet.Servlet que todos los servlets debe aplicar directamente o indirectamente a través de la GenericServlet o clases HttpServlet abstracto.

Servlet carga de clases y de instancias.

El contenedor de servlets es responsable de cargar y crear instancias de servlets. La carga y la creación de instancias se puede producir cuando el contenedor se inicia, o retrasarse hasta el contenedor determina el servlet que se necesita para atender una solicitud.

Cuando el motor servlet se ha iniciado, necesita clases de servlets, deberá colocarse el contenedor de servlets. Las cargas de contenedor de servlets la clase servlet de Java utilizando las instalaciones de carga normal de clases. La carga puede ser de un sistema de archivos local, un sistema de archivos remoto, u otros servicios de red.

Después de cargar la clase servlet, el contenedor se crea una instancia para su uso.

Servlet de inicialización de la clase.

Después de que el objeto se crea una instancia de servlet, el contenedor debe inicializar el servlet antes de poder tramitar las solicitudes de los clientes.Inicialización se proporciona para que un servlet puede leer los datos persistentes de configuración, inicializar los recursos costosos (como las conexiones JDBC), y realizar otras actividades de una sola vez. El contenedor inicializa la instancia de servlet llamando al método init de la interfaz Servlet con un único (por declaración de servlet) objeto que implementa la interfaz ServletConfig.

public interface Servlet {

public void init (ServletConfig config) throws ServletException;

}

Este objeto de configuración permite que el servlet para acceder a los parámetros de nombre y valor de inicialización de la información de configuración de la aplicación de laWeb. El objeto de configuración también le da el acceso servlet a un objeto (que implementa la interfaz ServletContext) que describe el medio ambiente servlet tiempo de ejecución.Durante la inicialización, la instancia de servlet puede lanzar una UnavailableException o ServletException uno. En este caso, el servlet no deben ser puestos en servicio activo y debe ser puesto en libertad por el contenedor de servlets. El método de destruir no se llama ya que se considera la inicialización sin éxito.

Una nueva instancia puede crear una instancia y se inicializa el contenedor después de la inicialización ha fallado. La excepción a esta regla es cuando un UnavailableException corresponde a un tiempo mínimo de indisponibilidad, y el contenedor debe esperar a que el período de pasar antes de crear e inicializar una instancia de servlet nuevo.

Solicitud de manipulación.

Después de un servlet está correctamente inicializado, el contenedor de servlets pueden utilizar para manejar peticiones de clientes. Las solicitudes están representados por objetos petición de ServletRequest tipo. El servlet llena de respuesta a las solicitudes de llamar a los métodos de un objeto siempre de tipo ServletResponse. Estos objetos se pasan como parámetros al método de servicio de la interfaz Servlet.


public void service(ServletRequest req, res ServletResponse)lanza ServletException, IOException;

}

En el caso de una petición HTTP, los objetos proporcionados por el envase son de tipo HttpServletRequest y HttpServletResponse.

public abstract class HttpServlet extends javax.servlet.GenericServletimplements java.io.Serializable {

protected void service(HttpServletRequest req, HttpServletResponse res)throws ServletException, IOException;

}

Tenga en cuenta que una instancia de servlet puesto en servicio por un contenedor de servlets puede manejar ninguna solicitud durante su vida útil.

Fin del servicio.

El contenedor de servlets no está obligada a mantener un servlet carga por un periodo de tiempo determinado. Una instancia de servlet puede mantenerse activo en un contenedor de servlets por un período de milisegundos, durante la vida útil del contenedor de servlets (que podría ser un número de días, meses o años), o cualquier cantidad de tiempo en el medio.

Cuando el contenedor de servlets determina que un servlet debe ser retirado del servicio, llama al método destroy de la interfaz Servlet para permitir que el servlet para liberar los recursos que está utilizando y guardar cualquier estado persistente.Por ejemplo, el contenedor puede hacer esto cuando se quiere conservar los recursos de memoria, o cuando se está cerrando.


public void destroy ();

}

Antes de que el contenedor servlet llama al método destroy, debe permitir que ninguna de las discusiones que se están ejecutando actualmente en el método de servicio del servlet para completar la ejecución, o superar un límite de tiempo definido por el servidor.

Una vez que el método de destrucción se llama en una instancia de servlet, el contenedor no puede enrutar las solicitudes de otros a esa instancia del servlet. Si el envase tiene que permitir que el servlet de nuevo, debe hacerlo con una nueva instancia de la clase del servlet.

Después de que el método destroy se completa, el contenedor de servlets debe liberar la instancia de servlet para que sea elegible para la recolección de basura.

La estructura y el despliegue de aplicaciones Web

Una aplicación web que existe una jerarquía estructurada de directorios. La raíz de esta jerarquía sirve como la raíz de documentos de los archivos que forman parte de la solicitud. Por ejemplo, para una aplicación web con la ruta del contexto y el catálogo en un contenedor Web, el archivo index.html en la base de la jerarquía de la aplicación web puede servir para satisfacer una petición de / catalog / index.html.

Un directorio especial existe dentro de la jerarquía de aplicación denominada "WEB-INF". Este directorio contiene todo lo relacionado con la aplicación que no están en la raíz del documento de la solicitud. El nodo WEB-INF no es parte de la estructura del documento público de la solicitud. No existe el fichero que figura en el directorio WEB-INF se puede servir directamente a un cliente por el contenedor. Sin embargo, el contenido del directorio WEB-INF son visibles para los servlet de código usando el método de getResourceAsStream GetResource y pide a la ServletContext, y puede ser expuesta con el RequestDispatcher llamadas. Por lo tanto, si el desarrollador de la aplicación necesita acceder, a partir de código servlet, a la información de configuración de aplicación específica que no quieran estar expuestos directamente al cliente Web, puede colocarlo en este directorio. Dado que las solicitudes se hacen coincidir con las asignaciones de recursos de una manera entre mayúsculas y minúsculas, las solicitudes de cliente para / WEB-INF/foo, / WEb-iNf/foo, por ejemplo, no debe dar lugar a contenidos de la aplicación web se encuentra en / WEB-INF se devuelto, ni ninguna forma de lista de directorios de los mismos.

El contenido del directorio WEB-INF son:

El descriptor / despliegue WEB-INF/web.xml.

El / WEB-INF/classes / guía para las clases de servlets y utilidad. Las clases de este directorio debe estar a disposición del cargador de clases de la aplicación.

El / WEB-INF/lib / *. jar área de archivos Java Archive. Estos archivos contienen los servlets, los beans y otras clases de servicios públicos de utilidad para la aplicación web. El cargador de aplicaciones Web de clase debe ser capaz de cargar las clases de cualquiera de estos ficheros de archivo.

El cargador de aplicaciones Web de clase debe cargar clases desde el directorio WEB-INF/classes primero, y después de la colección de JAR en el directorio WEB-INF/lib. Además, ninguna de las solicitudes del cliente para acceder a los recursos en WEB-INF / debe ser retornado con un SC_NOT_FOUND (404) de respuesta.

Las aplicaciones Web se pueden empaquetar y firmado en un formato de archivo Web (WAR) usando las herramientas estándar de Java archivo. Por ejemplo, una aplicación para seguimiento de problemas podría ser distribuido en un archivo llamado issuetrack.war.

En forma predeterminada en un formulario, un directorio META-INF se presente, que contiene información útil a las herramientas de archivo de Java. Este directorio, no deberán ser atendido directamente por el contenido como el contenedor en respuesta a la solicitud de un cliente Web, aunque su contenido sea visible a través del código de servlet GetResource y pide getResourceAsStream en el ServletContext. Además, las solicitudes de acceso a los recursos en el directorio META-INF debe ser retornado con un SC_NOT_FOUND (404) de respuesta.

Las extensiones de etiqueta escrita en los archivos JSP con etiquetas se pueden colocar en uno de los dos lugares. La primera posibilidad es en el directorio / META-INF/tags / directorio (o en un subdirectorio de / META-INF/tags /) en un archivo JAR instalado en el directorio / WEB-INF/lib / directorio de la aplicación web. Etiquetas colocado aquí suelen formar parte de una biblioteca reutilizable de etiquetas que se pueden fácilmente caer en cualquier aplicación web.

La segunda posibilidad es en el directorio / WEB-INF/tags / directorio (o en un subdirectorio de / WEB-INF/tags /) de la aplicación web. Etiquetas puesto aquí son de fácil acceso y requieren poco embalaje. Sólo los archivos con la extensión. Etiquetas o extensión. Tagx son reconocidos por el recipiente que los archivos de etiquetas.

archivos de la etiqueta que aparece en cualquier otro lugar no se consideran las extensiones de etiqueta y debe ser ignorado por el contenedor JSP. Por ejemplo, un archivo de etiqueta que aparece en la raíz de una aplicación web se tratan como contenido para ser servido.

La siguiente es una lista de todos los archivos en una aplicación Web de ejemplo:

/ Index.html / Howto.jsp / Feedback.jsp / Images / banner.gif / Images / jumping.gif / WEB-INF/web.xml / WEB-INF/lib/jspbean.jar / WEB-INF/lib/jstl.jar / WEB-INF/jsp/example-taglib.tld / WEB-INF/jsp/debug-taglib.tld / WEB-INF/jsp2/jsp2-example-taglib.tld / WEB-INF/tags/displayProducts.tag / WEB-INF/tags/helloWorld.tag / WEB-INF/tags/panel.tag / WEB-INF/tags/xhtmlbasic.tag / WEB-INF/classes/com/mycorp/servlets/MyServlet.class / WEB-INF/classes/com/mycorp/util/MyUtils.class

Construir la estructura correcta para cada uno de los elementos del descriptor de implementación siguientes: Error de páginas, init-param, mimo mapeo, servlet, el servlet-clase, servlet-mapping, el nombre del servlet, y dar la bienvenida-archivo.

Las páginas de error.

<! - El elemento de error de página contiene una asignación entre un código de error o excepción de tipo a la vía de un recurso en la aplicación web ->

<!ELEMENT error-page ((error-code | exception-type), location)>

Parámetros de inicio.

<! - El elemento init-param contiene un par nombre / valor como parámetros de inicialización del servlet ->

<!ELEMENT init-param (param-name, param-value, description?)>

Elemento MIME.

<! - El elemento mime-mapping define una asignación entre una extensión y un tipo de MIME. ->

<Mimo! ELEMENTO-mapping (extensión, tipo MIME)>

<! - El elemento de extensión contiene una cadena que describe un de extensión. ejemplo: "txt" ->

<! Elemento de extensión (# PCDATA)>

<! - El elemento de tipo MIME contiene un tipo MIME definido. ejemplo: "text / normal " ->

<! Mimo tipo de elemento (# PCDATA)>

Servlet.

<! - El elemento servlet contiene los datos declarativa de un servlet. Si un archivo jsp-se especifica y es el elemento de carga en el arranque presente, entonces el JSP debe ser compilados y cargados. ->

<! Servlet ELEMENTO (icono?, Servlet-name, display-name?, Descripción?, (Servlet-clase | archivo jsp), * init-param, carga en el arranque,? la seguridad de rol ref *)>

<! - El elemento servlet-name contiene el nombre canónico de la servlet. ->

<! ELEMENTO servlet-name (# PCDATA)>

<! - El elemento servlet-clase que contiene el nombre de clase completo del servlet. ->

<! Servlet ELEMENTO Class (# PCDATA)>

<! - El elemento jsp-archivo contiene la ruta completa a un archivo JSP en la aplicación web. ->

<! ELEMENTO jsp-file (# PCDATA)>

mapeo de Servlet.

<! - El elemento servlet-mapping define una asignación entre un servlet y un patrón de URL

-> <Servlet! ELEMENTO-mapping (servlet-name, url-pattern)>

Bienvenido archivos.

<! - La bienvenida lista de archivos contiene una lista ordenada de los archivos de bienvenida elementos. ->

<! ELEMENTO bienvenida lista de archivos (archivo de bienvenida +)>

env-entrada

<! - El elemento env-entrada contiene la declaración de uno de aplicaciones medio ambiente de entrada. Este elemento debe ser honrada en en J2EE servlet compatible contenedores.

El elemento env-entrada-tipo contiene el tipo de Java totalmente calificado de el valor de entrada de entorno que se espera por la aplicación código.

Los siguientes son los valores legales de env de entrada de tipo: java.lang.Boolean, java.lang.String, java.lang.Integer, java.lang.Double, java.lang.Float. ->

<! Env ELEMENTO-entrada (descripción?, Env-entrada-nombre, env-entrada-valor?, env-entrada-tipo)>

<env-entry> <env-entry-name> TableName </ env-nombre de la entrada-> <env-entry-value> StockTable </ env-valor de la entrada-> <env-entry-type> java.lang.String </ env-tipo de entrada-> </ Entry env->

ejb-ref

<! - El elemento ejb-ref se utiliza para la declaración de una referencia a un bean de empresa está en casa. La declaración se compone de: - Una descripción opcional - El nombre de referencia EJB utiliza en el código de la aplicación web que hace referencia el grano de la empresa - El tipo esperado de la empresa de referencia del frijol - La casa de espera y las interfaces de control remoto de la referencia empresa de frijol - Información opcional ejb-link, que se utiliza para especificar la referencia empresa de frijol

El elemento ejb-ref se utiliza para declarar una referencia a una empresa de frijol.

El elemento ejb-ref-name contiene el nombre de un EJB de referencia. Este es el nombre JNDI que el código de servlet utiliza para obtener una referencia a la empresa de frijol.

El elemento ejb-ref-tipo contiene el tipo esperado de la referencia de frijol de la empresa.

El elemento ejb-ref-type debe ser uno de los siguientes:

<ejb-ref-type> Entidad </ ejb-ref-> Tipo de <ejb-ref-type> sesión </ ejb-ref tipo->

El elemento principal contiene el nombre completo de los EJB la interfaz de inicio

El elemento de mando a distancia contiene el nombre completo de los EJB interfaz remota

El elemento ejb-link se utiliza en el elemento ejb-ref para especificar que una referencia EJB está vinculada a un EJB en un abarca Java2 Enterprise Edition (J2EE), paquete de aplicación. El valor del elemento ejb-link tiene que ser el ejb-nombre y EJB en el paquete de aplicaciones J2EE. ->

<! ELEMENTO ejb-ref (descripción?, Ejb-ref-name, ejb-ref-tipo, el hogar, a distancia, ejb-link?)>

<-! De referencia sobre un grano de distancia sin ejb-link -> <ejb-ref> ejb <ejb-ref-name> / MySessionBean </ ejb-ref-nombre> <ejb-ref-type> sesión </ ejb-ref tipo-> <home> org.sample.beans.MySessionBeanHome </ home> <remote> org.sample.beans.MySessionBean </ a distancia> </ Ejb-ref>

<-! De referencia sobre un grano de distancia con ejb-link -> <ejb-ref> ejb <ejb-ref-name> / EjbLinkMySessionBean </ ejb-ref-nombre> <ejb-ref-type> sesión </ ejb-ref tipo-> <home> org.sample.beans.MySessionBeanHome </ home> <remote> org.sample.beans.MySessionBean </ a distancia> <ejb-link> MySB.jar # MySessionBean </ ejb-link> </ Ejb-ref>

ejb-local-ref

<! - El elemento ejb-local-ref se utiliza para la declaración de una referencia a la casa de un local de frijol empresa. La declaración se compone de: - Una descripción opcional - El nombre de referencia EJB utiliza en el código de la aplicación web que es referencia el grano de la empresa - El tipo esperado de la empresa de referencia del frijol - La casa de espera local y las interfaces locales de la referencia empresa de frijol - Información opcional ejb-link, que se utiliza para especificar la referencia empresa de frijol

El elemento ejb-ref-tipo contiene el tipo esperado de la referencia de frijol de la empresa.

El elemento ejb-ref-type debe ser uno de los siguientes:

<ejb-ref-type> Entidad </ ejb-ref-> Tipo de <ejb-ref-type> sesión </ ejb-ref tipo-> ->

<! ELEMENTO ejb-local-ref (descripción?, Ejb-ref-name, ejb-ref-tipo, local casa, local, ejb-link?)>

<-! De referencia sobre un grano de locales -> <ejb-local-ref> <ejb-ref-name> ejb / MySBLocal </ ejb-ref-name> <ejb-ref-type> sesión </ ejb-ref tipo-> <local-home> org.sample.beans.MySessionBeanLocalHome </ local-home> <local> org.sample.beans.MySessionBeanLocal </ local> secusb.jar <ejb-link> # Op </ ejb-link> </ Ejb-local-ref>

recursos-ref

<! - El elemento resource-ref contiene una declaración de un sitio Web de referencia de aplicación a un recurso externo.

El elemento de res-auth indica si el componente de aplicación código realiza inicio de sesión mediante programación de los recursos o si los signos de contenedores en el recurso basado en el principio de asignación información suministrada por el implementador. Debe ser CONTENEDOR o servlet! ->

Web <! ELEMENTO-ref (descripción?, Res-ref-name, res-tipo, res-auth)>

<resource-ref> <res-ref-name> jdbc / BookDB </ res nombre-ref-> <res-type> javax.sql.DataSource </ res de tipo> <res-auth> de contenedores </ res-auth> </ Ref recursos>

resource-env-ref

<! - El elemento resource-env-ref contiene una declaración de una red solicitud de referencia a un objeto administrado asociada a un de recursos en el entorno de la aplicación web. Se trata de un descripción opcional, el medio ambiente recurso de nombre de referencia, y una indicación del tipo de recurso de referencia medio ambiente espera el código de la aplicación web. ->

<! Recursos ELEMENTO-env-ref (descripción?, Resource-env-ref-name, resource-env-ref-type)>

<resource-env-ref> <resource-env-ref-name> jms / Pedidos </ resource-env-ref-nombre> <resource-env-ref-type> javax.jms.Queue </ resource-env-ref tipo-> </ Resource-ref env->

Documents

Tutorial Java WEB