Tutorial Java WEB
Cargado por
Carlos GarciaTutorial Java WEB
Cargado por
Carlos GarciaCapí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.
public interface HttpServletResponse extiende javax.servlet.ServletResponse {
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 interface HttpServletResponse extiende javax.servlet.ServletResponse {
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.
public interface HttpServletResponse extiende javax.servlet.ServletResponse {
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 interface 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.GenericServlet
implements 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 interface Servlet {
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->
