619 javaserver pages

JavaServer PagesItinerario Bases de Datos con Java. NIVEL II

Colección temática del manual: Programación y Desarrollo

Propiedad del manual: Garben Consultores

Datos del autor del manual: Marta Costales Pérez

Datos del revisor del manual: Miguel Paniagua López de Haro

MANUAL DE CONECTIVIDAD A BASES DE DATOS CON JAVA

objetivos unidad didáctica 1MANUAL CONECTIVIDAD A BBDD CON JAVA. NIVEL II

Comprender la relevancia de la plataforma web en desarrollo de aplicaciones telemá-ticas.

Conocer y manejar los conceptos, criterios y notaciones del modelado de sistemas infor-máticos, utilizados en el campo específico de las aplicaciones web.

Obtener un conocimiento práctico de las herramientas, tecnologías y lenguajes utilizados en el desarrollo de aplicaciones web.

Conocer los elementos necesarios para la puesta en servicio de una aplicación web.

/4

JDBC / índice

índice12

3

Índice de contenidoUNIDAD DIDÁCTICA 1. JAVA SERVER PAGES 6

LECCION 1: ENTORNO DESARROLLO DE JSP 6

INTRODUCCIÓN 6

1.1 ARQUITECTURA EMPRESARIAL. J2EE 6

1.2 JAKARTA TOMCAT 10

1.3 INSTALACIÓN DE JAKARTA TOMCAT 11

1.4 ESTRUCTURA DE DIRECTORIOS DE JAKARTA TOM... 12

1.5 FICHEROS DE CONFIGURACIÓN 13

LECCION 2: INTRODUCCIÓN A JSP (JAVASERVER PAGES) 21

INTRODUCCIÓN 21

1.1 DEFINICIÓN DE PÁGINA JSP 22

1.2 ELEMENTOS DE LAS PÁGINAS JSP 23

1.3 EJECUCIÓN DE LAS PÁGINAS JSP 24

1.4 JSP 2.0 Y EL (EXPRESION LANGUAJE) 25

1.5 JSTL 25

LECCION 3: DIRECTIVAS Y ELEMENTOS SCRIPTING 29

INTRODUCCIÓN 29

1.1 DIRECTIVAS 29

1.2 DIRECTIVA PAGE 30

1.3 DIRECTIVA INCLUDE 34

1.4 DIRECTIVA TAGLIB 35

1.5 ELEMENTOS DE SCRIPTING 35

LECCION 4: OBJETOS INTEGRADOS 42

INTRODUCCIÓN 42

1.1 EL OBJETO REQUEST 42

1.2 EL OBJETO RESPONSE 44

1.3 EL OBJETO OUT 45

1.4 EL OBJETO EXCEPTION 46

1.5 EL OBJETO SESSION 46

1.6 EL OBJETO APPLICATION 49

1.7 EL OBJETO PAGECONTEXT 49

1.8 EL OBJETO PAGE 50

1.9 EL OBJETO CONFIG 51

/5

JDBC / índice

LECCION 5: TRATAMIENTO DE ERRORES EN JSP 53

INTRODUCCIÓN 53

1.1 TIPOS DE ERRORES Y EXCEPCIONES 53

1.2 PÁGINAS JSP DE ERROR 53

1.3 EJEMPLO DE TRATAMIENTO DE ERRORES 55

LECCION 6: ACCIONES 68

INTRODUCCIÓN 68

1.1 <JSP:FORWARD> 68

1.2 <JSP:INCLUDE> 68

1.3 <JSP:PARAM> 69

1.4 <JSP:PLUGIN> 69

1.5 <JSP:USEBEAN> 69

1.6 <JSP:SETPROPERTY> 71

1.7 <JSP:GETPROPERTY> 72

EJERCICIOS MANUAL CONECTIVIDAD A BBDD CON JAVA 74

SOLUCIONES MANUAL CONECTIVIDAD A BBDD CON JAVA. 76

GLOSARIO 83

lección 1: Entorno desarrollo de JSP

/ 6

u.d. 1 NIVEL IIunidad didáctica 1:

UNIDAD DIDÁCTICA 1. JAVA SERVER PAGES

LECCION 1: ENTORNO DESARROLLO DE JSPINTRODUCCIÓN1.1 ARQUITECTURA EMPRESARIAL. J2EEUna posible definición abstracta de arquitectura empresarial sería: “El estudio de siste-mas empresariales complejos desde el punto de vista de su estructura”. Un arquitecto empresarial ha de ser capaz de estudiar un problema en concreto y de escoger una serie de componentes con los que modelar la arquitectura más adecuada para el problema en cuestión. Dichos componentes pueden ser servidores de aplicaciones, contenedores web, servidores de mensajería, etc. El arquitecto, asimismo, ha de ser capaz de establecer el modo de trabajo de dichos componentes, las herramientas utilizadas y las relaciones existentes entre los mismos.

La labor más complicada y con mayor responsabilidad para un arquitecto empresarial es con diferencia la elección de la plataforma empresarial sobre la que se cimentará la arqui-tectura de una empresa. Una elección errónea puede tener resultados catastróficos tanto para la empresa como para el responsable de dicha elección.

Una plataforma de desarrollo empresarial ha de ofrecer una serie de servicios a los arquitec-tos y desarrolladores encaminados a facilitar el desarrollo de aplicaciones empresariales, al tiempo que ofrece la mayor cantidad posible de funcionalidades a los usuarios. Normalmente una plataforma de desarrollo empresarial tiene los siguientes requisitos:

•• Escalabilidad : Ha de ofrecer una buena escalabilidad tanto horizontal como vertical de modo que si aumenta la carga del sistema podamos añadir servidores o ampliar los existentes sin que sea necesario realizar modificaciones.

•• Mantenibilidad : Ha de permitir añadir modificar los componentes existentes sin que se modifique el comportamiento del sistema.

•• Fiabilidad

•• Disponibilidad : Hemos de tener el soporte de arquitecturas tolerantes a fallos, sis-temas de redundancia, etc., que nos aseguren que nuestros sistema estará siempre disponible.

•• Extensibilidad : Ha de ser posible añadir nuevos componentes y capacidades al sistema sin que se vean afectados el resto de componentes.

•• Manejabilidad : Nuestros sistemas han de ser fácilmente manejables y configura-bles.

•• Seguridad : Hemos de tener buenos sistemas de seguridad tanto a nivel de autenti-cación, como de autorización y como de transporte.

•• Rendimiento : Se ha de ofrecer automáticamente soporte de clustering, balanceo de carga, pools de objetos, pools de conexiones, cachés, y en general mecanismos que permitan aumentar el rendimiento de manera transparente al usuario.

La importancia de una plataforma empresarial es que todos estos componentes se nos ofre-cen de manera automática de modo que los desarrolladores son mucho más productivos.


/ 7

u.d. 1 NIVEL II

La diferencia entre utilizar una plataforma de desarrollo empresarial y no utilizarla radica en que en el segundo caso nuestros desarrolladores perderán mucho tiempo realizando sistemas de bajo nivel, no pudiéndose centrar en el desarrollo de aplicaciones y por consi-guiente disminuyendo considerablemente la productividad de los mismos.

Por si fuera poco, las soluciones cerradas, a menudo pueden representar problemas para las empresas ya que éstas se verán ligadas a terceras entidades de las que dependerán para la evolución de sus estructuras de información. Es por ello que en la actualidad las plataformas más importantes son aquellas que disponen del apoyo de gran cantidad de empresas, entidades o asociaciones y que disponen de grupos de estandarización que ase-guren el futuro de las mismas. En la actualidad las plataformas de desarrollo empresarial más importantes son tres:

•• CORBA

•• .NET

•• J2EE

Nosotros no quedaremos con J2EE.

J2EE, la plataforma creada por SUN en el año 1997 es según nuestra opinión la que ofrece mejores perspectivas de desarrollo para empresas que quieran basar su arquitectura en productos basados en software libre. J2EE, nos ofrece entre otras las siguientes ventajas:

•• Soporte de múltiples sistemas operativos: Al ser una plataforma basada en el lenguaje Java, es posible desarrollar arquitecturas basadas en J2EE utilizando cualquier sistema operativo donde se pueda ejecutar una máquina virtual Java.

•• Organismo de control: La plataforma J2EE está contolada por el JCP, un organismo formado por más de 500 empresas. Entre las empresas que lo forman están todas las más importantes del mundo informático ( SUN, IBM, Oracle, SAP, HP, AOL, etc. ) lo que garantiza la evolución de la misma.

•• Competitividad: Muchas empresas crean soluciones basadas en J2EE y que ofrecen características como rendimiento, precio, etc., muy diferentes. De este modo el cliente tiene una gran cantidad de opciones a elegir.

•• Madurez: Creada en el año 1997 como respuesta a la tecnología MTS de Microsoft, J2EE tiene ya cinco años de vida y una gran cantidad de proyectos importantes a sus espaldas.

•• Soluciones libres: En la plataforma J2EE es posible crear arquitecturas completas basadas única y exclusivamente en productos de software libre. No sólo eso, sino que los arquitectos normalmente disponen de varias soluciones libres para cada una de las partes de su arquitectura.

Aún así, la plataforma de J2EE también tiene desventajas, algunas importantes:

•• Depende de un único lenguaje: La plataforma J2EE depende exclusivamente del len-guaje Java. Sólo se puede utilizar este lenguaje para desarrollar aplicaciones lo que puede suponer un gran problema si nuestro equipo no dispone de los conocimientos suficientes o tiene otras preferencias.

•• Complejidad: Aunque no es una plataforma tan compleja como CORBA, no existe un VB .NET en Java. La creación de aplicaciones bajo J2EE requiere normalmente desarrolladores más experimentados que los necesarios para desarrollar bajo .NET


/ 8

u.d. 1 NIVEL II

•• Heterogeneidad: Existe una gran heterogeneidad en las soluciones de desarrollo. No existe en J2EE un símil a Visual Studio .NET. La gran cantidad de herramientas dis-ponibles causa confusión dentro de los desarrolladores y puede crear dependencias dentro de las empresas.

Existe mucha confusión, sobre todo entre la gente alejada del mundo de Java, sobre lo que es en realidad J2EE. La confusión más habitual es pensar que J2EE es un producto concreto que distribuye SUN Microsystems, como hace con su JDK, y que te puedes descargar desde su página web. Nada más lejos de la realidad. No existe un J2EE concreto, no puedes ir a la página web de SUN Microsystems y descargarte “el J2EE”.

JSR

JSR es el acrónimo de Java Specification Request. Cuando una persona o entidad cree que es necesario la presencia de una determinada tecnología dentro de las plataformas basa-das en Java, lo que hace es crear un JSR y presentarlo para su aprobación. Dentro de este documento se relata por que es necesaria dicha tecnología, por que no se pueden abordar los problemas que soluciona con las tecnologías existentes, etc.

JCP

Java, siempre fue criticado por ser única y exclusivamente de SUN. A raíz de todas esas críticas, SUN, el 8 de diciembre de 1998, decidió dar la posibilidad a todo el mundo de par-ticipar en la evolución de Java y de todas las plataformas que se basan en Java. Con esa intención se creó el JCP, que como hemos dicho es un organismo formado por alrededor de 500 empresas, asociaciones y particulares cuyo objetivo es asegurar la evolución de las plataformas basadas en Java.

Después de ver los conceptos de JSR y JCP estamos preparados para definir lo que es J2EE. J2EE es una especificación, un JSR, que define una plataforma de desarrollo empresarial, a la que llamaremos la plataforma J2EE. La plataforma J2EE está formada varios compo-nentes:

•• Un conjunto de especificaciones.

•• Un test de compatibilidad, el J2EE Compatibility Test Suite ( CTS ).

•• La implementación de referencia de J2EE.

•• Un conjunto de guías de desarrollo y de prácticas aconsejadas denominadas J2EE BluePrints.

1.1.1 MODELO N-CAPAS

La plataforma de J2EE define un modelo de programación encaminado a la creación de aplicaciones basadas en n-capas. Típicamente una aplicación puede tener cinco capas diferentes:

•• Capa de cliente: Representa el interfaz de usuario que maneja el cliente.

•• Capa de presentación: Representa el conjunto de componentes que generan el la información que se representará en el interfaz de usuario del cliente. Típicamente se creará a través de componentes basados en Servlets y JSP.

•• Capa de lógica de negocio: Contiene nuestros componentes de negocio reutilizables. Normalmente se forma a partir de componentes EJB.

•• Capa de integración: Aquí se encuentran componentes que nos permiten hacer más transparente el acceso a la capa de sistemas de información. Por ejemplo este es el


/ 9

u.d. 1 NIVEL II

lugar idóneo para implementar una lógica de objetos de acceso a datos, DAO (Data Access Objects).

•• Capa de sistemas de información: Esta capa engloba a nuestros sistemas de infor-mación : bases de datos relacionales, bases de datos orientadas a objetos, sistemas legacy, etc.

Las ventajas de un modelo como este son muy importantes. Al tener las capas separadas tenemos que existe poco acoplamiento entre las mismas, de modo que es mucho más fácil hacer modificaciones en ellas sin que interfieran en las demás. Todo esto redunda en la obtención de mejoras en cuanto a mantenibilidad, extensibilidad y reutilización de compo-nentes. Otra de las ventajas que obtenemos es que se promueve la heterogeneidad de los clientes ya que añadir nuevos tipos de cliente (móviles, set-top-boxes, PCs, etc.) se reduce a añadir nuevas capas de interfaz de usuario y presentación, sin tener que modificar todo el resto de capas.

Imagen1-1-1

En la imagen de arriba se puede ver lo que sería una posible arquitectura J2EE. El modelo que aparece en la figura está dividido en varias capas, con una separación clara entre presentación, lógica de negocio y sistemas de información empresariales. En este caso además, podemos ver como se trata de un modelo mixto. En la parte de arriba tenemos que se recorre un camino por una estructura de tres capas (aplicación - lógica de negocio - sistemas de información ), mientras que por el segundo camino recorremos una estruc-tura de cuatro capas ( aplicación - lógica de presentación - lógica de negocio - sistemas de información ).

Este modelo es sólo un ejemplo, en muchos casos hasta puede que sea demasiado com-plejo y nos conformemos con utilizar únicamente la capa de Servlets/JSP para acceder a nuestros sistemas de información, en otros casos prescindiremos de la capa web, en otros casos utilizaremos servicios web para acceder a la lógica de negocio, o crearemos capas de persistencia intermedia con patrones de acceso a datos. Las combinaciones son prácti-camente ilimitadas.

Como ya hemos dicho, el modelo de desarrollo con J2EE está basado en componentes reutilizables, con el objetivo de aumentar la reusabilidad de las aplicaciones. Estos com-


/ 10

u.d. 1 NIVEL II

ponentes, además, gracias a las especificaciones, son intercambiables entre servidores de aplicaciones, por lo que la portabilidad de nuestros desarrollos es máxima. Si hay un tipo de componentes que requieren una atención especial estos son los Enterprise Java Beans. Se trata de objetos distribuidos, que como hemos dicho contienen la lógica de negocio de nuestras aplicaciones y que hacen transparente al programador operaciones como la per-sistencia, la seguridad, la gestión de transacciones, etc.

1.2 JAKARTA TOMCATApache Tomcat es sin lugar a dudas el proyecto de software libre más famoso escrito en Java. Creado a partir de código donado por SUN Microsystems a la Apache Software Foun-dation, ha crecido hasta convertirse en la implementación oficial de referencia de Servlets y JSP sustituyendo a la implementación de SUN original. Esto lo convierte, obviamente, en el contenedor sobre el que todos los demás prueban su adhesión a las especificaciones.

Aunque siempre se le ha acusado de un rendimiento pobre, el caso es que a partir de las nuevas versiones de la serie 4.x, creadas para cumplir las especificaciones 2.3 de Servlets y 1.2 de JSP, Tomcat se ha reescrito entero lo que mejora considerablemente su rendimiento. Quizás siga sin ser la opción más indicada para una aplicación con miles de clientes simultá-neos, pero ningún servidor en solitario es adecuado para una carga así. En todos los demás casos su rendimiento es más que aceptable.

Por supuesto puede integrarse sin demasiados problemas con el servidor web Apache, y para aplicaciones empresariales grandes con servidores de aplicaciones como JBoss o JOnAS. Asimismo puede integrarse con muchos otros productos con licencias propietarias. Es más, sin ir más lejos, Tomcat es el contenedor web que más se está utilizando en servidores de aplicaciones comerciales, donde gigantes como IBM con su todopoderoso WebSphere han elegido a Tomcat como contenedor web.

Otra de las muestras de lo estandarizado del uso de Tomcat es su utilización como servidor de Servlets y JSP por parte de los entornos de desarrollo, tanto libres como comerciales. Ejemplos de esto son Borland JBuilder o Eclipse que integran un servidor Tomcat para poder desarrollar nuestras páginas JSP y Servlets.

Diferencias en Tomcat 4.x y Tomcat 5.x

• Servlets 2.4 y JSP 2.0

La primer gran diferencia entre Catalina (Tomcat 4.x) y Tomcat 5.x, es que ésta última imple-menta el ambiente para la ejecución de Servlets versión 2.4 y JSP versión 2.0, mientras Tomcat 4.x lo hace para las versiones Servlets 2.3 y JSP 1.2 .

• Configuración server.xml y Administración JMX

La configuración de Tomcat 5.x se encuentra aun más modularizada que aquella empleada para Catalina (Tomcat 4.x), tal como el uso de recursos JNDI a nivel de “Servlet Engine”.

Además de los cambios presentes en el archivo de configuración server.xml, éste ahora incluye la opción de configurar MBeans vía JMX (“Java Management Extensions”) que permiten una administración a través de métodos programáticos.

• Filtros

El uso de filtros en solicitudes y requisiciones para aplicaciones Web se encuentra más avanzado en esta versión del “Servlet Engine”, aunque este mecanismo se encontraba definido desde la especificación 2.3 de Servlets que correspondería a Catalina (Tomcat 4.x ), no fue sino hasta esta versión (Tomcat 5.x) que esta funcionalidad fue implementada en su totalidad.


/ 11

u.d. 1 NIVEL II

• Clusters

Una adición largamente esperada en Tomcat ya presente en la versión 5.x es el apoyo para Clusters, lo cual permite configurar el “Servlet Engine” para sistemas de producción de alto tráfico con requerimientos de alta disponibilidad.

• Tomcat 5.0.x y Tomcat 5.5.x

Por ultimo, existen dos arboles sobre la versión 5.x de Tomcat. La versión 5.0 se encuentra diseñada para operar con el “JDK” versión 1.4, mientras la versión 5.5 esta diseñada para operar con las funcionalidades ofrecidas por la versión 1.5 (J2SE) del “JDK”.

1.3 INSTALACIÓN DE JAKARTA TOMCATInstalación de Tomcat

1. Bajar la versión binaria de Tomcat en: http://jakarta.apache.org/tomcat . (La versión de Código Fuente(src) solo es necesaria si quiere experimentar y/o instalar Apache con Tomcat)

2. Descomprimir el archivo Tar de Tomcat en /usr/local/, esto genera un directorio llamado jakarta-tomcat-<numero_de_version>, para dar mayor uniformidad se recomienda cambiar el nombre de este directorio a tomcat.

3. Posteriormente se debe definir una variable ambiental la cual le indicará al sistema la ubicación de Tomcat , esta variable se llama CATALINA_HOME la cual debe ser agregada a /etc/bashrc, si no esta familiarizado con ambientes *nix, esto significa agregar la linea:

export CATALINA_HOME=/usr/local/tomcat;;

para instalaciones Windows esta variable ambiental puede ser definida de la misma manera que CLASSPATH, descrita en las instrucciones del JDK.

Configuración Local

Solo para ilustrar esta instalación inicial modifique el archivo /etc/hosts agregando una línea como la siguiente:

127.0.0.1 www.servidorprueba.com

Generalmente el paso anterior se logra a través de DNS, pero por facilidad y demostración se opto por modificar /etc/hosts.

Ejecución y Pruebas

Una vez efectuados los pasos anteriores es posible realizar pruebas iniciales sobre Tomcat, para esto ejecute lo siguiente:

Desciende al directorio bin de Tomcat (/usr/local/tomcat/bin ) y ejecuta el archivo startup.sh :

[root@servidor1 bin]# ./catalina.sh runUsing CATALINA_BASE: /usr/local/tomcatUsing CATALINA_HOME: /usr/local/tomcatUsing CATALINA_TMPDIR: /usr/local/tomcat/tempUsing JAVA_HOME: /usr/local/jdk

Debes observar algo similar al desplegado anterior; los detalles de estos parámetros son tema de esta guía, sin embargo, cabe mencionar que la pantalla permanecerá inhabilitada, este congelamiento en pantalla se debe a que aquí será enviado todo error detectado por


/ 12

u.d. 1 NIVEL II

“Tomcat” (esto obviamente debe ser cambiado, pero por ahora es la configuración “default” de Tomcat, esto se describe en elemento Logger del fichero Server.xml).

2. Aunque pueda descongelarse la pantalla mediante Ctrl-C y seguir ejecutando comandos en pantalla, Tomcat no es cerrado/clausurado hasta que se ejecute shutdown.sh, inclusive si intenta ejecutar ./startup.sh consecutivamente, sin ejecutar shutdown.sh se genera un error.

3. Asegurándose que Tomcat este activo, de cualquier navegador (“Netscape”,”Galeon”,”Opera” u otro) del sistema intente visitar la dirección que fue definida en /etc/hosts, en este caso www.servidorprueba.com agregando el fragmento :8080 al final:

www.servidorprueba.com:8080

Al introducir la dirección anterior en un navegador, se le esta indicando que solicite la página principal de www.servidorprueba.com en el puerto TCP 8080 ; www.servidorprueba.com esta en la maquina local (127.0.0.1) como fue definido en /etc/hosts y el puerto 8080 es en el que precisamente esta Tomcat (en la secuencia de startup.sh se indica)

4. En su navegador debe aparecer la página principal de documentación de Tomcat y los diversos Links hacia los ejemplos de Tomcat .

Aunque ya este observando la documentación de Tomcat, seguramente esto no servirá de mucho a los visitantes de tu sitio y seguramente tampoco sabrán que deben agregar :8080 a sus solicitudes, para realizar estos cambios es necesario entrar en los detalles de configuración de Tomcat.

1.4 ESTRUCTURA DE DIRECTORIOS DE JAKARTA TOMCATAsumiendo que hemos des-comprimido la distribución binaria de Tomcat deberíamos tener la siguiente estructura de directorios:

Imagen 1-1-2

Adicionalmente podemos, o Tomcat creará, los siguientes directorios:

Imagen 1-1-3

/ 13

u.d. 1 NIVEL II

1.5 FICHEROS DE CONFIGURACIÓNLa configuración de Tomcat se basa en dos ficheros:

A. server.xml - El fichero de configuración golbal de Tomcat.

B. web.xml - Configura los distintos contextos en Tomcat.

1.5.1 FICHERO SERVER.XML

server.xml es el archivo principal de configuración para Tomcat, al igual que otros archivos de configuración para productos empleados en servidor puede contener una gran variedad de parámetros, sin embargo, esta guía se concentrará en los parámetros principales.

Validación,  y valores “Default”

El archivo server.xml es un archivo en XML,el cual de no contener una estructura conforme a XML, se indicará al arranque de Tomcat; dicho archivo se encuentra bajo el directorio /usr/local/tomcat/conf donde /usr/local/tomcat es el directorio definido en CATALINA_HOME.

Como cualquier otro documento en XML todo contenido entre  es considerado un comentario, y por lo tanto cualquier parámetro que se encuentre entre estos caracteres no es utilizado por “Tomcat”; aquellos parámetros que no sean definidos dentro de server.xml son asignados un valor “Default” por Tomcat.

<Server> - </Server>

<Server> es el elemento principal del archivo server.xml y todas las demás secciones deben encontrarse entre estos nodos; el atributo port indica el puerto TCP donde se espera la señal de cierre (shutdown) de Tomcat, el cual rara vez es modificado.

<Listener>

A través de los elementos <Listener> se configuran las extensiones JMX (“Java Manage-ment Extensions”) que serán utilizadas por Tomcat, dichos elementos toman dos atributos: className que indica la Clase diseñada para escuchar sobre eventos JMX y debug para especificar el nivel de “debug” generado al tiempo de ejecución.

<GlobalNamingResources> , <Resource> y <ResourceParams>

Anidado dentro de los elementos <GlobalNamingResources> es posible definir recursos JNDI para ser utilizados globalmente en Tomcat. Lo anterior evita que estos recursos tengan que ser declarados a nivel de WAR de manera individual.

A través de <Resource> es como define el tipo de recurso JNDI que será utilizado y mediante <ResourceParams> se especifican los parámetros específicos que tomará el recurso en dicha instancia de Tomcat.

<Service> - </Service>

Esta parámetro permite configurar Tomcat para diferentes modalidades de ejecución, en el archivo server.xml “Default” se definen dos modalidades a través del atributo name; la

definición asignada name=”Catalina” es empleada para ejecutar Tomcat indi-vidualmente, esto es representado con la linea roja de la siguiente gráfica:

imagen1-1-4


/ 14

u.d. 1 NIVEL II

<Connector>

El elemento Connector representa las conexiones (Puertos TCP) que serán abiertas por Tomcat al arranque, a su vez dentro de cada elemento Connector se definen diversos atri-butos los cuales dan más detalles acerca de la conexión.

El elemento Connector más importante es aquel que define la clase: HttpConnector.

<Connector port=”8080” maxThreads=”150” minSpareThreads=”25” maxSpareThreads=”75” enableLookups=”false” redirectPort=”8443” acceptCount=”100” debug=”0” connectionTimeout=”20000” disableUploadTimeout=”true” />

La declaración anterior indica que Tomcat esta dispuesto a dar respuesta a requisiciones que arriven en el puerto 8080 del “Host” donde esta instalado Tomcat.

Para ambientes de producción en los cuales toda requisición será atendida por Tomcat el parámetro port de este elemento debe ser modificado al valor de 80, este puerto es el ampliamente conocido puerto TCP 80 con el que intenta comunicarse cualquier Navegador(“Netscape”,”Explorer”,”Opera” u otro) en Internet.

Gráficamente esto es representado con la linea roja de la siguiente gráfica: imagen1-1-5

Esta linea roja indica que Tomcat actúa en efecto como “Servidor de Páginas”.

Otras declaraciones para Connectors son aquellas para utilizar encriptación (HTTPS) y los conectores AJP; la configuración de HTTPS es un tanto extensa y no se describirán los detalles, sin embargo, los conectores AJP son aquellos utilizados para la comunicación entre Apache y Tomcat y son los siguientes:

<Connector port=”8009” enableLookups=”false” redirectPort=”8443” debug=”0” protocol=”AJP/1.3” />

Esta declaración indica que el puerto 8009 estará recibiendo conexiones bajo ajp13, lo anterior es solo de interés si utiliza Apache en conjunción con Tomcat , lo cual equivale a la línea verde del diagrama anterior.

<Engine> - </Engine>

Los elementos <Engine> los cuales deben encontrarse anidados dentro de <Service> representan el mecanismo que atenderá toda solicitud llegada a Tomcat, esto es, toda soli-citud recibida por las definiciones Connectors será procesada por <Engine>, los atributos de este elemento son los siguientes:

<Engine name=”Catalina” defaultHost=”localhost” debug=”0”>

defaulthost representa el nombre del servidor Tomcat mientras debug indica el nivel de “debug” generado al tiempo de ejecución.

Logger

Los elementos Logger le indican a Tomcat hacia donde deben ser enviados los registros “Logs” :

<Logger className=”org.apache.catalina.logger.FileLogger” directory=”logs” prefix=”localhost_log.” suffix=”.txt” timestamp=”true”/>


/ 15

u.d. 1 NIVEL II

Lo anterior indica que los registros de Tomcat deben ser enviados al archivo localhost_log.txt; la ubicación de este registro (“log”) puede ser modificada al nivel de los elementos Host los cuales permiten definir Virtual Hosts.

Analice estos registros con Analog.

<Host> - </Host>

Los elementos Host permiten definir varios Hosts “Virtuales” para Tomcat, esto es, a través del elemento <Engine> se define un sitio(localhost) para atender solicitudes, a través de Host es posible definir diversos sitios “Virtuales”, su configuración es la siguiente:

<Host name=”desarrollo.servidorprueba.com” debug=”0” appBase=”webapps” unpackWARs=”true”>

Lo anterior indica que el sitio desarrollo.servidorprueba.com contiene sus aplicaciones (Archivos WARS) bajo el directorio $CATALINA_HOME/webapps, donde $CATALINA_HOME es /usr/local/tomcat; el atributo unpackWARs le indica a Tomcat que debe descomprimir los archivos WAR’s al arranque.

Como ya fue mencionado, dentro de estos elementos <Host> es posible utilizar <Logger> para generar registros (“logs”) por cada sitio virtual.

Context

Context es un elemento utilizado para indicar la ubicación de las aplicaciones ejecutadas en Tomcat , en su configuración “Default” estas aplicaciones se encuentran dentro del directorio webapps bajo el directorio raíz de Tomcat ( /usr/local/tomcat ). El entrar en los detalles de Context seria un tanto prematuro ya que aún no se ha descrito que es un aplicación en Tomcat .

Una aplicación en Tomcat o cualquier Servlet Engine(Web-Container) es un conjunto de “JSP’s (Java Server Pages)” y/o “Servlets” agrupados con ciertos parámetros de arranque y seguridad, este conjunto de archivos / aplicación en todo Servlet Engine es conocido como un WAR (Web-Archive).

1.5.2 FICHERO WEB.XML

Existe un fichero WEB.XML dentro del directorio CONF que define una serie de valores por defecto para todas las aplicaciones Web del servidor, pero cada aplicación WEB, en su directorio WEB-INF, puede tener su propio fichero WEB.XML, y así poder sobrescribir estos valores por defecto o añadir nuevos aspectos a la configuración de la aplicación Web correspondiente.

El fichero de configuración WEB.XML posee las siguientes funciones:

•• Ofrecer una descripción de la aplicación Web.

•• Realizar una correspondencia de nombre de servlets con URLs.

•• Establecer la configuración de la sesión.

•• Mapeo de librerías de etiquetas.

•• Informar de los tipos MIME soportados.

•• Establecer la página por defecto de la aplicación Web.

•• Definir los parámetros de inicialización de un servlet.

De momento vamos a comentar como definir los parámetros de inicialización de un servlet, pero antes de esto tenemos que ver como asignar un nombre a un servlet, ya que los pará-metros de inicialización se le asignan a un servlet a través de su nombre.


/ 16

u.d. 1 NIVEL II

Primero debemos asociar un nombre con el fichero de la clase del servlet, una vez hecho esto asociamos el nombre del servlet con el parámetro de inicialización. Todas las etiquetas XML que vamos a utilizar se encuentran englobadas por una etiqueta general llamada <web-app> y que contiene toda la configuración para la aplicación Web en la que se encuentra el fichero WEB.XML. La estructura inicial de este fichero es la que se muestra en el siguiente código.

<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE web-appPUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN”“http://java.sun.com/j2ee/dtds/web-app_2.2.dtd”><web-app></web-app>

Dentro de una etiqueta <servlet> indicaremos la correspondencia entre el nombre que se le va a dar al servlet y el fichero que contiene la clase del mismo y los parámetros de ini-cialización que se van a utilizar en el servlet, además de otros aspectos de configuración del servlet. Es precisamente dentro de esta etiqueta dónde podremos indicar si el servlet se debe instanciar cuando se inicie la ejecución del servidor Tomcat.

Mediante la etiqueta <servlet-name> indicamos el nombre que se le va a asignar al servlet. El valor que se indique en esta etiqueta puede ser utilizado en la URL que invoca al servlet, así por ejemplo si al servlet MuestraMensaje le asignamos el nombre mensaje, podremos invocarlo desde el navegador con la URL http://localhost:8080/ejemplos/servlet/mensaje. Como se puede comprobar debemos seguir utilizando el directorio servlet.

Para indicar el servlet al que vamos a asignar el nombre especificado en la etiqueta <ser-vlet-name>, utilizaremos la etiqueta <servlet-class>. En esta etiqueta se indica el nombre de la clase del servlet, así si tomamos el ejemplo anterior, deberíamos especificar la clase MuestraMensaje.

Tanto la etiqueta <servlet-name> como <servlet-class> son etiquetas obligatorias que forman parte de la etiqueta <servlet>.

De esta forma ya tendríamos un servlet determinado identificado mediante un nombre. En este momento el fichero WEB.XML tiene el aspecto del mostrado en el código siguiente.

<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE web-appPUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN”“http://java.sun.com/j2ee/dtds/web-app_2.2.dtd”><web-app><servlet><servlet-name>

mensaje

</servlet-name><servlet-class>

MuestraMensaje

</servlet-class></servlet></web-app>

Para asignar ahora los parámetros de inicialización al servlet hacemos uso de otras etiquetas llamadas <init-param>, <paran-name> y <param-value>. La etiqueta <init-param> indica que se va a definir un parámetro para el servlet actual, es decir, en servlet que se encuentra definido entre las etiquetas <servlet></servlet>.


/ 17

u.d. 1 NIVEL II

La etiqueta <init-param> posee varios subelementos que comentamos a continuación:

• <param-name>: etiqueta en la que indicamos el nombre del parámetro de inicialización del servlet. El nombre del parámetro es case-sensitive, es decir, se distingue entre minúsculas y mayúsculas, esta norma la podemos aplicar como general a todos los elementos identifi-cativos de los ficheros XML de configuración del servidor Tomcat y sus aplicaciones.

• <param-value>: etiqueta en la que se indica el valor del parámetro. Estos valores siempre se van a recuperar como objeto String, el servlet será encargado de convertir el valor del parámetro al tipo correspondiente.

• <description>: permite especificar una descripción del parámetro, esta etiqueta se utiliza a nivel de documentación.

De esta forma si queremos inicializar el servlet asignándole al parámetro repeticiones el valor de 4 y al parámetro mensaje el valor de la cadena “Hola, que tal”, el fichero de confi-guración de la aplicación Web, tendrá el aspecto del código siguiente.

<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE web-appPUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN”“http://java.sun.com/j2ee/dtds/web-app_2.2.dtd”><web-app><servlet><servlet-name>mensaje</servlet-name><servlet-class>MuestraMensaje</servlet-class><init-param><param-name>repeticiones</param-name><param-value>4</param-value><description>Número de veces que se repite el mensaje</description></init-param><init-param><param-name>mensaje</param-name><param-value>Hola, que tal</param-value><description>Texto del mensaje</description></init-param></servlet></web-app>

Dentro de la etiqueta <servlet> también podemos indicar que el servlet se cree, y ejecute el método init(), al iniciar la ejecución del servidor Tomcat. Para ello utilizaremos la etiqueta <load-on-startup>, si a este etiqueta no se le facilita ningún valor, el servidor instanciará y cargará el servlet cuando le sea posible al iniciarse. Pero si deseamos que se instancie el servlet atendiendo a una prioridad con respecto al resto de los servlets de la aplicación Web, especificaremos un entero como valor de la etiqueta. Cuanto mayor sea este número menor será la prioridad de creación del servlet, de esta forma primero se crearán los servlets con prioridad 1, luego los de prioridad 2, y así con el resto.

En siguiente aspecto que vamos a comentar del fichero WEB.XML es la forma en la que nos permite la correspondencia de los servlets con patrones de URLs.

La etiqueta <servlet-mapping> nos permite asignar a un servlet, identificado por su nombre asignado en la subetiqueta <servlet-name> de la etiqueta <servlet>, una URL determinada. La etiqueta <servletmapping> contiene dos subetiquetas <servlet-name> y <url-pattern>, que pasamos a comentar a continuación:

• <servlet-name>: en esta etiqueta indicamos el nombre del servlet al que queremos


/ 18

u.d. 1 NIVEL II

asociar con una URL determinada, o bien con un patrón de URL, como veremos más ade-lante.

• <url-pattern>: en esta etiqueta especificamos el patrón de la URL que queremos asignar al servlet. El contenido del cuerpo de esta etiqueta puede ser una cadena sencilla que indique una ruta más o menos compleja de la URL que se va a asociar con el servlet correspondiente, o bien una cadena con caracteres especiales que sirvan como un patrón.

1.6 ESTRUCTURA DE DIRECTORIOS DE UNA APLICACIÓN WEB

Al instalar Jakarta Tomcat, se crea un directorio llamado jakarta-tomcat como directorio raíz de la aplicación, dentro de este directorio encontramos diversos subdirectorios que son los que pasamos a comentar a continuación:

•• BIN: contiene los scripts de arranque y parada del servidor Web, es decir, los ficheros por lotes STARTUP.BAT y SHUTDOWN.BAT respectivamente.

•• CONF: contiene varios ficheros de configuración del servidor, los principales los SERVER.XML y WEB.XML. El primero de estos ficheros es el fichero de configura-ción principal del servidor, y el segundo de ellos establece los valores por defecto de las distintas aplicaciones Web del servidor. La estructura de estos dos directorios la comentaremos más adelante.

•• DOC: contiene la documentación de Jakarta Tomcat.

•• LIB: contiene varios ficheros JAR de Tomcat. Se ofrece un fichero JAR (Java Archive), llamado SERVLET.JAR que contiene los paquetes de la especificación Java servlet 2.2 y de la especificación Java Server Pages 1.1, y también los ficheros JASPER.JAR y WEBSERVER.JAR, que contienen las clases que forman parte del propio contenedor de servlets y páginas JSP.

•• LOGS: en este directorio se encuentran los ficheros de registro de Tomcat.

•• SRC: contiene los ficheros fuente de la especificación Java servlet y de la especifica-ción Java Server Pages.

•• WEBAPPS: contiene las aplicaciones Web de ejemplo que se distribuyen con Tomcat.

•• WORK: es le directorio de trabajo de Tomcat, es dónde tiene lugar la traducción de las páginas JSP a los servlets correspondientes. Existirá un subdirectorio del directorio WORK por cada aplicación Web, así si nuestra aplicación Web se llama ejemplos, su directorio de trabajo será c:\jakarta-tomcat\work\localhost_8080%2Fejemplos. El directorio de trabajo de la aplicación encontraremos un fichero .JAVA y otro fichero .CLASS que contienen en su nombre la cadena pagina JSP, es decir, el nombre de la página JSP a la que corresponden y a partir de la que se han generado. En este caso han generado los ficheros _0002fpaginaJSP_0002ejsppaginaJSP_jsp_0.java y _0002fpaginaJSP_0002ejsppaginaJSP.class. Si abrimos el fichero fuente del servlet, podemos ver el código Java que ha generado el contenedor de página JSP para crear el servlet equivalente a la página.

1.7 JNDI

JNDI (“Java Naming Directory Interface”) es una especificación que permite localizar infor-mación en distintos directorios distribuidos (como NDS de Novell), directorios LDAP(como OpenLDAP) o servicios CORBA “(COS)Corba Object Service”. Debido a la importancia que


/ 19

u.d. 1 NIVEL II

tienen los servicios antes mencionados en sistemas empresariales, JNDI es una herramienta que cobrará gran importancia en este tipo de desarrollos

Razones de JNDI

El diseño de un cliente LDAP es utilizado para autorizar usuarios en un sistema de computo. La principal deficiencia de este cliente LDAP es la inhabilidad de realizar búsquedas o autori-zación en otros sistemas que puedan contener información de usuarios o contraseñas.(Como NDS de Novell o ADS).

En la mayoría de las empresas este suele ser el caso: la existencia de diversos depósitos de información sin ninguna uniformidad para acceder, obviamente el escribir diversos clientes para realizar búsquedas en los distintos sistemas empresariales no seria imposible pero si una labor ardua. Debido a esto surgió JNDI.

En JNDI es posible utilizar un API estandarizado para escribir el programa antes mencio-nado, la ventaja es que casi todos los productos tanto “Directorios Distribuidos” como “LDAP Servers” se apegan a este estándar, de esta forma su programa podrá ser utilizado para acceder a cualquier “Directorio Distribuido” o “LDAP Server”, aquí vale el lema Java: “Write once run everywhere”!.

JNDI y SPI

Mediante JNDI se definen varios estándares para realizar búsquedas en diversos sistemas de información como LDAP Servers, NDS, COS. Observa el diagrama:

imagen1-1-6

Los diversos vendedores de directorios distribuidos y “LDAP Servers” deben definir un SPI (“Service Provider Interface”) para su producto, este SPI ofrecerá las funcionalidades del producto vía un ambiente en Java, esto es conocido como ganchos (“Hooks”) del producto. (Varios vendedores ya han definido sus SPI SPI’s de Java)

•• Mediante el API de JNDI (el cual se encuentra en los diversos JDK’s) es posible escribir cualquier tipo de programa para acceder a la información en directorios distribuidos o “LDAP Servers”, con la garantía de utilizar solo ciertas funciones para acceder a diversos directorios distribuidos o “LDAP Servers”.

•• Naming Manager: Ofrece otro grado de flexibilidad sobre la utilización de JNDI, men-cionado a continuación

Naming Manager

Al escribir el programa en “Java” y que éste busque información de cualquier tipo en un directorio distribuido o “LDAP” debe indicarse dentro del programa la ubicación del direc-torio “LDAP Server”, esto es, el “LDAP Server” o “NDS Novell se encuentra en el nodo IP xxx.xx.xx.x, isp.com ?. Es mediante el “Naming Manager” que se logra localizar la ubicación física del sistema en cuestión.

Lo anterior es de suma importancia al desarrollar aplicaciones que utilicen RMI/CORBA ya que les permite cambiar de “servidor físico” sin la necesidad de modificar el código fuente de la aplicación

final de lección

/ 20

!!

FINAL DE LA LECCIÓN 1Notas de trabajo del alumno:

Conclusiones:

Temas clave a recordar:

• Normalmente una plataforma de desarrollo empresarial tiene los siguientes requisitos:

o Escalabilidad

o Mantenibilidad

o Fiabilidad

o Disponibilidad

o Extensibilidad

o Manejabilidad

o Seguridad

o Rendimiento

• La plataforma de J2EE define un modelo de programación encaminado a la creación de aplicaciones basadas en n-capas.

• Apache Tomcat es sin lugar a dudas el pro-yecto de software libre más famoso escrito en Java. Creado a partir de código donado por SUN Microsystems a la Apache Software Foundation, ha crecido hasta convertirse en la implementación oficial de referencia de Ser-vlets y JSP sustituyendo a la implementación de SUN original.

lección 2: Introducción a JSP (JAVASERVER PAGES)

/ 21

u.d. 1 NIVEL II

LECCION 2: INTRODUCCIÓN A JSP (JAVASERVER PAGES)INTRODUCCIÓNJava Server Pages (JSP) es la tecnología para generar páginas web de forma dinámica en el servidor, desarrollado por Sun Microsystems basado en scripts que utilizan una variante del lenguaje java.

La tecnología JSP, o de Java Server Pages, es una tecnología Java que permite a los pro-gramadores generar dinámicamente HTML, XML o algún otro tipo de página web. Esta tecnología permite al código Java y a algunas acciones predefinidas ser empotradas en el contenido estático. En las jsp, se escribe el texto que va a ser devuelto en la salida (normal-mente código HTML) empotrando código java dentro de él para poder modificar o generar contenido dinámicamente. El código java se incluye dentro de las marcas de etiqueta <% y %>.

En una posterior especificación, se incluyeron taglib; esto es, la posibilidad de definir eti-quetas nuevas que ejecuten código de clases java. La asociación de las etiquetas con las clases java se declaran en archivos de configuración en XML.

La principal ventaja de JSP frente a otros lenguajes es que permite integrarse con clases Java (.class) lo que permite separar en niveles las aplicaciones web, almacenando en clases java las partes que consumen más recursos así como las que requieren más seguridad, y dejando la parte encargada de formatear el documento html en el archivo jsp.

Además Java se caracteriza por ser un lenguaje que puede ejecutarse en cualquier sistema, lo que sumado a jsp le da mucha versatilidad.

Sin embargo JSP no se puede considerar un script al 100% ya que antes de ejecutarse el servidor web compila el script y genera un servlet, por lo tanto se puede decir que aunque este proceso sea transparente para el programador no deja de ser una aplicación compilada. La ventaja de esto es algo más de rapidez y disponer del API de Java en su totalidad.

La arquitectura que Sun propone para el desarrollo de servicios como el que nos ocupa es la siguiente:

imagen1-2-1

El cliente es el navegador que se comunica con la parte servidora mediante el protocolo http. La parte servidora puede dividirse en dos grandes bloques:

•• El que constituye el interés del servicio, que es la base de datos

•• La lógica de control.

La lógica de control puede a su vez dividirse en dos categorías, en función de su proximidad o lejanía al cliente o al servidor:

o La parte más cercana a la información y, más alejada del cliente implementa todo el detalle de las operaciones que se ejecutan sobre la base de datos.


/ 22

u.d. 1 NIVEL II

o La parte más cercana al cliente y más alejada del servidor es responsable del Look & Feel de la aplicación.

En la siguiente imagen se puede ver la arquitectura de una aplicación Web

imagen1-2-2

Vemos que es posible que varios servidores web y browsers se comuniquen con cada tecnología. La especificación J2EE, permite que las aplicaciones se distribuyan en distintos entornos con ninguna o muy pocas modificaciones.

Normalmente los servidores de aplicaciones J2EE son BEA WebLogic e IBM WebSphere.

J2EE define como usar muchos de los servicios con los que una aplicación trata.

Estos servicios incluyen mantenimiento de transacciones (JTA), servicios (JNDI), mensajería (JMS, JavaMail), manejo de objetos distribuidos (RMI—IIOP) y mantenimiento de base de datos (JDBC).

Además de estos servicios, una aplicación compilada en J2EE tiene un contenedor Web y un contenedor de JavaBean (EJB).

En la siguiente imagen se puede ver la arquitectura de J2EE.

imagen1-2-3

1.1 DEFINICIÓN DE PÁGINA JSPJava Server Pages (JSP) combinan HTML con fragmentos de Java para producir páginas web dinámicas.

Cada página es automáticamente compilada a servlet por el motor de JSP, en primer lugar es recogida y a continuación ejecutada.

JSP tiene gran variedad de formas para comunicarse con las clases de Java, servlets, applets y el servidor web; por esto se puede aplicar una funcionalidad a nuestra web a base de componentes.


/ 23

u.d. 1 NIVEL II

Una página JSP es archivo de texto simple que consiste en contenido HTML o XML con elementos JSP. Cuando un cliente pide una página JSP del sitio web y no se ha ejecutado antes, la página es inicialmente pasada al motor de JSP, el cual compila la página convir-tiéndola en Servlet, la ejecuta y devuelve el contenido de los resultados al cliente.

Es posible ver el código del servlet generado, este código debe estar en el directorio que se informa en la estructura de directorios del servidor.

Si nos fijamos en este archivo podemos encontrar las siguientes clases:

•• JSPPage

•• HttpJspPage

Ellas definen la interface para el compilador de páginas JSP.

Nos encontramos también tres métodos:

•• JspInit()

•• JspDestroy()

•• _jspService(HttpServletRequest request, HttpServletResponse response)

Los dos primeros métodos pueden ser definidos por el autor de la página JSP, pero el tercer método es una versión compilada de la página JSP, y su creación es responsabilidad del motor de JSP.

Normalmente daremos a nuestro fichero una extensión .jsp, y normalmente lo instalaremos en el mismo sitio que una página Web normal. Aunque lo que escribamos frecuentemente se parezca a un fichero HTML normal en vez de un Servlet, detrás de la escena, la página JSP se convierte en un servlet normal, donde el HTML estático simplemente se imprime en el stream de salida estándar asociado con el método service del servlet. Esto normalmente sólo se hace la primera vez que se solicita la página, y los desarrolladores pueden solicitar la página ellos mismos cuando la instalan si quieren estar seguros de que el primer usuario real no tenga un retardo momentáneo cuando la página JSP sea traducida a un servlet y el servlet sea compilado y cargado.

Observa también, que muchos servidores Web nos permiten definir alias para que una URL que parece apuntar a un fichero HTML realmente apunte a un Servlet o a una página JSP.

Además de el HTML normal, hay tres tipos de construcciones JSP que embeberemos en una página:

elementos de script, directivas y acciones.

Los elementos de script nos permiten especificar código Java que se convertirá en parte del servlet resultante, las directivas nos permiten controlar la estructura general del servlet, y las acciones nos permiten especificar componentes que deberían ser usados, y de otro modo controlar el comportamiento del motor JSP.

1.2 ELEMENTOS DE LAS PÁGINAS JSPEl código fuente de una página JSP incluye:

1. Directivas: Dan información global de la página, por ejemplo, importación de estamentos, página que maneja los errores o cuando la página forma parte de una sesión, en el ejemplo anterior informamos del tipo de script de Java.


/ 24

u.d. 1 NIVEL II

2. Declaraciones: Sirven para declarar métodos y variables.

3. Scripts de JSP: Es el código Java embebido en la página.

4. Expresiones de JSP: Formatea las expresiones como cadenas para incluirlas en la página de salida.

Estos elementos siguen una sintaxis como XML, así se obtiene un significado con una presentación totalmente separada de la lógica. Un buen ejemplo es <jsp:useBean .../> el cual busca o crea una instancia de un bean. Con el mecanismo de extensiones de tag se tiene la posibilidad de definir tags con acciones similares y poner la funcionalidad en una librería de tags.

1.3 EJECUCIÓN DE LAS PÁGINAS JSPSi el usuario pide una página con extensión .html el servi-dor se la envía.

Si el usuario pide una página con extensión .jsp el servidor ejecuta el JSP y añade el resultado al HTML original de la página.

Para ejecutar una página JSP, el servidor realiza interna-mente varias operaciones:

Convierte la página JSP en código Java.

Compila el código Java.

Ejecuta el código Java.

imagen1-2-4

En la siguiente imagen se muestra un esquema de la estructura interna del servidor Jakarta Tomcat, relacio-nándolo con los distintos contenedo-res y las página JSP y los servlets.

imagen1-2-5


/ 25

u.d. 1 NIVEL II

1.4 JSP 2.0 Y EL (EXPRESION LANGUAJE)La especificación 2.0 de JSP ha introducido una nueva librería estándar de etiquetas, deno-minada JSTL.

Estas etiquetas tratan de abstraer la complejidad de introducir código Java (scriptlet) dentro de JSP, del mismo modo que trata de evitar que cada equipo de desarrollo cree un juego de etiquetas no estándar para las mismas labores.

Dentro de estas etiquetas, se utiliza un lenguaje llamado EL, lenguaje de expresiones, que pretende ser un lenguaje más sencillo que Java, para realizar operaciones.

Uno de los primeros contenedores de JSP que soporta estas capacidades es Tomcat5.

1.5 JSTLJSTL significa Java Standard Template Library (biblioteca de etiquetas estándar para Java).

•• Es un subconjunto de las etiquetas disponibles en JSP 2.0.

•• No contiene código Java.

•• Es sencillo.

Lo único que se requiere para JSTL son conocimientos básicos acerca del desarrollo de aplicaciones Web en Java, y un servidor capaz de ejecutar JSP 2.0 e instalar una implemen-tación de JSTL: jstl-1.0.2.jar, y Standard-1.0.4.jar

JSTL es una biblioteca que implementa funciones de uso frecuente en aplicaciones JSP. En concreto, JSTL proporciona:

•• Cinco bibliotecas de etiquetas JSP:

o Funciones comunes de iteración sobre datos, operaciones condicionales, e importación de otras páginas.

o Internacionalización y formateo de texto.

o Funciones de manipulación de cadenas.

o Procesamiento de XML.

o Acceso a bases de datos.

•• Un lenguaje de expresión para referenciar objetos y sus propiedades sin necesidad de código Java.

•• Validadores de bibliotecas de etiquetas (Tag Library Validators, TLVs).

•• JSTL requiere un contenedor de JSP 2.0.

Por su simplicidad, JSTL solo requiere conocimientos rudimentarios de Java, JSP, y aplica-ciones Web. Cualquier desarrollador puede comenzar a usarlo de forma casi inmediata.

JSTL facilita la referencia a objetos:

<%-- con JSP --%><%= session.getAttribute(“username”).getFirstName()%>

<%-- con JSTL --%>${sessionScope.username.firstName}


/ 26

u.d. 1 NIVEL II

1.5.1 HISTORIA DE JSTL

Con JSTL se pretendía recopilar las etiquetas JSP más usadas en una biblioteca estándar que pudiera usarse en todos los contenedores JSP

La especificación JSTL se desarrollo bajo el auspicio del JCP (Java Community Process, Proceso Comunitario Java). El JCP es un proceso supervisado por SUN pero abierto a empresas, e individuos particulares, que guía el desarrollo y aprobación de los estándares para el lenguaje Java.

Las iniciativas para crear un estándar dentro del proceso JCP se conocen como JSR (Java Specification Request, Petición de Especificación Java). La JSR nº 52 se llamó “A Standard Tag Library for Java Server Pages”, o abreviadamente JSTL. Fue solicitada originalmente por Eduardo Pelegri-Llopart y Anil Vijendran, empleados de SUN. En su desarrollo parti-ciparon individuos como Jason Hunter, y representantes de varias organizaciones (ASF, Adobe, BEA, y otras).

La especificación JSTL 1.0 fue terminada el 11 de julio de 2002. Unos días después apare-ció la primera implementación creada por miembros del proyecto Taglibs de la fundación Apache

1.5.2 INSTALAR JSTL

Para trabajar con JSTL necesitamos:

o Un kit de desarrollo java como el Java Standard Edition (J2SE) de Sun.

o Un servidor que ejecute Servlets y JSP como Tomcat. JSTL 1.0 necesita JSP 1.2 y Servlets 2.3 implementadas por Tomcat 4. JSTL 1.1 requiere JSP 2.0 y Servlets 2.4, implementadas por Tomcat 5. O dicho de otro modo, si vas a trabajar con la última versión de JSTL (la 1.1) usa Tomcat 5.

o Una implementación de JSTL como la proporcionada por el proyecto Taglibs de Apache. La distribución (jakarta-taglibs-standard-1.1.0.zip) contiene documentación, ejemplos, la implementación en sí, y varios jars de dependencias. Si quieres ahorrar tiempo baja solo los jars siguientes jstl-1.0.2.jar, y Standard-1.0.4.jar

Si vas a trabajar con expresiones XPath necesitaras jaxen-full.jar, y saxpath.jar, de la distri-bución de Jaxen, el motor XPath escogido por Sun para JSTL. Jaxen es un interfaz XPath para evaluar expresiones en DOM, JDOM, dom4j, o EXML. Esta presente en el Web Services Developer Pack de Sun.

El fichero jar jstl-1.0.2.jar contiene clases javax.servlet.jsp.jstl.* con la API de JSTL. El fichero standard-1.0.4.jar contiene los paquetes con la implementación de JSTL.

1.5.3 CREAR UNA APLICACIÓN DE EJEMPLO

En Tomcat, cada aplicación Web se añade en un subdirectorio de CATALINA_HOME/webapps. Además el estándar requiere que tenga cierta estructura de directorios. Sin entrar en detalles, necesitaremos una estructura como esta:

$CATALINA_HOME/webapps/miAplicacion��WEB-INF ��classes ��lib commons-logging-1.0.3.jar jstl-1.0.2.jar standard-1.0.4.jar


/ 27

u.d. 1 NIVEL II

Observa que web.xml no es obligatorio según la especificación Servlet, y tampoco necesita-mos crearlo para declarar los descriptores de etiquetas, porque desde JSP 1.2 es posible (y aconsejable) empaquetarlos con la propia implementación binaria. En JSTL los descriptores están en el fichero standard-1.0.1.jar.

En cualquier caso, no esta de más añadir un web.xml. Se coloca bajo el directorio WEB-INF:

<?xml version=”1.0” encoding=”ISO-8859-1”?><web-app xmlns=”http://java.sun.com/xml/ns/j2ee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd” version=”2.4”>

<description>JSTL test</description> <display-name>JSTL test</display-name></web-app>

Si reiniciamos Tomcat, la aplicación será accesible en http://localhost:8080/miAplicacion, pero no veremos nada a menos que añadamos alguna página JSP.

1.5.4 CREAR UNA PÁGINA JSP CON JSTL

Siguiendo con la aplicación Web de la sección anterior, vamos a crear una página JSTL.

En toda página JSP hay que declarar la biblioteca a la que pertenece cada etiqueta que usemos. Puesto que son varias líneas, lo más cómodo es hacer las declaraciones en un fichero aparte, y luego incluir dicho fichero en nuestras páginas JSP. Este sistema evita repetir el mismo texto en todas las páginas, y si en el futuro añadimos más bibliotecas, solo tendremos que modificar un único fichero.

Añade una página $CATALINA_HOME/webapps/miAplicacion/taglibs.jsp con las siguientes declaraciones:

<%@ taglib prefix=”c” uri=”http://java.sun.com/jstl/core” %><%@ taglib prefix=”fmt” uri=”http://java.sun.com/jstl/fmt” %><%@ taglib prefix=”x” uri=”http://java.sun.com/jstl/xml” %><%@ taglib prefix=”sql” uri=”http://java.sun.com/jstl/sql” %><%@ taglib prefix=”fn” uri=”http://java.sun.com/jsp/jstl/functions” %>

Añade una página $CATALINA_HOME/webapps/miAplicacion/index.jsp que importe la anterior usando una directiva include:

<%@include file=”taglibs.jsp” %> <html> <body> <c:out value=”Hola mundo”/> </body> </html>

En este ejemplo hemos usado la etiqueta c:out de la librería core para mostrar un men-saje.

final de lección

/ 28

!!


Conclusiones:


• Java Server Pages (JSP) es la tecnología para generar páginas web de forma dinámica en el servidor.

• La principal ventaja de JSP frente a otros len-guajes es que permite integrarse con clases Java (.class) lo que permite separar en niveles las aplicaciones web, almacenando en clases java las partes que consumen más recursos así como las que requieren más seguridad, y dejando la parte encargada de formatear el documento html en el archivo jsp.

• Java Server Pages (JSP) combinan HTML con fragmentos de Java para producir páginas web dinámicas.

• Cada página es automáticamente compilada a servlet por el motor de JSP, en primer lugar es recogida y a continuación ejecutada.

• La especificación 2.0 de JSP ha introducido una nueva librería estándar de etiquetas, denominada JSTL.

• Estas etiquetas tratan de abstraer la com-plejidad de introducir código Java (scriptlet) dentro de JSP. JSTL significa Java Standard Template Library (biblioteca de etiquetas estándar para Java).

lección 3: Directivas y elementos scripting

/ 29

u.d. 1 NIVEL II

LECCION 3: DIRECTIVAS Y ELEMENTOS SCRIPTINGINTRODUCCIÓN 1.1 DIRECTIVAS Las directivas son un conjunto de etiquetas JSP que ofrecen al contenedor de páginas JSP instrucciones específicas de cómo se debe procesar una página determinada. Las directivas definen propiedades generales que afectan a la página, incluso algunas de estas directivas se pueden utilizar para generar de forma indirecta contenido dinámico que será devuelto como parte de la respuesta enviada al cliente, y por lo tanto tienen una traducción correspondiente dentro del servlet equivalente a la página JSP. Las directivas sirven como mensajes que se envían desde la página JSP al contendor JSP que la ejecuta.

Un ejemplo de uso de las directivas puede ser para indicar el tipo de lenguaje (lenguaje de script) que se va a utilizar dentro de la página JSP, para incluir contenidos de otra página o recurso del servidor, para indicar que la página usa una librería de etiquetas personalizada determinada, para importar paquetes del lenguaje Java, etc.

Las directivas no generan directamente una salida que se envíe al cliente de forma directa, sino que generan efectos laterales en la forma en la que el contenedor JSP procesa la página en la que se encuentra definida la directiva.

Las directivas se pueden situar en cualquier lugar de la página, pero para una mayor legibi-lidad del código de la página se recomienda que se sitúen al principio de la misma.

Antes de comenzar a comentar la sintaxis de las directivas que nos ofrece la especificación JSP, es necesario comentar una serie de reglas generales que podemos aplicar a todas las etiquetas JSP. Esta reglas son las siguientes:

•• Las etiquetas tienen una etiqueta de inicio con atributos opcionales, un cuerpo opcio-nal, y una etiqueta de cierre, como se puede ver en la siguiente sintaxis:

<etiquetaJSP nombreAtributo=”valor atributo”>cuerpo</etiquetaJSP>

También puede aparecer estas etiquetas sólo con una etiqueta de inicio sin cuerpo y con atributos opcionales, como se puede ver en el siguiente esquema:

<etiquetaJSP nombreAtributo=”valor atributo”/>

•• Los valores de los atributos de las etiquetas siempre aparecen entre comillas dobles o sencillas. Las cadenas especiales ' y " se pueden utilizar (como se hace en HTML) si las comillas son parte del valor del atributo.

•• Un espacio en al cuerpo del contenido (texto) de un documento no es significante, pero es preservado, es decir, cualquier espacio en blanco en la página JSP se traduce y mantiene durante el proceso de generación del servlet correspondiente.

•• El carácter \ se puede utilizar como carácter de escape en una etiqueta, por ejemplo para utilizar el carácter % (que veremos más adelante es una carácter especial que forma parte de la propia etiqueta de las directivas y de varios elementos de scripting) debemos usar la notación \%.


/ 30

u.d. 1 NIVEL II

•• Las URLs utilizadas en las páginas JSP siguen las mismas convenciones que en los servlets. Si se inicia una URL con / se supone que es una referencia al contexto actual, es decir, a la aplicación Web actual. Si la URL no comienza con / se supone que es relativa a la página JSP actual.

Realizadas estas aclaraciones generales volvemos a retomar el tema principal de este apartado.

Las directivas de JSP tiene la siguiente sintaxis general.

<%@ nombreDirectiva atributo1=”valor”... atributon=”valorn”>

Pero también es posible utilizar una sintaxis equivalente utilizando la siguiente notación basada en XML:

<jsp:directive.nombreDirectiva atributo1=”valor1”...atributon=”valorn”/>

La especificación Java Server Pages define tres directivas distintas que son page, include y taglib, a continuación en los siguientes apartados vamos a comentar cada una de estas directivas.

1.2 DIRECTIVA PAGELa directiva Page se usa para definir atributos que se aplican a una página JSP entera.

La directiva page se aplica a una página JSP completa, y a cualquier fichero estático que incluya con la directivas include” o <jsp:include>, que juntas son llamadas una unidad de traducción.

Observa que la directiva page no se aplica a cualquier fichero dinámico incluido. Una directiva page puede usarse para establecer valores para distintos atributos que se pueden aplicar a la página JSP. Podemos usar la directiva page más de una vez en una página JSP (unidad de traducción). Sin embargo, (excepto para el atributo import), sólo podemos especificar un valor para atributo una sola vez.

El atributo import es similar a la directiva import en un programa Java, y por eso podemos usarla más de una vez.

Podemos situar el directiva page en cualquier lugar de la unidad de traducción y se aplicará a toda la unidad de traducción. Por claridad y facilidad de entendimiento, el mejor lugar podría ser al principio del fichero JSP principal.

Aquí podemos ver la sintaxis de la directiva page. Los valores por defecto se muestran en negrita. Los corchetes ([...]) indican un término opcional. La barra vertical (|) proporciona una elección entre dos valores como true y false.

<%@ page[ language=”java”][ extends=”package.class”][ import= “{ package.class|package.*}, ...” ][ session=”true|false”][ buffer=”none|8kb|sizekb”][ autoFlush=”true|false”][ isThreadSafe=”true|false”][ info=”text”][ errorPage=”URLrelativa”][ contentType=”mimeType[ ;charset=characterSet]” |“text/html; charset=ISO-8859-1”][ isErrorPage=”true|false”]%>


/ 31

u.d. 1 NIVEL II

Ejemplos de Directivas Page

<%@ page import=”java.util.Date” %><%@ page import=”java.awt.*” %><%@ page info=”Información sobre la página” %>

1.2.1 ATRIBUTO INFO

Este atributo nos permite especificar una cadena de texto que es incorporada en el página JSP compilada. Podemos recuperar el string más tarde con el método getServletInfo().

En siguiente código se muestra un ejemplo de utilización del atributo info de la directiva page.

<%@ page info=”Ejemplo de directivas, Autor: MCP”%><!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”><html><head><title>Directivas</title></head><body>Ejemplo de atributo info</body></html>

JSP en servlet (recordamos al lector que este fichero lo puede encontrar en el directorio c:\jakartayomcat\ work\localhost_8080%2FnombreAplicacion), podemos comprobar que el valor del atributo info se devuelve mediante el método getServletInfo(). En el código siguiente se muestra de forma completa el servlet que se ha generado, y la parte que apa-rece destacada es la que se corresponde con la traducción de la directiva page de la página JSP del ejemplo.

import javax.servlet.*;import javax.servlet.http.*;import javax.servlet.jsp.*;import javax.servlet.jsp.tagext.*;import java.io.PrintWriter;import java.io.IOException;import java.io.FileInputStream;import java.io.ObjectInputStream;import java.util.Vector;import org.apache.jasper.runtime.*;import java.beans.*;import org.apache.jasper.JasperException;public class _0002fdirectivas_0002ejspdirectivas_jsp_8 extends HttpJspBase {// begin [file=”C:\\directivas.jsp”;from=(0,0);to=(0,61)]public String getServletInfo() {return “Ejemplo de directivas, Autor:MCP”;}// endstatic {}public _0002fdirectivas_0002ejspdirectivas_jsp_8( ) {}private static boolean _jspx_inited = false;public final void _jspx_init() throws JasperException {}public void _jspService(HttpServletRequest request, HttpServletResponseresponse) throws IOException, ServletException {JspFactory _jspxFactory = null;PageContext pageContext = null;HttpSession session = null;ServletContext application = null;


/ 32

u.d. 1 NIVEL II

ServletConfig config = null;JspWriter out = null;Object page = this;String _value = null;try {if (_jspx_inited == false) {_jspx_init();_jspx_inited = true;}_jspxFactory = JspFactory.getDefaultFactory();response.setContentType(“text/html;charset=8859_1”);pageContext = _jspxFactory.getPageContext(this, request, response,“”, true, 8192, true);application = pageContext.getServletContext();config = pageContext.getServletConfig();session = pageContext.getSession();out = pageContext.getOut();// HTML // begin [file=”C:\\directivas.jsp”;from=(0,61);to=(10,0)]out.write(“\r\n<!DOCTYPE HTML PUBLIC \”-//W3C//DTD HTML 4.0Transitional//EN\”>\r\n<html>\r\n<head>\r\n\t<title>Directivas</title>\r\n</head>\r\n<body>\r\nEjemplo de atributo info\r\n</body>\r\n</html>\r\n”);// end} catch (Exception ex) {if (out.getBufferSize() != 0)out.clearBuffer();pageContext.handlePageException(ex);} finally {out.flush();_jspxFactory.releasePageContext(pageContext);}}}

1.2.2 ATRIBUTO LANGUAGE

Este atributo define el lenguaje de script usado en los scriptles, declaraciones y expresiones en el fichero JSP y en cualquier fichero incluido.

language=”java”

1.2.3 ATRIBUTO CONTENTTYPE

Este atributo especifica el tipo MIME y la codificación de caracteres que use el fichero JSP cuando se envía la respuesta al cliente. Podemos usar cualquier tipo MIME o conjunto de caracteres que sean válidos para el motor JSP.

El tipo MIME por defecto es text/html, y el conjunto de caracteres por defecto es ISO-8859-1.

contentType=”mimeType [ ; charset=characterSet ]” | “text/html;charset=ISO-8859-1”

A continuación se muestra un ejemplo:

<%@ page info=”Ejemplo de directivas, Autor: Angel Esteban” language=”java”contentType=”text/html;charset=ISO-8859-1”%><html><head><title>Directivas</title></head><body>

Ejemplos de atributos de la directiva page

</body></html>


/ 33

u.d. 1 NIVEL II

Si acudimos al servlet equivalente a la página JSP anterior encontraremos una sentencia que realiza la función especificada en el atributo contentType. Esta sentencia se muestra resaltada en el siguiente fragmento de código del servlet.

_jspxFactory = JspFactory.getDefaultFactory();response.setContentType(“text/html;charset=ISO-8859-1”);pageContext = _jspxFactory.getPageContext(this, request, response,“”, true, 8192, true);application = pageContext.getServletContext();config = pageContext.getServletConfig();session = pageContext.getSession();out = pageContext.getOut();// HTML // begin [file=”C:\\directivas.jsp”;from=(1,44);to=(10,0)]out.write(“\r\n<html>\r\n<head>\r\n\t<title>Directivas</title>\r\n</head>\r\n<body>\r\nEjemplos de atributos de la directiva page\r\n</body>\r\n</html>\r\n”);// end

1.2.4 ATRIBUTO EXTEND

Este atributo especifica un nombre totalmente cualificado de una superclase que será extendida por la clase Java en el fichero JSP. Sun recomienda que usemos este atributo con cautela, ya puede limitar la habilidad del motor del JSP a proporcionar la superclase especializada que mejora la calidad del fichero compilado.

extends=”package.class”

1.2.5 ATRIBUTO IMPORT

Esta lista especifica una lista separada por comas de uno o más paquetes o clases que el fichero JSP debería importar. Las clases de los paquetes se ponen a disposición de los scriptlets, expresiones, declaraciones y etiquetas dentro del fichero JSP.

Como cabría esperar, el atributo import debe aparecer antes de cualquier etiqueta que refiera la clase importada. Para importar varios paquetes, podemos usar una lista separada por comas, más de una directiva import o una combinación de ambas.

import= “{ package.class | package.* }, ...”

1.2.6 ATRIBUTO SESSION

Todo cliente debe unirse a una sesión HTTP para poder usar una página JSP.

Si el valor es true, el objeto session se refiere a la sesión actual o a una nueva sesión. Si el valor es false, no podemos utilizar el objeto session en el fichero JSP. El valor por defecto es true.

session=”true|false”

1.2.7 ATRIBUTO BUFFER

Este atributo especifica el tamaño del buffer en kilobytes que será usado por el objeto out para manejar la salida enviada desde la página JSP compilada hasta el navegador cliente. El valor por defecto es 8kb.

buffer=”none|8kb|sizekb”

1.2.8 ATRIBUTO AUTOFLUSH

Este atributo especifica si la salida sería enviada o no cuando el buffer esté lleno. Por defecto, el valor es true, el buffer será descargado. Si especificamos false, se lanzará una excepción cuando el buffer se sobrecargue.

autoFlush=”true|false”


/ 34

u.d. 1 NIVEL II

1.2.9 ATRIBUTO STHREADSAFE

Este atributo especifica si la seguridad de threads está implementada en el fichero JSP. El valor por defecto, true, significa que el motor puede enviar múltiples solicitudes concurren-tes a la página.

Si usamos el valor por defecto, varios threads pueden acceder a la página JSP. Por lo tanto, debemos sincronizar nuestros métodos para proporcionar seguridad de threads.

Con false, el motor JSP no envía solicitudes concurrentes a la página JSP.

Probablemente no querremos forzar esta restricción en servidores de gran volumen porque

puede dañar la habilidad del servidor de enviar nuestra página JSP a múltiples clientes.

isThreadSafe=”true|false”

1.2.10 ATRIBUTO ERRORPAGE

Este atributo especifica un path a un fichero JSP al que este fichero JSP envía excepciones. Si el path empieza con una “/”, el path es relativo al directorio raíz de documentos de la aplicación JSP y es resuelto por el servidor Web. Si no, el path es relativo al fichero JSP actual.

errorPage=”URLrelativa”

1.2.11 ATRIBUTO ISERRORPAGE

Este atributo especifica si el fichero JSP muestra una página de error. Si es true, podemos usar el objeto exception, que contiene una referencia a la excepción lanzada, en el fichero JSP. Si es false (el valor por defecto), significa que no podemos usar el objeto exception en el fichero JSP.

isErrorPage=”true|false”

1.3 DIRECTIVA INCLUDELa directiva include se usa para insertar un fichero dentro de una página JSP cuando se compila la página JSP. El texto del fichero incluido se añade a la página JSP (ver la descrip-ción de un fichero estático más adelante en esta página)

El fichero incluido puede ser un fichero JSP, un fichero HTML, o un fichero de texto.

También ser un fichero de código escrito en lenguaje Java.

Hay que ser cuidadoso en que el fichero incluido no contenga las etiquetas <html>,

</html>, <body>, or </body>. Porque como todo el contenido del fichero incluido se añade en esa localización del fichero JSP, estas etiquetas podrían entrar en conflicto con las eti-quetas similares del fichero JSP.

Si el fichero incluido es un fichero JSP, las etiquetas JSP son analizadas y sus resultados se incluyen (junto con cualquier otro texto) en el fichero JSP.

Sólo podemos incluir ficheros estáticos. Esto significa que el resultado analizado del fichero incluido se añade al fichero JSP justo donde está situada la directiva. Una vez que el fichero incluido es analizado y añadido, el proceso continúa con la siguiente línea del fichero JSP llamante.

Un include estático significa que el texto del fichero incluido se añade al fichero JSP.


/ 35

u.d. 1 NIVEL II

Además en conjunción con otra etiqueta JSP, <jsp:include>: podemos incluir

ficheros estáticos o dinámicos:

Un fichero estático es analizado y si contenido se incluye en la página JSP llamante.

Un fichero dinámico actúa sobre la solicitud y envía de vuelta un resultado que es incluido en la página JSP.

Podemos incluir un fichero en la localización específica del fichero JSP usando la directiva include con la siguiente sintaxis:

“<%@ include file=”URL” %>

Aquí la URL puede ser una URL relativa indicando la posición del fichero a incluir dentro del servidor.

1.4 DIRECTIVA TAGLIBPermite ampliar el conjunto de etiquetas que el intérprete JSP puede usar, ampliando así de manera casi ilimitada la funcionalidad del mismo. La sintaxis de esta directiva es la siguiente:

<%@ taglib uri=”URIdeLaLibreríaDeEtiquetas” prefix=”prefijoLibrería” %>

donde se distinguen dos atributos:

•• uri=”URIdeLaLibreríaDeEtiquetas”: dirección absoluta (posición dentro el árbol de directorios “WEB-INF”) o relativa (nombre virtual definido desde el descriptor de despliegue de la aplicación “web.inf”) del descriptor de despliegue de la librería de etiquetas (TLD).

•• prefix=”prefijoLibrería”: prefijo a usar dentro de la página para hacer uso de las etiquetas definidas en la librería de etiquetas indicada (pudiendo tener así etiquetas con igual nombre en distintas librerías), esto es, identifica la librería, “prefijoLibrería:nombreEtiqueta”.

Componentes de una etiqueta JSP:

•• Clase manejadora de etiqueta (Tag Handler Class): define el comportamiento de la etiqueta

•• Fichero de descripción de la librería de etiqueta (tag lirary descriptor fiel): mapea los nombres de los elementos XML a la implementación de la etiqueta

•• Fichero JSP que usa la librería de etiquetas

1.5 ELEMENTOS DE SCRIPTING Mientras que las directivas influían en la forma de procesar la página JSP por parte del con-tenedor de páginas JSP, los elementos de scripting son los que nos permiten incluir código Java en las páginas JSP, los elementos de scripting nos van a permitir declarar objetos, instanciarlos, ejecutar métodos, definirlos, etc., es decir son los que realmente nos permiten realizar la programación de nuestra página JSP.

Hay cuatro elementos de scripting, cuya funcionalidad resumimos a continuación:

•• Declaraciones: son bloques de código Java incluido en la página JSP utilizados para declarar variables y métodos propios dentro de la página JSP. Un bloque de declara-ción se encuentra entre los delimitadores <%! %>.

/ 36

u.d. 1 NIVEL II

•• Scriptlets: un scriptlet es un fragmento de código Java incluido en una página JSP que se ejecutará cuando se realice una petición de la misma. Un scriptlet se encontrará entre los delimitadores <% %>, como curiosidad cabe comentar que estos delimitadores son los mismos que utilizan las páginas ASP (Active Server Pages) para delimitar el script de servidor. En un scriptlet podemos encontrar cualquier código Java válida, no debemos olvidar que las páginas JSP al igual que los servlets pueden utilizar todos los APIs ofrecidos por el lenguaje Java.

•• Expresiones: una expresión es una notación especial para un scriptlet que devuelve un resultado a la respuesta dada al usuario, la expresión se evalúa y se devuelve como una cadena que se envía al cliente. Una expresión se encuentra entre los delimitadores <%= %>, que son también los mismos delimitadores que se utilizan para devolver el valor de expresiones dentro de una página ASP.

•• Comentarios: estos elementos permiten documentar nuestro código fuente, se encuen-tran entre los delimitadores <%-- --%>. Estos comentarios no serán visibles en el navegador, ya que son comentarios de JSP que serán tratados por el contenedor de páginas JSP, no se deben confundir con los comentarios HTML (), que si serán visibles desde el navegador y enviados como tales al usuario.

1.5.1 DECLARACIONES

Una declaración JSP nos permite definir métodos o campos que serán insertados dentro del cuerpo principal de la clase servlet (fuera del método service que procesa la petición). Tienen la siguiente forma:

<%! Código Java%>

Como las declaraciones no generan ninguna salida, normalmente se usan en conjunción con expresiones JSP o scriptlets. Por ejemplo, aquí tenemos un fragmento de JSP que imprime el número de veces que se ha solicitado la página actual desde que el servidor se arrancó (o la clase del Servlet se modificó o se recargó):

<%! private int accessCount = 0; %>

Accesses to page since server reboot:

<%= ++accessCount %>

Como con los scriptlet, si queremos usar los caracteres “%>”, ponemos “%\>”. Finalmente, observa que el equivalente XML de <%! Código %> es:

<jsp:declaration> Código</jsp:declaration>

1.5.2 SCRIPTLETS

Siempre que sea posible, debemos evitar usar scriptlets JSP mientras que las librerías de etiquetas proporcionen una funcionalidad similar. Esto hace que las páginas JSP sean más fáciles de leer y de mantener, ayuda a separar la lógica de negocios de la lógica de presen-tación, y hará que nuestras páginas evoluciones más fácilmente al estilo JSP 2.0. (JSP 2.0 soporta, pero no favorece el uso de scriptlets).


/ 37

u.d. 1 NIVEL II

En los siguientes ejemplos, por cada representación de tipo de datos del cliente se debe escribir un scriptlet:

customers como un array de Customers: <table> <% for ( int i=0; i<customers.length; i++ ) { %> <tr> <td><%= customers[i].getLastName() %></td> <td><%= customers[i].getFirstName() %></td> </tr> <% } %> </table>

customers como una Enumeration:

<table> <% for ( Enumeration e = customers.elements(); e.hasMoreElements(); ) { Customer customer = (Customer)e.nextElement(); %> <tr> <td><%= customer.getLastName() %></td> <td><%= customer.getFirstName() %></td> </tr> <% } %> </table>

Sin embargo, si se utilizara una librería común, hay una alta flexibilidad al utilizar los distintos tipos de customers. Por ejemplo, en la Librería de Etiquetas Estándar de JSO, el siguiente fragmento de código JSP soportará las representaciones de array y de Enumeration de customers:

<table> <c:forEach var=”customer” items=”${customers}”> <tr> <td><c:out value=”${customer.lastName}”/></td> <td><c:out value=”${customer.firstName}”/></td> </tr> </c:forEach> </table>

En el espíritu de adoptar el modelo del patrón de diseño Modelo-Vista-Controlador (MVC) para reducir el acoplamiento entre la capa de presentación de la lógica de negocio, no se debería usan scriptlets JSP para escribir lógica de negocio. Como en la siguiente imagen lo muestra:

imagen1-3-1


/ 38

u.d. 1 NIVEL II

En vez de eso, usaremos los scriptlets si es necesario transformar datos (también llamados “objeto valor”) devueltos desde el procesamiento de las solicitudes del cliente en un for-mato listo para el cliente apropiado. Incluso entonces, esto se podría hacer mejor desde un servlet controlador o desde una etiqueta personalizada. Por ejemplo, el siguiente ejemplo recoge los nombres de los clientes desde una base de datos y los muestra directamente en el cliente:

<% // NO SE RECOMIENDA HACERLO EN UN SCRIPTLET

Connection conn = null; try { // Get connection InitialContext ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup(“customerDS”); conn = ds.getConnection(); // Get customer names Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(“SELECT name FROM customer”); // Display names while ( rs.next() ) { out.println( rs.getString(“name”) + “<br>”); } } catch (SQLException e) { out.println(“Could not retrieve customer names:” + e); } finally { if ( conn != null ) conn.close(); }%>

El siguiente fragmento de código JSP es mejor ya que delega la interacción con la base de datos en una etiqueta personalizada myTags:dataSource que encapsula y oculta la depen-dencia del código de la base de datos en su implementación:

<myTags:dataSource name=”customerDS” table=”customer” columns=”name” var=”result” /><c:forEach var=”row” items=”${result.rows}”> <c:out value=”${row.name}” /> <br /></c:forEach>

result es una variable de scripting introducida por la etiqueta personalizada myTags:data-Source para contener el resultado de recuperar los nombres de los clientes desde la base de datos. El código JSP también se puede mejorar para generar distintos tipos de salidas (HTML, XML, WML) basándose dinámicamente en las necesidades del cliente, sin impactar en el código final (para la etiqueta dataSource). Una mejor opción es delegar esto en un servlet controlador que realice la recuperación de los datos y proporcione el resultado al JSP a través de un atributo del ámbito de la solicitud.

1.5.3 EXPRESIONES

Las expresiones JSO se deberían utilizar casi tan poco como los scriptlets. Para ilustrar esto, vemos los tres siguientes ejemplos que realizan tareas.

Ejemplo1 (con código Java explícito):

<%= myBean.getName() %>


/ 39

u.d. 1 NIVEL II

Ejemplo 2 (con etiqueta JSP):

<jsp:getProperty name=”myBean” property=”name” />

Ejemplo 3 (con etiqueta JSTL):

<c:out value=”${myBean.name}” />;

El ejemplo 1 asume que se declara una variable de script llamada myBean. Los otros dos ejemplos asumen que myBean es un atributo que se puede encontrar usando PageContext.findAttribute(). El segundo ejemplo también asume que myBean se introdujo en la página usando <jsp:useBean>.

De los tres ejemplos, el preferido es el de la etiqueta JSTL. Es casi tan corto como la expre-sión JSP, casi tan fácil de leer y de mantener, y no trata con scriptlets Java (lo que requeri-ría que el desarrollador Web estuviera familiarizado con el lenguaje y las llamadas al API). Además, hace que la página se puede transportar fácilmente al estilo de programación JSP 2.0, donde esto se podría conseguir simplemente escribiendo ${myBean.name} en la planti-lla de texto. Independientemente de la elección adoptada, debería hacerse de acuerdo con los desarrolladores web y de forma consistente en todos los JSPs producidos en el mismo proyecto. Deberíamos observar que el ejemplo JSTL realmente es algo diferente en que obtiene el valor de myBean desde el contexto de la página en lugar de desde una variable de script local.

Finalmente, las expresiones JSP tienen preferencia sobre los scriptlets JSP equivalentes lo que tiene que ver con la sintaxis del lenguaje de script subyacente. Por ejemplo:

<%= x %>

Tiene preferencia sobre :

<% out.print( x ); %>

1.5.4 COMENTARIOS

Los comentarios se utilizan para describir información adicional o los propósitos del código cercano. Aquí tenemos dos tipos para los ficheros JSP: uno para JSP y otro para comenta-rios del lado del cliente.

Los comentarios JSP (también conocidos como comentarios del lado del servidor) sólo son visibles en el lado del servidor (es decir, no se propagan al lado del cliente. Se prefie-

ren los comentarios puros JSP sobre los comentarios JSP con comentarios de scripts, ya que los primeros son menos dependientes del len-guaje de script subya-cente, y será más fácil evolucionarlos a JSP 2.0. La siguiente tabla ilustra esto:

imagen1-3-2

/ 40

u.d. 1 NIVEL II

Comentarios del Lado del Cliente

Los comentarios del lado del cliente () se pueden utilizar para anotar respuestas enviadas al cliente con información adicional sobre las respuestas. No deberían contener información sobre el comportamiento y al estructura interna de la aplicación en el servidor o del código generado en las respuestas.

Normalmente se desaconseja el uso de comentarios del lado del cliente, ya que el cliente/usuario no necesita leer este tipo de comentarios directamente para poder interpretar las respuestas recibidas. Hay una excepción para autentificación y propósitos legales como una información de copyright. Otra excepción es para que los autores de HTML utilicen una pequeña cantidad de comentarios HTML para guiar la estructura del documento HTML, por ejemplo:

 ... ... ... ...

Bloques de Comentarios Multi-línea

Un bloque de comentario multi-línea, tanto JSP como del lado del cliente, se decora con el carácter guión “-”. En la especificación XML, el string doble-guión “--” no está permitido dentro de un bloque de comentarios XML. Así, por compatibilidad y consistencia con esta especificación, no debemos utilizar dobles-guiones para decorar líneas de comentarios dentro de un bloque de comentarios de varias líneas. La siguiente tabla ilustra esta preferencia usando un bloque de comentarios del lado del servidor:

imagen1-3-3

final de lección

/ 41

!!


Conclusiones:


• Idealmente los scriptles JSP no deberían existir en un JSP para que el JSP sea inde-pendiente del lenguaje de script, y se evite la implementación de la lógica de negocio dentro del JSP.

• Si no es posible, usaremos objetos valor (JavaBeans) para llevar información desde y hacia el lado del servidor, y usaremos scriptles JSP para transformar estos objetos en salidas para el cliente.

• Las directivas son un conjunto de etiquetas JSP que ofrecen al contenedor de páginas JSP instrucciones específicas de cómo se debe procesar una página determinada

• Utilizaremos etiquetas personalizadas siem-pre que sea posible para procesar la informa-ción en el lado del servidor.

• Una declaración JSP nos permite definir méto-dos o campos que serán insertados dentro del cuerpo principal de la clase servlet (fuera del método service que procesa la petición)

lección 4: Objetos integrados

/ 42

u.d. 1 NIVEL II

LECCION 4: OBJETOS INTEGRADOS INTRODUCCIÓN Se puede hacer referencia a una serie de objetos implícitos , que se corresponden con objetos útiles del API de servlets (petición, respuesta, ...) y que en realidad son variables instanciadas de manera automática en el servlet generado a partir del JSP. Los objetos predefinidos en JSP se referencian en la siguiente tabla.

imagen1-4-1

1.1 EL OBJETO REQUEST Este objeto va a representar la petición realizada por el usuario que a demandado la página JSP actual.

Este objeto ofrece acceso a toda la información asociada con la petición, podemos acceder a los campos enviados de un formulario, cabeceras de petición HTTP, cookies, etc. El objeto request debe implementar el interfaz javax.servlet.ServletRequest, y en este caso, como el protocolo es HTTP debe implementar el interfaz javax.servlet.http.HttpServletRequest, que es un interfaz que hereda del anterior.

El objeto request es uno de los cuatro objetos integrados que permiten el almacenamiento y recuperación de atributos, la utilización de los atributos ya la vimos al tratar los servlets. Entendíamos por atributo cualquier tipo de objeto Java, que en este caso se va a poder almacenar en una petición realizada a una página JSP o a un recurso del servidor.

El objeto request va a presentar todos los métodos contenidos en los interfaces Servle-tRequest y HttpServletRequest, los cuales ya conocemos de los servlets, aunque vamos a comentar de forma breve los métodos más relevantes del objeto request para refrescar la memoria del lector.


/ 43

u.d. 1 NIVEL II

Podemos agrupar los métodos del objeto integrado request atendiendo a la funcionalidad que ofrecen.

En un primer grupo podemos tener aquellos métodos que nos permiten utilizar los atributos en la petición, estos métodos se comentan a continuación:

•• void setAttribute(String nombre, Object valor): almacena un atributo en la petición actual. Como se puede comprobar el atributo puede ser cualquier tipo de objeto.

• Object getAttribute(String nombre): devuelve un atributo almacenado en la petición actual.

• Enumeration getAttributeNames(): devuelve dentro de un objeto java.util.Enumeration los nombres de todos los atributos disponibles en al petición.

• void removeAtttribute(String nombre): elimina de la petición el atributo indicado por parámetro.

Estos métodos para la manipulación de atributos son comunes a cuatro objetos integrados, al objeto request, al objeto session, al objeto application y al objeto pageContext, es decir todos estos objetos permiten almacenar atributos. A través de la asignación y recuperación de atributos es posible transferir información, en forma de los objetos (atributos) almace-nados, entre distintas páginas JSP y servlets.

La diferencia que existe a la hora de almacenar un atributo en cualquiera de los cuatro objetos integrados, es el ámbito del objeto que se va a almacenar como atributo, existen cuatro ámbitos distintos, uno por cada objeto integrado que permite almacenar y recuperar atributos.

Los atributos almacenados dentro del objeto request poseen un ámbito de petición, esto quiere decir que sólo se encontrarán disponibles en la página JSP o servlet a los que se ha realizado una petición.

Ejemplo:Uso frecuente en formularios

imagen1-4-2

Lo que hace esta línea es solicitar la información de un campo específico enviado por medio de un formulario en nuestra página. Este dato se guarda en la variable “un_campo” que es del tipo String.También se podría recoger éste campo si el mismo fuera pasado por URL de la siguiente manera: http://www.midominio.com/formulario.jsp?nombre_del_campo=CafeCeativo


/ 44

u.d. 1 NIVEL II

Los métodos más importantes de este objeto son los que s emuestran en la siguiente imagen:

imagen1-4-3

1.2 EL OBJETO RESPONSE

imagen1-4-4

En la siguiente imagen se puede ver la interacción entre el objeto Request y el objeto Response.

imagen1-4-5


/ 45

u.d. 1 NIVEL II

1.3 EL OBJETO OUT Este objeto es una instancia de la clase javax.servlet.jsp.JspWriter, y representa el flujo de salida de la página JSP.

La clase JspWriter es una clase abstracta que hereda de la clase java.io.Writer, implemen-tando varios de los métodos de la clase java.io.PrintWriter. En particular hereda los distintos métodos write() de la clase Writer, e implementa todos lo métodos print() y println() ofrecidos por la clase PrintWriter.

La clase java.io.PrintWriter ya la utilizábamos para manipular el flujo de salida de los servlets, para enviar contenidos al cuerpo de la respuesta HTTP, para ello utilizábamos el método getWriter() del interfaz javax.servlet.ServletResponse.

El objeto out va a realizar la misma labor que el objeto PrintWriter que manejábamos en los servlets.

Se debe señalar que el objeto integrado out utilizará un búfer intermedio, para enviar el contenido del cuerpo de la respuesta HTTP al cliente, si no indicamos lo contrario en la directiva page.

En este caso, al no ser el objeto out instancia de una clase ya conocida por los que conocéis servlets, vamos a comentar todos los métodos que ofrece la clase JspWriter:

o void clear(): elimina el contenido del búfer. Si el búfer ya ha sido vaciado para enviar su contenido al cliente y se lanza el método clear() se producirá una excepción de la clase IOException.

o void clearBuffer(): elimina los contenidos actuales del búfer. Si algún contenido del búfer ya ha sido enviado al cliente no se producirá una excepción.

o void close(): cierra el flujo de salida enviando al cliente los contenidos del búfer, una vez cerrado el flujo de salida, no podremos utilizar el método print() o write() sobre el objeto out ya que no generará salida alguna. Una vez que ha sido lanzado el método close() sobre el objeto out no se devolverá ningún contenido al cliente.

o void flush(): vacía el contenido actual del búfer del objeto out (flujo de salida) envián-dolo al cliente.

o int getBufferSize(): devuelve el tamaño del búfer de salida en bytes. El tamaño por defecto de este búfer de 8KB, pero podemos modificarlo a través de la propiedad buffer de la directiva page.

o int getRemaining(): devuelve el número de bytes que no se han utilizado todavía del búfer de salida.

o boolean isAutoFlush(): indica si el contenido del búfer es enviado de forma automá-tica al cliente cuando el búfer se llena. Por defecto el contenido del búfer se envía de forma automática al cliente cuando se llena, este comportamiento se puede modificar a través de la propiedad autoFlush de la directiva page.

o void newLine(): escribe un separador de línea.

La clase javax.servlet.jsp.JspWriter posee numerosos métodos print() y println() para escribir en el flujo de salida que se devuelve al cliente distintos tipos de datos y objetos del lenguaje Java.

La clase JspWriter hereda de la clase java.io.Writer, y por lo tanto el objeto out también presentará los métodos de esta otra clase, como pueden ser los distintos métodos write() que permiten escribir en un flujo de salida de caracteres.


/ 46

u.d. 1 NIVEL II

El objeto out lo vamos a utilizar sobretodo para enviar contenidos al cliente, dónde utili-zamos una expresión de JSP con la notación <%=%> se puede utilizar el objeto out con su correspondiente método print() o println(), pasándole por parámetro la expresión que se quiere evaluar y devolver.

1.4 EL OBJETO EXCEPTIONPermite recoger las excepciones ocurridas en tiempo de ejecución. Es una instancia de la clase java.lang.Throwable y de ámbito page. Sólo estará disponible en una página de error si se ha definido el modificador isErrorPage de antemano en la directiva page.

<%@ page isErrorPage = “true”%>

La excepción deberá ser recogida mediante la variable “exception”.

A continuación se muestran los distintos métodos que nos ofrece el objeto exception:

•• String getMessage(): devuelve el mensaje de error descriptivo que se corresponde con la excepción que se ha lanzado.

•• void printStackTrace(PrintWriter salida): devuelve en un objeto PrintWriter el volcado de pila que se corresponde que la excepción que se ha producido.

•• String toString(): devuelve una breve descripción del objeto Throwable, que consiste en el nombre de la clase de la excepción y una breve descripción.

1.5 EL OBJETO SESSIONEste objeto integrado es una instancia del interfaz javax.servlet.http.HttpSession y va a repre-sentar la sesión del usuario actual conectado a nuestra aplicación Web, este objeto lo vamos a utilizar sobretodo para almacenar y recuperar información relativa al usuario actual.

Las sesiones en las páginas JSP tienen el mismo significado que en los servlets, es decir, una sesión se mantiene entre distintas páginas JSP pertenecientes a una misma aplicación Web y además podemos almacenar información en el objeto session en forma de atributos (objetos) para que se mantenga entre distintas páginas JSP

Una sesión es una conexión continuada de un mismo browser a un servidor durante un tiempo prefijado de tiempo. Este tiempo depende habitualmente del servidor, aunque a partir de la versión 2.1 del Servlet API puede establecerse mediante el método setMaxInactiveInterval(int) de la interface HttpSession. Esta interface es la que proporciona los métodos necesarios para mantener sesiones.

Al igual que las cookies, las sesiones son compartidas por todos los servlets de un mismo servidor. De hecho, por defecto se utilizan cookies de una forma implícita en el mantenimiento de sesiones. Por ello, si el browser no acepta cookies, habrá que emplearse las sesiones en conjunción con la reescritura de URLs

La forma de obtener una sesión es mediante el método getSession(boolean) de un objeto HttpServletRequest. Si este boolean es true, se crea una sesión nueva si es necesario mien-tras que si es false, el método devolverá la sesión actual. Por ejemplo:

...HttpSession miSesion = req.getSession(true);...

crea una nueva sesión con el nombre miSesion.


/ 47

u.d. 1 NIVEL II

Una vez que se tiene un objeto HttpSession, es posible mantener una colección de pares nombre de dato/valor de dato, de forma que pueda almacenarse todo tipo de información sobre la sesión. Este valor puede ser cualquier objeto de la clase Object que se desee. La forma de añadir valores a la sesión es mediante el método putValue(String ,Object ) de la clase HttpSession y la de obtenerlos es mediante el método getValue(String , Object ) del mismo objeto. Esto puede verse en

el siguiente ejemplo:

...HttpSession miSesion=req.getSesion(true);CarritoCompras compra = (CarritoCompras)miSesion.getValue(miSesion.getId());if(compra==null) {compra = new CarritoCompras();miSesion.putValue(miSesion.getId(), compra);}

...

En este ejemplo, se supone la existencia de una clase llamada CarritoCompras. En primer lugar se obtiene una nueva sesión (en caso de que fuera necesario, si no se mantendrá una creada previamente), y se trata de obtener el objeto CarritoCompras añadido a la sesión. Obsérvese que para ello se hace una llamada al método getId() del objeto miSesion. Cada sesión se encuentra identificada por un identificador único que la diferencia de las demás. Este método devuelve dicho identificador. Esta es una buena forma de evitar confusiones con el nombre de las sesiones y el de sus valores. En cualquier caso, al objeto CarritoCompras se le podía haber asociado cualquier otra clave. Si no se hubiera añadido previamente el objeto CarritoCompras a la sesión, la llamada al método getValue() tendría como resultado null. Obsérvese además, que es preciso hacer un cast para pasar el objeto Object a objeto CarritoCompras.

En caso de que compra sea null, es decir, que no existiera un objeto añadido previamente, se crea un nuevo objeto CarritoCompras y se añade a la sesión miSesion mediante el método putValue(), utilizando de nuevo el identificador de la sesión como nombre.

Además de estos métodos mencionados, la interface HttpSession define los siguientes métodos:

•• getCreationTime(): devuelve el momento en que fue creado la sesión (en milisegun-dos).

•• getLastAccessedTime():devuelve el último momento en que el cliente realizó una petición con el identificador asignado a una determinada sesión (en milisegundos)

•• getValueNames(): devuelve un array con todos los nombres de los objetos asociados con la sesión.

•• invalidate(): invalida la sesión en curso.

•• isNew(): devuelve un boolean indicando si la sesión es “nueva”.

•• removeValue(String): elimina el objeto asociado con una determinada clave.

De todos los anteriores métodos conviene comentar dos en especial: invalidate() y isNew().

El método invalidate() invalida la sesión en curso. Tal y como se ha mencionado con ante-


/ 48

u.d. 1 NIVEL II

rioridad, una sesión puede ser invalidada por el propio servidor si en el transcurso de un intervalo prefijado de tiempo no ha recibido peticiones de un cliente. Invalidar quiere decir eliminar el objeto HttpSession y los valores asociados con él del sistema.

El método isNew() sirve para conocer si una sesión es “nueva”. El servidor considera que una sesión es nueva hasta que el cliente se una a la sesión. Hasta ese momento isNew() devuelve true.

Un valor de retorno true puede darse en las siguientes circunstancias:

•• 1. El cliente todavía no sabe nada acerca de la sesión

•• 2. La sesión todavía no ha comenzado.

•• 3. El cliente no quiere unirse a la sesión. Ocurre cuando el browser tiene la aceptación de cookies desactivada.

Otro ejemplo Librerías Fuentes utiliza seguimiento de sesión para seguir la pista de los libros de la hoja de pedido del usuario. Aquí hay un ejemplo de CatalogServlet obteniendo un identificador de sesión de usuario, y obteniendo y seleccionando datos de la aplicación asociada con la sesión de usuario.

public class CatalogServlet extends HttpServlet {public void doGet (HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{// Get the userʼs session and shopping cartHttpSession session = request.getSession(true);ShoppingCart cart =(ShoppingCart)session.getValue(session.getId());// If the user has no cart, create a new oneif (cart == null) {cart = new ShoppingCart();session.putValue(session.getId(), cart);}...}}

Como un objeto puede ser asociado con una sesión, el ejemplo Librerías Fuentes sigue la pista de los libros que el usuario ha pedido dentro de un objeto. El tipo del objeto es Sho-ppingCart y cada libro que el usuario a seleccionado es almacenado en la hoja de pedidos como un objeto Shop pingCartItem. Por ejemplo, el siguiente código procede del método doGet de CatalogServlet.

public void doGet (HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException{HttpSession session = request.getSession(true);ShoppingCart cart = (ShoppingCart)session.getValue(session.getId());...// Check for pending adds to the shopping cartString bookId = request.getParameter(“Buy”);//If the user wants to add a book, add it and print the resultString bookToAdd = request.getParameter(“Buy”);if (bookToAdd != null) {BookDetails book = database.getBookDetails(bookToAdd);cart.add(bookToAdd, book);out.println(“<p><h3>” + ...);}}


/ 49

u.d. 1 NIVEL II

Finalmente, observa que una sesión puede ser designada como nueva. Una sesión nueva hace que el método isNew de la clase HttpSession devuelva true, indicando que, por ejemplo, el cliente, todavía no sabe nada de la sesión. Una nueva sesión no tiene datos asociados.

Podemos tratar con situaciones que involucran nuevas sesiones. En el ejemplo Librerías Fuentes, si el usuario no tiene hoja de pedido (el único dato asociado con una sesión), el servlet crea una nueva.

Alternativamente, si necesitamos información sobre el usuario al iniciar una sesión (como el nombre de usuario), podríamos querer redireccionar al usuario a un “página de entrada” donde recolectamos la información necesaria.

Invalidar la sesión

Una sesión de usuario puede ser invalidada manual o automáticamente, dependiendo de donde se esté ejecutando el servlet. (Por ejemplo, el Java Web Server, invalida una sesión cuando no hay peticiones de página por un periodo de tiempo, unos 30 minutos por defecto). Invalidar una sesión significa eliminar el objeto HttpSession y todos sus valores del sistema.

Para invalidar manualmente una sesión, se utiliza el método invalidate de “session”. Algu-nas aplicaciones tienen un punto natural en el que invalidar la sesión. El ejemplo Librerías Fuentes invalida una sesión de usuario después de que el usuario haya comprado los libros. Esto sucede en el ReceiptServlet.

public class ReceiptServlet extends HttpServlet {public void doPost(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException {...scart = (ShoppingCart)session.getValue(session.getId());...// Clear out shopping cart by invalidating the sessionsession.invalidate();// set content type header before accessing the Writerresponse.setContentType(“text/html”);out = response.getWriter();...}}

1.6 EL OBJETO APPLICATIONRepresenta la aplicación web en el que se esta ejecutando la página JSP, es decir, que con-tiene el método relativo al contexto dónde se está ejecutando el servlet al que corresponde el JSP.

getServletConfig().getContext()

1.7 EL OBJETO PAGECONTEXTEste objeto instancia de la clase abstracta javax.servlet.jsp.PageContext, permite acceder al espacio de nombres de la página JSP actual, ofrece también acceso a varios atributos de la página así como una capa sobre los detalles de implementación.

Además el objeto pageContext ofrece una serie de métodos que permiten obtener el resto de los objetos integrados de JSP, también nos va a permitir acceder a los atributos perte-necientes a distintos ámbitos.

Podemos distinguir varios grupos de métodos en la clase PageContext, el primero de estos grupos es el que nos permite acceder y obtener los distintos objetos integrados de JSP.


/ 50

u.d. 1 NIVEL II

Estos métodos no los utilizaremos nunca directamente en nuestras páginas JSP veremos que serán muy útiles cuando tratemos la implementación del mecanismo de etiquetas per-sonalizadas, además estos métodos sí que son utilizados por el servlet equivalente a una página JSP determinada para obtener los distintos objetos integrados y así poder realizar la traducción.

Los métodos que permiten obtener los objetos integrados son los siguientes.

•• Exception getException(): devuelve la excepción que se le ha pasado a la página de error, es decir, devuelve una referencia al objeto integrado exception.

•• JspWriter getOut(): devuelve el flujo de salida actual, es decir, el objeto out.

•• Object getPage(): devuelve la instancia del servlet para la página actual, es decir, el objeto integrado page.

•• ServletRequest getRequest(): devuelve la petición que inició el procesamiento de la página JSP actual, es decir, el objeto integrado request.

•• ServletResponse getResponse(): devuelve la respuesta que la página envía al cliente que realizó la petición, es decir, el objeto integrado response.

•• ServletConfig getServletConfig(): devuelve un objeto que va a representar la configu-ración del servlet con el que se corresponde la página JSP actual, es decir, se obtiene una referencia al objeto integrado config.

•• ServletContext getServletContext(): devuelve el contexto en el que se ejecuta el servlet que se corresponde con la página actual, es decir, se obtiene una referencia al objeto integrado application.

•• HttpSession getSession(): devuelve la sesión asociada con la petición de página actual, si existe se obtendrá una referencia al objeto integrado session.

El siguiente conjunto de métodos es utilizado para controlar el procesamiento de páginas, indicando si se desea incluir un contenido en la página actual o redirigir la ejecución de la página hacia otro recurso.

•• void forward(String ruta): este método redirige la ejecución de la página actual hacia el recurso indicado mediante su ruta relativa, sin embrago una vez que se haya pro-cesado el recurso al que se ha enviado la ejecución, se vuelve a procesar la página de origen. Si el contenido del búfer del objeto out ya ha sido enviado (aunque sea parcialmente) al cliente se producirá un error.

•• void include(String ruta): incluye el resultado de la ejecución del recurso indicado a través de su ruta relativa. La diferencia con el método anterior es que en la página de origen es posible enviar previamente el contenido del búfer.

1.8 EL OBJETO PAGE El objeto page es una instancia de la clase java.lang.Object, y representa la página JSP actual, o para ser más exactos, una instancia de la clase del servlet generado a partir de la página JSP actual. Se puede utilizar para realizar una llamada a cualquiera de los métodos definidos por la clase del servlet.

Utilizar el objeto page, es similar a utilizar la referencia a la clase actual, es decir, la refe-rencia this.


/ 51

u.d. 1 NIVEL II

Este objeto pertenece a la categoría de objetos integrados relacionados con los servlets, en esta caso representa una referencia al propio servlet.

En nuestras páginas JSP no es muy común utilizar el objeto page.

En el siguiente apartado, que finaliza este capítulo y que contiene el último de los objeto integrados, trataremos el objeto config que representa la configuración del servlet con el que se corresponde la página JSP actual.

1.9 EL OBJETO CONFIGEste objeto integrado es una instancia del interfaz javax.servlet.ServletConfig, y su función es la de almacenar información de configuración del servlet generado a partir de la página JSP correspondiente. Normalmente las páginas JSP no suelen interactuar con parámetros de inicialización del servlet generado, por lo tanto el objeto config en la práctica no se suele utilizar.

El objeto config pertenece a la categoría de objetos integrados relacionados con los ser-vlets.

Los métodos que ofrece este objeto integrado son los siguientes.

o String getInitParameter(String nombreParametro): este método devuelve un objeto String que representa el valor del parámetro de inicialización cuyo nombre le pasamos por parámetro. Si el parámetro no existe se devolverá null.

o Enumeration getInitParameterNames(): devuelve el nombre de todos los parámetros de inicialización del servlet como un objeto java.util.Enumeration que contiene obje-tos String, uno por cada nombre del parámetro. Devolverá un objeto Enumeration vacío si el servlet que se corresponde con la página JSP actual no tiene parámetros de inicialización.

o ServletContext getServletContext(): este método devuelve una referencia al objeto ServletContext en el que se está ejecutando el servlet que se corresponde con la página JSP actual

o String getServletName(): devuelve el nombre de la instancia actual del servlet.

final de lección

/ 52

!!


Conclusiones:


• Se puede hacer referencia a una serie de objetos implícitos , que se corresponden con objetos útiles del API de servlets (petición, respuesta, ...) y que en realidad son variables instanciadas de manera automática en el ser-vlet generado a partir del JSP.

• Los objetos que hay son:

o El objeto request

o El objeto response

o El objeto out

o El objeto exception

o El objeto session

o El objeto pagecontext

o El objeto page

o El objeto config

lección 5: Tratamiento de errores en JSP

/ 53

u.d. 1 NIVEL II

LECCION 5: TRATAMIENTO DE ERRORES EN JSPINTRODUCCIÓN ¿Que sucedió la última vez que usamos una aplicación JSP e introdujimos algo incorrecta-mente? Si la aplicación estaba bien escrita, probablemente lanzaría una excepción y mostraría una página de error. Las excepciones que ocurren durante la ejecución de una aplicación JSP se llaman excepciones en tiempo de ejecución.

1.1 TIPOS DE ERRORES Y EXCEPCIONESAl igual que en una aplicación Java, una excepción es un objeto que es un ejemplar de java.lang.Throwable o de una de sus subclases. Throwable tiene dos subclases estándares -java.lang.Exception, que describe excepciones, y java.lang.Error, que describe errores.

Los errores son diferentes de las excepciones. Los errores normalmente indican problemas de enlaces o de la máquina virtual de los que nuestra aplicación Web podría no recuperarse, como errores de memoria. Sin embargo, las excepciones son condiciones que pueden capturarse y recuperarse de ellas. Estas excepciones podrían ser, por ejemplo, un NullPo-interException o un ClassCastException, que nos dicen que se ha pasado un valor nulo o un dato del tipo erróneo a nuestra aplicación mientras se estaba ejecutando.

Las excepciones en tiempo de ejecución son fáciles de manejar en una aplicación JSP, porque están almacenadas una cada vez en el objeto implícito llamado exception. Pode-mos usar el objeto exception en un tipo especial de página JSP llamado página de error, donde mostramos el nombre de la clase exception, su seguimiento de pila, y un mensaje informativo para el usuario.

Las excepciones en tiempo de ejecución son lanzadas por el fichero JSP compilado, el fichero class Java que contiene la versión traducida de nuestra página JSP. Esto significa que nuestra aplicación ha sido compilada y traducida correctamente. (Las excepciones que ocurren mientras un fichero está siendo compilado o traducido no son almacenadas en el objeto exception y tienen sus mensajes mostrados en la ventana de comandos, en vez de en la página de error. Estas no son el tipo de excepciones descritas en este punto.)

Este punto describe cómo crear una sencilla aplicación JSP con varias páginas, un compo-nente JavaBean y una página de error que ofrece mensajes informativos al usuario. En este ejemplo, el Bean sigue la pista sobre la página en la que estaba trabajando el usuario cuando se lanzó la excepción, que nos da a nosotros, el desarrollador, información útil para que podamos mostrar un mensaje informativo. Este es un simple mecanismo de seguimiento de error.

1.2 PÁGINAS JSP DE ERRORAunque las llamemos páginas de error, las páginas especializadas JSP que describimos aquí realmente muestran información sobre excepciones. Para añadir páginas de error que muestren información de excepciones a una aplicación web, seguimos estos pasos:

•• Escribimos nuestro Bean (o bean enterprise, servlet, u otro componente) para que lance ciertas excepciones bajo ciertas condiciones.


/ 54

u.d. 1 NIVEL II

•• Usamos un sencillo mecanismo de seguimiento en nuestro componente para ayudar-nos a obtener información sobre lo que estaba haciendo el usuario cuando la excepción fue lanzada. (Si nos movemos en el desarrollo de aplicaciones J2EE, nuestra aplicación podrá grabar el estado, que es la mejor forma de proporcionar información).

•• El fichero JSP usa una directiva page con errorPage que selecciona el nombre de un fichero JSP que mostrará un mensaje al usuario cuando ocurre una excepción.

•• Escribir un fichero de página de error, usando una directiva page con isErrorPage=”true”.

•• En el fichero de la página de error, usa el objeto exception para obtener información sobre la excepción.

•• Usamos mensajes informativos, en nuestra página de error o incluida desde otros ficheros, para darle al usuario un mensaje relevantemente informativo sobre lo que el usuario estaba haciendo cuando se lanzó la excepción.

Llamar a una Página de Error desde otra Página

Para hacer que las páginas muestren una página de error, cada página de la aplicación usa una directiva page con el atributo errorPage, de esta forma:

<%@ page isThreadSafe=”false” import=”java.util.*, email.Map” errorPage=”error.jsp” %>

Sólo podemos especificar un página de error por cada página JSP.

Esto significa que podemos diseñar una aplicación JSP para que cada página JSP llame a una página de error diferente, o que varias páginas JSP llamen a un misma página de error. En una aplicación, varias páginas JSP llaman a un página de error, a sí simplificamos el número de ficheros que necesitamos para mantener una aplicación.

Deberíamos usar al menos una página de error en una aplicación JSP. Si no especificamos una página de error, los mensajes de excepción y el seguimiento de pila se mostrarán en la ventana de comandos desde la que se arrancó el motor JSP, mientras que el navegador Web mostrará un mensaje de error HTTP no informativo, por ejemplo, un mensaje 404 o 501. Esta definitivamente no es una manera adecuada de manejar excepciones.

Escribir una Página de Error

Una página de error es diferente a una página normal JSP. En una página de error, debemos seleccionar explícitamente el atributo isErrorPage de la directiva page como true. También tendremos acceso al objeto exception, que nos dará información sobre la excepción.

Primero, veamos un ejemplo de la directiva page de una página de error:

<%@ page isErrorPage=”true” import=”java.util.*, email.Map” %>

Una vez que hemos seleccionado isErrorPage a true, podemos usar el objeto exception. exception es del tipo java.lang.Throwable, por eso podemos usar cualquier método definido en Throwable con exception en un scriptlet o una expresión, por ejemplo:

• <%= exception.toString() %> • <% exception.printStackTrace(); %>

La expresión exception.toString() muestra el nombre de la clase de la excepción, por ejem-plo, java.lang.NullPointerException, mientras que exception.printStackTrace() muestra el seguimiento de pila de la excepción. El nombre de la clase y el seguimiento de pila son probablemente muy útiles para nuestro usuario. Para evitar esto, podríamos querer escribir algún tipo de mecanismo de seguimiento para proporcionar información que nos ayude a darle un mensaje informativo a nuestro usuario.


/ 55

u.d. 1 NIVEL II

1.3 EJEMPLO DE TRATAMIENTO DE ERRORES El ejemplo email tiene tres páginas con formularios HTML, dos ficheros de respuesta, una página de error, y un componente JavaBean. Podemos visualizar la estructura de ficheros en algo como esto:

imagen1-5-1

•• Map.java es un componente JavaBeans que crea el fichero map.

•• email.jsp es una página JSP que muestra un formulario donde el usuario introduce un nombre y una dirección email.

•• lookup.jsp es una página JSP que permite al usuario buscar una dirección email que corresponda con un nombre.

•• lookupresponse.jsp está incluido en lookup.jsp y muestra la entrada que el usuario quiere buscar.

•• delete.jsp es una página JSP que permite al usuario borrar una dirección email que corresponde con un nombre.

•• deleteresponse.jsp está incluido en delete.jsp y muestra la entrada que fue borrada del fichero map.

•• error.jsp es una página de error que muestra información sobre manejo de excepcio-nes que ocurren durante la adicción, búsqueda o borrado de entradas en el fichero map.

Añadir un Nombre y una Direc-ción Email (email.jsp)

imagen1-5-2

<%@ include file=”copyright.html” %><%@ page isThreadSafe=”false” import=”java.util.*, email.Map” errorPage=”error.jsp” %>

<jsp:useBean id=”mymap” scope=”session” class=”email.Map” /><jsp:setProperty name=”mymap” property=”name” param=”name” /><jsp:setProperty name=”mymap” property=”email” param=”email” />

<% mymap.setAction( “add” ); %>

<html>

<head><title>Email Finder</title></head>

/ 56

u.d. 1 NIVEL II

<body bgcolor=”#ffffff” background=”background.gif” link=”#000099”>



<form method=”get”><table border=”0” cellspacing=”0” cellpadding=”5”>

<tr><td width=”120”> </td><td align=”right”> <h1>Email Finder</h1> </td></tr>

<tr><td width=”120” align=”right”><b>Name</b></td><td align=”left”><input type=”text” name=”name” size=”35”></td></tr>

<tr><td width=”120” align=”right”><b>Email Address</b></td><td align=”left”><input type=”text” name=”email” size=”35”></td></tr>

<tr><td width=”120”> </td><td align=”right”>

Please enter a name and an email address.

</td></tr>

<tr><td width=”120”> </td><td align=”right”><input type=”submit” value=”Add”></td></tr>



<% String rname = request.getParameter( “name” ); String remail = request.getParameter( “email” ); if ( rname != null) { mymap.put( rname, remail ); } %>

<tr><td width=”120”> </td><td align=”right”>The map file has <font color=”blue”><%= mymap.size() %></font> entries.</font></td></tr>

<tr><td width=”120”> </td><td align=”right”><a href=”lookup.jsp”>Lookup</a> | <a href=”delete.jsp”>Delete</a></td></tr>


/ 57

u.d. 1 NIVEL II

</table></form>

</body></html>

Buscar un Nombre en el Fichero Map (lookup.jsp)

imagen1-5-3

<%@ include file=”copyright.html” %>


<jsp:useBean id=”mymap” scope=”session” class=”email.Map” /><jsp:setProperty name=”mymap” property=”name” param=”name” />

<% mymap.setAction( “lookup” ); %>

<html><head><title> Email Finder </title></head><body bgcolor=”#ffffff” background=”background.gif” link=”#000099”>



<tr><td width=”120” align=”right”><b>Name</b></td><td align=”left”><input type=”text” name=”name” size=”35”></td></tr>


Please enter a name for which

<br>

you’d like an email address.

</td></tr>


/ 58

u.d. 1 NIVEL II


The map file has <font color=”blue”> <%= mymap.size() %></font>

entries.

</td></tr>

<tr><td width=”120”> </td><td align=”right”> <input type=”submit” value=”Lookup”> </td></tr>

<% if ( request.getParameter( “name” ) != null ) { %> <%@ include file=”lookupresponse.jsp” %> <% } %>

<tr><td width=”120”> </td><td align=”right”><a href=”email.jsp”>Add</a> | <a href=”delete.jsp”>Delete</a></td></tr></table>

</body></html>

Mostrar la Respuesta a la Bús-queda (lookupresponse.jsp)

imagen1-5-4

<%@ page import=”java.util.*, email.Map” %>

<tr><td width=”120”> </td><td align=”right”><b> Success! </b></td></tr>

<tr><td width=”120”> </td><td align=”right”><jsp:getProperty name=”mymap” property=”name” /><br><jsp:getProperty name=”mymap” property=”email” /></td></tr>

/ 59

u.d. 1 NIVEL II

Borrar una Dirección Email (delete.jsp)

imagen1-5-5



<jsp:useBean id=”mymap” scope=”session” class=”email.Map” /><jsp:setProperty name=”mymap” property=”name” param=”name” />



<% mymap.setAction( “delete” ); %>

<html><head><title> Email Finder </title></head><body bgcolor=”#ffffff” background=”background.gif” link=”#000099”>



<tr><td width=”120” align=”right”><b>Name</b></td><td align=”left”> <input type=”text” name=”name” size=”35”> </td></tr>


Please enter a name you would like to delete.

</td></tr>


The map file has <font color=”blue”> <%= mymap.size() %></font>

entries.

/ 60

u.d. 1 NIVEL II

</td></tr>

<tr><td width=”120”> </td><td align=”right”> <input type=”submit” value=”Delete”> </td></tr>



<% if ( request.getParameter( “name” ) != null ) { %> <%@ include file=”deleteresponse.jsp” %><% mymap.remove( request.getParameter(“name”) ) ; } %>

<tr><td width=”120”> </td><td align=”right”><a href=”email.jsp”>Add</a> | <a href=”lookup.jsp”>Lookup</a></td></tr>

</table></body></html>

Mostrar la Respuesta de Borrado (deleteresponse.jsp)

imagen1-5-6

<%@ page import=”java.util.*, email.Map” %>

<tr><td width=”120”> </td><td align=”right”> <b>Success!</b> </td></tr>

<tr><td width=”120”> </td><td align=”right”> <jsp:getProperty name=”mymap” property=”name” /><br><jsp:getProperty name=”mymap” property=”email” /><br><p>has been deleted from the map file.</td></tr>


/ 61

u.d. 1 NIVEL II

Mostrar Mensajes de Excepción (error.jsp)

imagen1-5-7


<%@ page isErrorPage=”true” import=”java.util.*, email.Map” %><jsp:useBean id=”mymap” scope=”session” class=”email.Map” />

<html><head><title>Email Finder</title></head><body bgcolor=”#ffffff” background=”background.gif” link=”#000099”>

<table border=”0” cellspacing=”0” cellpadding=”5”><tr><td width=”150” align=”right”> </td><td align=”right” valign=”bottom”> <h1> Email Finder </h1> </td></tr>

<tr><td width=”150” align=”right”> </td><td align=”right”> <b>Oops! an exception occurred.</b> </td></tr>

<tr><td width=”150” align=”right”> </td><td align=”right”>The name of the exception is <%= exception.toString() %>. </td></tr>

<tr><td width=”150” align=”right”> </td><td align=”right”> </td></tr>

<% if (mymap.getAction() == “delete” ) { %> <tr> <td width=150 align=right> </td> <td align=right> <b>This means that ...</b> <p>The entry you were trying to <font color=”blue”>delete</font> is not in the map file <br> <b><i>or</i></b> <br> you did not enter a name to delete. <p> Want to try <a href=”delete.jsp”>again</a>? </td>


/ 62

u.d. 1 NIVEL II

</tr> <% }

else if (mymap.getAction() == “lookup” ) { %> <tr> <td width=”150” align=”right”> </td> <td align=”right”> <b><i>This means that ...</b></i> <p>the entry you were trying to <font color=”blue”>look up</font> is not in the map file, <b><i>or</i></b> <br> you did not enter a name to look up. <p> Want to try <a href=”lookup.jsp”>again</a>? </td> </tr>

<% }

else if (mymap.getAction() == “add” ) { %> <tr> <td width=”150” align=”right”> </td> <td align=”right”> <b><i>This means that ...</b></i> <p>You were trying to <font color=”blue”>add</font> an entry with a name of null. <br> The map file doesnʼt allow this. <p> Want to try <a href=”email.jsp”>again</a>? </td> </tr>

<% } %>

</table>Crear el Fichero Map (Map.java)package email;import java.util.*;

public class Map extends TreeMap {

// In this treemap, name is the key and email is the value

private String name, email, action; private int count = 0;

public Map() { }

public void setName( String formName ) { if ( formName != “” ) { name = formName; } }

public String getName() return name; }

public void setEmail( String formEmail ) { if ( formEmail != “” ) { email = formEmail; System.out.println( name ); // for debugging only


/ 63

u.d. 1 NIVEL II

System.out.println( email ); // for debugging only } }

public String getEmail() { email = get(name).toString(); return email; }

public void setAction( String pageAction ) { action = pageAction; }

public String getAction() { return action; }

}

Manejar Excepciones en el Bean

En este ejemplo, el código que lanza excepciones es la clase TreeMap, que extiende nuestro email.Map, por eso no tenemos que escribir código que lance excepciones en el Bean.

Los métodos que hemos usado de TreeMap son estos con sus excepciones:

•• public Object get( Object key ) throws ClassCastException, NullPointerException- recupera una entrada de un fichero map.

•• public Object put( Object key, Object value ) throws ClassCastException, NullPointe-rException-añade una entrada al fichero map.

•• public Object remove( Object key ) throws ClassCastException, NullPointerException- elimina una entrada del fichero map.

•• int size() - devuelve el número de entradas del fichero map.

Por supuesto, si necesitamos más información sobre estos métodos, podemos buscarlos en el API Javadoc por java.util.TreeMap.

La clase TreeMap lanza una ClassCastException cuando el usuario trata de introducir un dato del tipo erróneo en unf ichero map, por ejemplo, un int donde el fichero map está esperando un String. Tengamos en cuenta que la clase TreeMap también se usa en aplicaciones cliente Java. En nuestra aplicación JSP, esta aplicación no ocurrirá, porque el usuario introduce un nombre y una dirección email en un formulario HTML, que siempre pasa los datos al Bean como strings. Incluso si el usuario teclea 6 como un nombre, el valor envíado es un String.

Sin embargo, los métodos get, put, y remove lanzan una NullPointerException si el usuario no introduce nada o se pasa un valor null al Bean. Esta la excepción más comun que necesita manejar la aplicación email. Esta excepción podría ocurrir siempre que el usuario intente añadir, buscar o eliminar una entrada del fichero map. Recuerda que la clave, (en este caso el nombre) no puede ser null.

Cuando el Usuario Intenta Añadir un Valor Null

El primer caso, cuando el usuario intenta añadir un nombre o dirección de email nulos, es manejado por un sencillo código en el Bean y en email.jsp. (Aquí null significa que el usua-rio no ha introducido nada en la caja de texto del formulario. No maneja el caso en que el usuario teclee uno o dos espacios en blanco, y luego pulsa Return).


/ 64

u.d. 1 NIVEL II

El código que maneja la adicción de valores null está en los métodos setName y setEmail de Map.java y en un scriptlet en email.jsp:

Capturar un Valor Null Durante la Adicción

Map.java:

public void setName( String formName ) { if ( formName != “” ) { name = formName; }}public void setEmail( String formEmail ) { if ( formEmail != “” ) { email = formEmail; System.out.println( name ); // for debugging only System.out.println( email ); // for debugging only } }

email.jsp:

<% String rname = request.getParameter( “name” ); String remail = request.getParameter( “email” ); if ( rname != null) { mymap.put( rname, remail ); }%>

Tanto setName como setEmail chequean su el usuario ha introducido un valor en el formu-lario antes de seleccionar sus respectivas propiedades. Si el formulario es un valor null, el Bean no selecciona ninguna propiedad, el método put no añade nada al fichero map, y no se lanza ninguna excepción.

Cuando el Usuario Intenta Buscar un Valor Null

Pero si vamos a las páginas Lookup o Delete del ejemplo e intentamos buscar o borrar una entrada que no está en el fichero map, la aplicación email lanza una NullPointerException y muestra una página de error.

Capturar un Valor Null durante la Búsqueda

lookup.jsp:

<% if ( request.getParameter( “name” ) != null ) { %> <%@ include file=”lookupresponse.jsp” %><% } %>

lookupresponse.jsp:

<tr><td width=”120”> </td><td align=”right”><font face=”helvetica” size=”-2”><jsp:getProperty name=”mymap” property=”name” /><br><jsp:getProperty name=”mymap” property=”email” /></font></td></tr>


/ 65

u.d. 1 NIVEL II

Este ejemplo tiene dos piezas de código que trabajan juntas. La página lookup.jsp, donde introducimos un nombre por el que queremos buscar en el fichero map, tiene un scriptlet que chequea si el usuario ha introducido un nombre en el formulario o no. Si el usuario no ha introducido un nombre o introduce uno que no existe en el fichero map, el Bean lanza una NullPointerException y la aplicación muestra una página de error -- que es el comportamiento deseado! En este caso, podemos estar felices porque se muestra la página de error.

Podríamos haber observado que las líneas del fichero lookupresponse.jsp usan la etiqueta <jsp:getProperty> para recuperar el nombre y la dirección email desde el Bean. También podríamos intentar recuperar la dirección email usando expresiones, algo como esto:

<%= request.getParameter( “name” ) %><br><%= mymap.get( request.getParameter( “name” ) ) %>

Si usamos estas líneas, el comportamiento de la aplicación sería un poco diferente. En vez de lanzar una NullPointerException y mostrar una página de error, mostraría el nombre que introdujo el usuario, con la palabra null debajo en la página JSP. En la implementación JSP de Sun, la etiqueta <jsp:getProperty> maneja intencionadamente las valores null de forma diferente que los scriptlets o las expresiones. La forma de manejar los valores Null depende del motor JSP utilizado.

Cuando el Usuario Intenta Borrar un Valor Null

Manejar el caso de un usuario que intenta borrar un valor null es muy similar a manejar la búsqueda de un valor null.

Capturar un Valor Null durante el Borrado

delete.jsp:

<% if ( request.getParameter( “name” ) != null ) { %> <%@ include file=”deleteresponse.jsp” %><% mymap.remove( request.getParameter(“name”) ) ; } %>

deleteresponse.jsp:

<tr><td width=”120”> </td><td align=”right”> <font face=”helvetica” size=”-2”> <jsp:getProperty name=”mymap” property=”name” /><br><jsp:getProperty name=”mymap” property=”email” /><br><p>

has been deleted from the map file.

</font> </td></tr>

Escribir un Sencillo Mecanismo de Pila

El ejemplo email usa una propiedad llamada action en Map.java para seguir la página en la que el usuario estaba trabajando cuando se lanzó la excepción. Esto nos da información importante para ayudarnos a escribir un mensaje de error informativo para el usuario. El Bean tiene una variable llamada action, un método getAction, y un método setAction. La declaraciones de variable y métodos en el Bean se parecen a esto:


/ 66

u.d. 1 NIVEL II

private String action;

public void setAction( String pageAction ) { action = pageAction; }

public String getAction() { return action; }

Cada una de las páginas email.jsp, lookup.jsp, y delete.jsp seleccionan el valor de action con una línea como esta (que viene desde email.jsp):

<% mymap.setAction( “add” ); %>

Si ocurre una excepción, error.jsp chequea el valor de action e incluye el mensaje apropiado para cada valor, usando líneas como estas:

<% if (mymap.getAction() == “delete” ) { %>.. text message here ..else if (mymap.getAction() == “lookup” ) { %>.. text message here ..else if (mymap.getAction() == “add” ) { %>.. text message here ..<% } %>

Por supuesto, esta es una forma sencilla de implementar seguimiento. Si nos movemos dentro del desarrollo de aplicaciones J2EE con beans enterprise, podemos escribir aplica-ciones que graben el estado.

¿Cómo ejecuar el Ejemplo?

Para poder ejecutar este ejemplo, necesitamos tener instalado el JDK 1.2 (si no lo tienes, puedes ir a http://java.sun.com/products/OV_jdkProduct.html.)

Los paths dados aquí son para un sistema UNIX, si estás usando Windows, deberás usar los mismos paths pero con el separador de directorios invertido:

1. Creamos el directorio (o carpeta) ../jswdk-1.0/ejemplos/jsp/curso/email.

2. Situamos los siguientes ficheros en el directorio ../curso/email: background.gif, delete.jsp, deleteresponse.jsp, email.jsp, error.jsp, lookup.jsp, lookupresponse.jsp.

3. Creamos el directorio (o carpeta) ../jswdk-1.0/ejemplos/WEB-INF/jsp/beans/email.

4. Situamos los ficheros Map.class y Map.java en el directorio ../beans/email.

5. Arrancamos la implementación de referencia JSP de Sun:cd ../jswdk-1.0startserver

6. Abrimos un navegador Web y vamos a: http://yourMachineName:8080/ejemplos/jsp/curso/email/email.jsp

final de lección

/ 67

!!


Conclusiones:


• Los errores son diferentes de las excepcio-nes. Los errores normalmente indican pro-blemas de enlaces o de la máquina virtual de los que nuestra aplicación Web podría no recuperarse, como errores de memoria. Sin embargo, las excepciones son condiciones que pueden capturarse y recuperarse de ellas.

• Al igual que en una aplicación Java, una excepción es un objeto que es un ejemplar de java.lang.Throwable o de una de sus subclases. Throwable tiene dos subclases estándards -java.lang.Exception, que describe excepciones, y java.lang.Error, que describe errores.

• Las excepciones en tiempo de ejecución son lanzadas por el fichero JSP compilado, el fichero class Java que contiene la versión traducida de nuestra página JSP. Esto signi-fica que nuestra aplicación ha sido compilada y traducida correctamente.

lección 6: Acciones

/ 68

u.d. 1 NIVEL II

LECCION 6: ACCIONES INTRODUCCIÓN Las acciones JSP usan construcciones de sintaxis XML para controlar el comportamiento del motor de Servlets. Podemos insertar un fichero dinámicamente, reutilizar componentes JavaBeans, reenviar al usuario a otra página, o generar HTML para el plug-in Java.

Recuerda que, como en XML, los nombres de elementos y atributos son sensibles a las mayúsculas.

1.1 <JSP:FORWARD> Esta acción se utiliza para redirigir la petición hacia otra página JSP que esté en la misma aplicación web que la actual. Un ejemplo de su sintaxis básica es:

<jsp:forward page=”principal.jsp”/>

La salida generada hasta el momento por la página actual se descarta (se borra el buffer). En caso de que no se utilizara buffer de salida, se produciría una excepción.

Al igual que en el caso de <jsp:include>, se pueden añadir parámetros a la petición ori-ginal para que los reciba la nueva página JSP:

<jsp:forward page=”principal.jsp”> <jsp:param name=”privilegios” value=”root” /></jsp:forward>

1.2 <JSP:INCLUDE>Esta acción incluye en una página la salida generada por otra perteneciente a la misma aplicación web. La petición se redirige a la página incluida, y la respuesta que genera se incluye en la generada por la principal. Su sintaxis es:

<jsp:include page=”URL relativa” flush=”true|false”/>

El atributo flush especifica si el flujo de salida de la página principal debería ser enviado al cliente antes de enviar el de la página incluida. En JSP 1.2 este atributo es optativo, y su valor por defecto es false. En JSP 1.1 es obligatorio y siempre debía valer true (el forzar el vaciado de buffer era problemático porque una vez que ha sucedido esto no se pueden hacer redirecciones ni ir a páginas de error, ya que ya se han terminado de escribir las cabeceras).

Esta acción presenta la ventaja sobre la directiva del mismo nombre de que cambios en la página incluida no obligan a recompilar la “principal”. No obstante, la página incluida solo tiene acceso al JspWriter de la “principal” y no puede generar cabeceras (por ejemplo, no puede crear cookies).

Por defecto, la petición que se le pasa a la página incluida es la original, pero se le pueden agregar parámetros adicionales, mediante la etiqueta jsp:param. Por ejemplo:

<jsp:include page=”cabecera.jsp”><jsp:param name=”color” value=”YELLOW” /></jsp:include>


/ 69

u.d. 1 NIVEL II

1.3 <JSP:PARAM> Esta acción se utiliza en colaboración con cualquiera de las siguientes acciones: <jsp:forward>, <jsp:include> o <jsp:plugin>.

<jsp:param name=”nombreParametro” value=”valorParametro”/>

La acción <jsp:param> permite ofrecer información adicional a otra acción. El siguiente código muestra una página JSP que utiliza la acción <jsp:param> para indicar dos parámetros a la acción <jsp:include>, adelantamos que esta nueva acción incluirá el contenido del recurso indicado en la página actual, formando parte de la respuesta que se devuelve al cliente.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”><html><head><title>Param e include</title></head><body><h3>Página que incluye a otra</h3><jsp:include page=”incluida.jsp” flush=”true”><jsp:param name=”ciudad” value=”Madrid”/><jsp:param name=”domicilio” value=”Alcalá 2”/></jsp:include><h3>Se vuelve a la página de origen</h3></body></html>

El siguiente código muestra la página JSP que se ha utilizado en la acción <jsp:include>, se puede comprobar que para recuperar el valor del parámetro indicado en la acción <jsp:param> se debe utilizar el objewto integrado request, y lanzar sobre él el método getPara-meter(), de las misma forma que hacíamos para obtener los parámetros que se pasaban a una petición de una página JSP.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”><%@ page import=”java.util.*” %><html><head><title>Página incluida</title></head><body>ciudad=<%=request.getParameter(“ciudad”)%><br>domicilio=<%=request.getParameter(“domicilio”)%><br>fecha y hora=<%=new Date()%></body></html>

1.4 <JSP:PLUGIN>Esta acción sirve para incluir, de manera portable e independiente del navegador, applets que utilicen alguna librería de Java 2 (Swing, colecciones, Java 2D, ...), ya que las máquinas virtuales Java distribuidas con algunos navegadores relativamente antiguos (Explorer 5.x, Netscape 4.x,...) son de una versión anterior a Java 2.

1.5 <JSP:USEBEAN> Esta acción nos permite cargar y utilizar un JavaBean en la página JSP. Esta es una capaci-dad muy útil porque nos permite utilizar la reusabilidad de las clases Java sin sacrificar la conveniencia de añadir JSP sobre servlets solitarios. El síntaxis más simple para especificar que se debería usar un Bean es:

<jsp:useBean id=”name” class=”package.class” />


/ 70

u.d. 1 NIVEL II

Esto normalmente significa “ejemplariza un objeto de la clase especificada por class, y únelo a una variable con el nombre especificado por id”. Sin embargo, también podemos especifi-car un atributo scope que hace que ese Bean se asocie con más de una sóla página. En este caso, es útil obtener referencias a los beans existentes, y la acción jsp:useBean especifica que se ejemplarizará un nuevo objeto si no existe uno con el el mismo nombre y ámbito.

Ahora, una vez que tenemos un bean, podemos modificar sus propiedades mediante jsp:setProperty, o usando un scriptlet y llamando a un método explícitamente sobre el objeto con el nombre de la variable especificada anteriormente mediante el atributo id. Recuerda que con los beans, cuando decimos “este bean tiene una propiedad del tipo X llamada foo”, realmente queremos decir “Esta clase tiene un método getFoo que devuelve algo del tipo X, y otro método llamado setFoo que toma un X como un argumento”. La acción jsp:setProperty se describe con más detalle en la siguiente sección, pero ahora observemos que podemos suministrar un valor explícito, dando un atributo param para decir que el valor está derivado del parámetro de la petición nombrado, o sólo lista las propiedades para indicar que el valor debería derivarse de los parámetros de la petición con el mismo nombre que la propiedad. Leemos las propiedades existentes en una expresión o scriptlet JSP llamando al método getXxx, o más comunmente, usando la acción jsp:getProperty.

Observa que la clase especificada por el bean debe estar en el path normal del servidor, no en la parte reservada que obtiene la recarga automática cuando se modifican. Por ejemplo, en el Java Web Server, él y todas las clases que usa deben ir en el directorio classes o estar en un fichero JAR en el directorio lib, no en el directorio servlets.

Aquí tenemos un ejemplo muy sencillo que carga un bean y selecciona y obtiene un sencillo parámetro String.

BeanTest.jsp

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”><HTML><HEAD><TITLE>Usar un JavaBean en JSP</TITLE><LINK REL=STYLESHEET HREF=”Mi-hoja-de-estilos.css” TYPE=”text/css”></HEAD><BODY><CENTER><table BORDER=5> <TR><TH CLASS=”TITLE”> Usar un JavaBean en JSP </table></CENTER><P>

<jsp:useBean id=”test” class=”hall.SimpleBean” /><jsp:setProperty name=”test” property=”message” value=”Hola WWW” /> <H1>Message: <I><jsp:getProperty name=”test” property=”message” /></I></H1> </BODY></HTML>

La forma más sencilla de usar un Bean es usar:

<jsp:useBean id=”name” class=”package.class” />

para cargar el Bean, luego usar jsp:setProperty y jsp:getProperty para modificar y recuperar propiedades del bean. Sin embargo, tenemos dos opciones. Primero, podemos usar un


/ 71

u.d. 1 NIVEL II

formato de contenedor, llamado:

<jsp:useBean ...> Body </jsp:useBean>

Para indicar que la porción Body sólo se debería ejecutar cuando el bean es ejemplarizado por primera vez, no cuando un bean existente se encuentre y se utilice. Como se explica abajo, los bean pueden ser compartidos, por eso no todas las sentencias jsp:useBean resultan en la ejemplarización de un Bean. Segundo, además de id y class, hay otros tres atributos que podemos usar: scope, type, y beanName.

Atributo Uso

id Da un nombre a la variable que referenciará el bean. Se usará un objeto bean anterior en lugar de ejemplarizar uno nuevo si se puede encontrar uno con el mismo id y scope.

class Designa el nombre completo del paquete del bean.

scope Indica el contexto en el que el bean debería estar disponible. Hay cuatro posi-bles valores: page, request, session, y application. El valor por defecto, page, indica que el bean estará sólo disponible para la página actual (almacenado en el PageContext de la página actual). Un valor de request indica que el bean sólo está disponible para la petición actual del cliente (almacenado en el objeto ServletRequest). Un valor de session indica que el objeto está disponible para todas las páginas durante el tiempo de vida de la HttpSession actual. Finalmente, un valor de application indica que está disponible para todas las páginas que compartan el mismo ServletContext. La razón de la importancia del ámbito es que una entrada jsp:useBean sólo resultará en la ejemplarización de un nuevo objeto si no había objetos anteriores con el mismo id y scope. De otra forma, se usarán los objetos existentes, y cualquier elemento jsp:setParameter u otras entradas entre las etiquetas de inicio jsp:useBean y la etiqueta de final, serán ignoradas.

type Especifica el tipo de la variable a la que se referirá el objeto. Este debe corres-ponder con el nombre de la clase o ser una superclase o un interface que imple-mente la clase. Recuerda que el nombre de la variable se designa mediante el atributo id.

b e a n -Name

Da el nombre del bean, como lo suministraríamos en el método instantiate de Beans. Esta permitido suministrar un type y un beanName, y omitir el atributo class.

1.6 <JSP:SETPROPERTY>Usamos jsp:setProperty para obtener valores de propiedades de los beans que se han referenciado anteriormente. Podemos hacer esto en dos contextos. Primero, podemos usar antes jsp:setProperty, pero fuera de un elemento jsp:useBean, de esta forma:

<jsp:useBean id=”myName” ... />...<jsp:setProperty name=”myName” property=”someProperty” ... />

En este caso, el jsp:setProperty se ejecuta sin importar si se ha ejemplarizado un nuevo bean o se ha encontrado uno ya existente. Un segundo contexto en el que jsp:setProperty puede aparecer dentro del cuerpo de un elemento jsp:useBean, de esta forma:

<jsp:useBean id=”myName” ... > ... <jsp:setProperty name=”myName”


/ 72

u.d. 1 NIVEL II

property=”someProperty” ... /></jsp:useBean>

Aquí, el jsp:setProperty sólo se ejecuta si se ha ejemplarizado un nuevo objeto, no si se encontró uno ya existente.

Aquí tenemos los cuatro atributos posibles de jsp:setProperty:

Atributo Uso

name Este atibuto requerido designa el bean cuya propiedad va a ser seleccionada. El elemento jsp:useBean debe aparecer antes del elemento jsp:setProperty.

property Este atributo requerido indica la propiedad que queremos seleccionar. Sin embargo, hay un caso especial: un valor de “*” significa que todos los paráme-tros de la petición cuyos nombres correspondan con nombres de propiedades del Bean serán pasados a los métodos de selección apropiados.

value Este atributo opcional especifica el valor para la propiedad. Los valores string son convertidos automáticamente a números, boolean, Boolean, byte, Byte, char, y Character mediante el método estándard valueOf en la fuente o la clase envolvente. Por ejemplo, un valor de “true” para una propiedad boolean o Boolean será convertido mediante Boolean.valueOf, y un valor de “42” para una propiedad int o Integer será convertido con Integer.valueOf. No podemos usar value y param juntos, pero si está permitido no usar ninguna.

Param Este parámetro opcional designa el parámetro de la petición del que se debería derivar la propiedad. Si la petición actual no tiene dicho parámetro, no se hace nada: el sistema no pasa null al método seleccionador de la propiedad. Así, pode-mos dejar que el bean suministre los valores por defecto, sobreescribiendolos sólo cuando el parámetro dice que lo haga. Por ejemplo, el siguiente código dice “selecciona el valor de la propiedad numberOfItems a cualquier valor que tenga el perámetro numItems de la petición, si existe dicho parámetro, si no existe no se hace nada”

<jsp:setProperty name=”orderBean” property=”numberOfItems” param=”numItems” />

Si omitimos tanto value como param, es lo mismo que si suministramos un nombre de parámetro que corresponde con el nombre de una propiedad. Podremos tomar esta idea de automaticidad usando el parámetro de la petición cuyo nombre corresponde con la pro-piedad suministrada un nombre de propiedad de “*” y omitir tanto value como param. En este caso, el servidor itera sobre las propiedades disponibles y los parámetros de la petición, correspondiendo aquellas con nombres idénticos.

1.7 <JSP:GETPROPERTY> Este elemento recupera el valor de una propiedad del bean, lo convierte a un string, e inserta el valor en la salida. Los dos atributos requeridos son name, el nombre de un bean referen-ciado anteriormente mediante jsp:useBean, y property, la propiedad cuyo valor debería ser insertado. Aquí tenemos un ejemplo:

<jsp:useBean id=”itemBean” ... />...<UL> <LI>Number of items: <jsp:getProperty name=”itemBean” property=”numItems” /> <LI>Cost of each: <jsp:getProperty name=”itemBean” property=”unitCost” /></UL>

final de lección

/ 73

!!


Conclusiones:


• Las acciones JSP usan construcciones de sintaxis XML para controlar el comporta-miento del motor de Servlets. Podemos insertar un fichero dinámicamente, reutilizar componentes JavaBeans, reenviar al usuario a otra página, o generar HTML para el plug-in Java.

/74

JDBC/ u.d. 1 / ejercicios de repasoAA NIVEL II

EJERCICIOS MANUAL CONECTIVIDAD A BBDD CON JAVA1. Crear una página suma.HTML con el siguiente aspecto:

Al introducir dos números y pulsar el botón “Sumar”, genere una página suma.jsp que devuelva los números introducidos y el resultado de la suma.

2. Realizar una página que se llame expresión.jsp que muestre:La fecha actual

El host al que se está conectado

El id de session

3. Realizar una página llamada bgcolor.jsp con fondo blanco y al llamarse a sí misma cambie el color del fondo con el color que le hayamos pasado como parámetro por ejemplo C0C0C0. El objetivo es utilizar los elementos scripting.

4. Realizar una página JSP que muestre las letras del alfabeto en mayúsculas.

5. Realizar una página JSP que envía un correo utilizando la clase JavaMail

6. Realizar un formulario con paginación de registros de la consulta:“select nombre,apellidos from clientes order by des_nombre” suponiendo que tuvieramos un pool de conexiones.

7. Aplicación JSP basada en servletsInicialmente haremos uso de una página JSP que implementa su funcionalidad mediante el uso de servlets. La funcionalidad de la página es extraordinariamente sencilla, limitándose a un formulario en el que el cliente introducirá alguna información, a partir de la cual se generará un nueva página que presenta la información introducida. Para ello, se dispone de dos ficheros:

•• index.jsp: página JSP, con sólo código HTML, que contiene el formulario y la referencia al servlet. Dicha página no contiene código Java, pero requiere el uso de la extensión “.jsp” para que sea gestionada por el contenedor de servlets (lo cual resulta necesario para que se pueda procesar la invocación desde ella al servlet)

•• Saludo.class: código compilado del servlet encargado de recoger (a través de la peti-ción “HttpServletRequest”) la información introducida en el formulario y generar una página HTML de respuesta con esa información.

•• El descriptor de la aplicación (web.xml) deberá contener referencia al servlet empleado. De forma general, la manera de indicar en dicho archivo el uso de un servlet sigue el siguiente formato:

/75

JDBC/ u.d. 1 / ejercicios de repasoAA NIVEL II

web.xml

<servlet><servlet-name>Nombre canonico</servlet-name><servlet-class>paquete.fichero_servlet</servlet-class><init-param><param-name>Nombre_parametro</param-name><param-value>Valor</param-value></init-param><load-on-startup>Numero</load-on-startup></servlet>

donde se tienen los siguientes elementos:

<servlet-name> Nombre canónico que se asigna al servlet.

<servlet-class> Clase que corresponde al servlet.

<init-param> Parámetro opcional que contiene parejas nombre-valor que se asignan al servlet cuando se inicializa.

<load-on-startup> Parámetro opcional que indica el orden en que se deben cargar cada uno de los servlets. Números positivos pequeños indican una carga preferente; un valor negativo o la ausencia de este elemento indica que el servlet puede ser cargado en cualquier momento durante el arranque del contenedor de servlets.

De acuerdo con ello, generamos el fichero “web.xml” necesario para la aplicación, en el cual se distinguen dos partes:

“<servlet>”: Entrada encargada de indicar la posición del servlet sobre el árbol de directorios de la aplicación (posición del fichero .class dentro del directorio “classes”).

“<servlet-mapping>”: Entrada opcional, aunque recomendable, encargada de indicar la URL de acceso al servlet.

/76

JDBC/ u.d. 1 / soluciones NIVEL II

SOLUCIONES MANUAL CONECTIVIDAD A BBDD CON JAVA.Ejercicio 1

Suma.html<html> <head> <title> CALCULADORA </title> </head> <body> <h1> CALCULADORA QUE SUMA DOS NÚMEROS</h1> <form method=”post” action=”suma.jsp” > <p> Introduce el primer número a sumar <input type=”text” name=”sumando1”> <p> Introduce el segundo número a sumar <input type=”text” name=”sumando2”> </p> <p> <input type=”submit” value=”sumar”> </form> </body></html>

Suma.jsp

<html> <head> <title> Resultado de la suma </title> </head>

<body> <h1> Resultado de la suma </h1>

<%@ page import=”java.io.*” %> <% String sumando1, sumando2; sumando1=request.getParameter(“sumando1”); sumando2=request.getParameter(“sumando2”); Integer s1= Integer.valueOf(sumando1); Integer s2= Integer.valueOf(sumando2); int resultado= s1.intValue()+s2.intValue(); out.println(“El primer sumando es “ + sumando1 + “<br>”); out.println(“El segundo sumando es “ + sumando2 + “<br>”); out.println(“El resultado es “ + resultado); %>

</body></html>

Ejercicio 2

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”><HTML><HEAD><TITLE>JSP Expressions</TITLE><META NAME=”autor” CONTENT=”MCP”><META NAME=”keywords”CONTENT=”JSP,expresiones”><META NAME=”descripción”CONTENT=”Ejercicio de expresiones.”><LINK REL=STYLESHEETHREF=”JSP-Styles.css”TYPE=”text/css”>

/77


</HEAD><BODY><H2>Expresiones JSP</H2><UL><LI>Fecha actual: <%= new java.util.Date() %><LI>Nombre del host: <%= request.getRemoteHost() %><LI>Id de sesión: <%= session.getId() %></UL></BODY></HTML>

Ejercicio 3

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”><HTML><HEAD><TITLE>Color Testing</TITLE></HEAD><%String bgColor = request.getParameter(“bgColor”);boolean hasExplicitColor;if (bgColor != null) {hasExplicitColor = true;} else {hasExplicitColor = false;bgColor = “WHITE”;}%><BODY BGCOLOR=”<%= bgColor %>”><H2 ALIGN=”CENTER”>Color Testing</H2><%if (hasExplicitColor) {out.println(“Se ha modificado al color “ +bgColor + “.”);} %></BODY></HTML>

Ejercicio 4

<HTML><HEAD><TITLE>Página simple JSP</TITLE></HEAD><BODY><%// INFORMACION GLOBAL PARA LA PAGINA%><%@ page language=”java” %><% // DECLARACION DE VARIABLES %><% char c = 0;%><%for (int i=0;i < 26;i++){for (j = 0;j < 26;j++){c = (char) (0x41 + (26 – i + j)%26); %><%// IMPRIME LAS LETRAS DEL ALFABETO EN MAYUSCULAS %><%=c%><%}}%></BODY></HTML>

/78


Ejercicio 5

<%@ page language=”java” import=”java.util.*,java.io.*,javax.mail.*,javax.mail.internet.*,javax.activation.*,javax.mail.internet.MimeMultipart.*,java.sql.*,java.util.Properties” %><%! void enviar_correo_texto (String destinatario, String asunto, String mensaje ){try {//establezco las propiedades del correo.Properties props = new Properties();//protocolo smtpprops.setProperty(“mail.transport.protocol”, “smtp”);// servidor web de tu empresa suele ser nombreservidor.dominio.comprops.setProperty(“mail.host”, “host.tuempresa.com”);// usario que envía el correo.props.setProperty(“mail.user”, “cuentacorreo”);// password de la cuenta que envía el correo.props.setProperty(“mail.password”, “password”);Session mailSession = Session.getDefaultInstance(props, null);Transport transport = mailSession.getTransport();MimeMessage message = new MimeMessage(mailSession);String strTipoMsg = “text/html”;message.setSubject(asunto);message.setSentDate( new java.util.Date() );// quien lo enviaInternetAddress addressFrom = newInternetAddress(“[email protected]”);message.setFrom(addressFrom);// destinatariosmessage.addRecipient(Message.RecipientType.TO, newInternetAddress(destinatario));//rellenar el mensajemessage.setContent (mensaje, strTipoMsg);//conexiontransport.connect();//envioTransport.send(message);//adiostransport.close();}catch(Exception e) {e.printStackTrace();};}%><html><body bgcolor=”#FFFFFF” text=”#000000”><% //recoge los parámetrosString v_enviar = request.getParameter(“enviar_ahora”);if (v_enviar == null) v_enviar =””;// si le ha pulsado a enviar envía el mensajeif (v_enviar.equals(“enviar”)) {strDestino = request.getParameter(“destinatario”);strAsunto = request.getParameter(“asunto”);strMensaje = request.getParameter(“mensaje”);enviar_correo_texto(strDestino,strAsunto,strMensaje);}%><form name=”form1” method=”post” action=”estapagina.jsp”><input type=”hidden” name=”enviar_ahora” value=”enviar”><p>Destinatario:

/79


<input type=”text” name=”destinatario” value=””></p><p>Asunto:<input type=”text” name=”asunto” value=””></p><p>Mensaje:<textarea name=”mensaje”>prueba del mensaje</textarea></p><input type=”submit” value=”enviar mensaje”></form></body></html>

Ejercicio 6

<%@ page language=”java” import=”java.sql.*,java.io.*,java.util.*,com.coolservlets.forum.database.*”%><html><head><title>paginacion en JSP</title><body bgcolor=”#FFFFFF”><%int registros = 10;int RegistroActual = 1;String dbURL=”jdbc:oracle:thin:@111.24.80.2:1010:INSTANCIA”;String usuario = “USUARIO”;String pwd = “PWD”;//Class.forName(“oracle.jdbc.driver.OracleDriver”);// Connection cn = DriverManager.getConnection(dbURL,usuario,pwd);// POOL DE CONEXIONESConnection cn = null;cn = DbConnectionManager.getConnection();String LaDireccion = request.getParameter(“Direccion”);if (LaDireccion==null) LaDireccion=””;if ( LaDireccion.equals(“”)) RegistroActual = 1;%><p><%// LOS PARAMETROS DE SIG. O ANT. Y EL REGISTRO ACTUALString empezar = request.getParameter(“Actual”);if (empezar==null) empezar=””;//VARIABLE PARA EL REGISTRO ACTUAL DONDE SE ENCUENTRA// SI SE LE HA PASADO PARAMETRO DE BUSQUEDA SE LE PONE AL RegistroActualif (!(empezar.equals(“”))){if (Integer.parseInt(empezar) <= 0)RegistroActual = 1;elseRegistroActual = Integer.parseInt(empezar);}// *****************************************// SACA EL NUMERO DE REGISTROS DE LA TABLA// *****************************************int intTotalReg = 0;Statement s1 = cn.createStatement();ResultSet rsTotalRegistros = s1.executeQuery(“selectcount(CLIENTES.COD_CLIENTE) AS TOTAL_REGISTROS FROM CLIENTES “ );if (rsTotalRegistros != null){rsTotalRegistros.next();intTotalReg = rsTotalRegistros.getInt(“TOTAL_REGISTROS”);}rsTotalRegistros.close();s1.close();// FIN DEL NUMERO DE REGISTRO DE LA TABLA//***************************************

/80


StringBuffer strsql = new StringBuffer();strsql.append(“ “);strsql.append(“ SELECT NOMBRE,APELLIDOS,DIRECCION FROM CLIENTES “);strsql.append(“ ORDER BY NOMBRE,APELLIDOS “);Statements=cn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);ResultSet rs = s.executeQuery(strsql.toString());if (intTotalReg >0 && (rs.next() || RegistroActual >=1) ){rs.absolute(RegistroActual);if (!rs.isFirst()) rs.previous();int contador = 1;%><table width=”508” border=”0” cellspacing=”1” cellpadding=”3”align=”center”><tr bgcolor=”#0099CC”><td><b>listado de Clientes</b></td></tr><tr bgcolor=”#54DB00”><td><div align=”left”>Nombre</div></td><td><div align=”left”>Apellidos</div></td><td><div align=”left”>Dirección</div></td></tr><%int i =1 ;do {%><tr><td><%=rs.getString(“NOMBRE”)%></td><td> <%=rs.getString(“APELLIDOS”)%></td><td><%=rs.getString(“DIRECCION”)%></td></tr><%if (rs.isLast()) break;i++;contadorr++;} while (i<=registros && rs.next());if (contador == registros)RegistroActual =rs.getRow();elseRegistroActual = rs.getRow() + (registros-contador);%></table><table width=”100%” align=”center” border=”0”><tr align=”center”><% if (RegistroActual <= registros) %><td height=”11”> </td><% else {%><td height=”11”><div align=”right”><ahref=”esta_pagina.jsp?Direccion=ANT&Actual=<%=RegistroActual-19 %>”><-- Anteriores</a> </div></td><% } %><td height=”11”> </td><% if (RegistroActual >= intTotalReg)%><td height=”11”> </td><% else {if (contador >= registros) {%>

/81


<td height=”11”><div align=”left”><ahref=”esta_pagina.jsp?Direccion=SIG&Actual=<%=RegistroActual+1%>”>Siguientes --></a></div></td><%}} %></tr></table><%} elseout.println(“<CENTER>No hay datos en la consulta</CENTER> “);%> </td></tr></table><br><%rs.close();cn.close();%></body></html>

Ejercicio 7

Index.jsp

<HTML><BODY><H1>Ejemplo 1: Página JSP basada en servlets</H1><BR><FORM NAME=”identificacion” ACTION=”servlets/Saludo” METHOD=”post”>¿Cómo te llamas?<BR>Nombre: <INPUT TYPE=”text” NAME=”nombre”><BR><INPUT TYPE=”Submit” NAME=”Enviar”> </FORM></BODY></HTML>

Saludos.java

import java.io.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*; public class Saludo extends HttpServlet { public void init( ServletConfig conf ) throws ServletException { super.init( conf ); } public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException { // Si la petición entra por aquí la reenviamos al método doPost() doPost( req,res ); } public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException { // Recuperamos el nombre del usuario String nombre = req.getParameter( “nombre” ); // Generamos la página de saludo personalizada res.setContentType( “text/html” ); PrintWriter salida = res.getWriter();

/82


salida.println( “<HTML><BODY>” ); salida.println( “<H2>Saludos,</H2>” ); salida.println( “<H1 ALIGN=\”CENTER\”>” + “<FONT COLOR=\”#0000FF\”>” + nombre ); salida.println( “</FONT></H1>” ); salida.println( “</HTML></BODY>” ); } public void destroy() { }}

Resultado de web.xml

<?xml version=”1.0” encoding=”ISO-8859-1”?> <web-app xmlns=”http://java.sun.com/xml/ns/j2ee” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd” version=”2.4”>  <servlet> <servlet-name>Saludo</servlet-name> <servlet-class>Saludo</servlet-class> </servlet>  <servlet-mapping> <servlet-name>Saludo</servlet-name> <url-pattern>/servlets/Saludo</url-pattern> </servlet-mapping> </web-app>

/83

glosario general de términos

GLOSARIOAbstract Windowing Toolkit (AWT).- Biblioteca de módulos para representar interfaces gráficos, provisto por Sun en la API de Java.

Administrador de Seguridad.- Parte de la máquina virtual Java responsable de velar por el cumplimiento de las políticas y reglas de seguridad.

Ámbito.- Parte de un programa en el que es válida una referencia a una variable.

American Standard Code for Information Interchange (ASCII). - Sistema de codificación, que convierte caracteres a números en el rango de 0 a 127. Es una parte del código ANSI, que se amplía hasta los 257 caracteres.

Análisis.- Proceso de conocer los requerimientos de software que tienen el cliente y el usuario final.

API.- Application Programming Interface.

Aplicación.- Programa informático, que se ejecuta sin necesidad de otro programa.

Applet.- Programa informático, que se ejecuta necesitando de otro programa, normalmente un navegador.

Application Programming Interface (API).- Conjunto de paquetes y clases Java, incluidos en el JDK, que utilizan los programadores Java para realizar sus aplicaciones.

Árbol.- Estructura de datos, grafo no cíclico, con forma de árbol (nodos padres e hijos).

Argumentos. - Parámetros.

Array. - Vector.

ASCII. - American Standard Code for Information Interchange.

AWT. - Abstract Windowing Toolkit.

BDK. - Beans Developer Kit.

Beans Developer Kit (BDK).- Conjunto de herramientas para desarrollar JavaBeans.

/84


Bit.- Unidad mínima de información digital, que puede tomar los valores lógicos de 0 ó de 1.

Bloque.- Código localizado entre corchetes.

Boolean.- Tipo de datos bi-estado, que puede tomar valor de cierto (true) o falso (false).

Byte.- Secuencia de 8 bits.

Cadena.- Secuencia de caracteres.

Carácter.- Símbolo que representa información o la codificación en una computadora. Nor-malmente, letras de alfabeto, números o signos ASCII.

Cargador de clases.- Parte del JRE de Java, responsable de encontrar archivos de clase y cargarlos en la máquina virtual Java.

Casting.- Moldeado.

CGI. - Common Gateway Interfaz.

Clase. - Unidad fundamental de programación en Java, que sirve como plantilla para la creación de objetos. Una clase define datos y métodos, y es la unidad de organización básica de un programa Java.

Common Gateway Interfaz (CGI).- Es un lenguaje de programación, que permite dotar a las páginas Web de interactividad, construyendo una página Web correspondiente a un enlace de hipertexto en el mismo momento en que se hace “clic” sobre el enlace. Los script cgi pueden estar escritos en cualquier lenguaje de programación.

Common Object Requeset Broker Architecture (CORBA). - Estándar para la conexión entre objetos distribuidos, aunque estéN codificados en distintos lenguajes.

Compilador.- Programa de software, que traduce código fuente en un lenguaje de pro-gramación legible por una persona a código máquina interpretable por un ordenador.

Constante.- Valor utilizado en un programa de computadoras con la garantía de no cambiar en tiempo de ejecución. La garantía es, a menudo, reforzada por el compilador. En Java las constantes se declaran como static final.

/85


Constructor.- Método que tiene el mismo nombre que la clase que inicia. Toma cero o más parámetros, y proporciona unos datos u operaciones iniciales dentro de una clase, que no se pueden expresar como una simple asignación.

Contenedor.- En diseño de interfaces de usuario, es un objeto que contiene los componentes (como botones, barras de deslizamiento y campos de texto).

Conversión de tipos de datos.- Modificación de una expresión de un tipo de datos a otro.

CORBA. - Common Object Requeset Broker Architecture.

Entero.- Un número entero, sin parte decimal, positivo o negativo.

Estructura de datos.- Una construcción de software (en memoria o en disco duro) que con-tiene datos y las relaciones lógicas entre ellos.

Evento.- Un mensaje que significa un incidente importante, normalmente desde fuera del entorno de software.

Excepción.- Un evento que ocurre durante la ejecución de un programa, que interrumpe el flujo normal de las instrucciones.

Flujo.- Stream.

Graphical User Inteface (GUI).- Interfaz gráfica de usuario.

Hardware.- El aspecto físico de un sistema de computadora, como el procesador, disco duro e impresora.

Herencia múltiple.- La práctica (permitida en lenguajes como C++, pero no en Java) de derivar una clase de más de una clase base.

Herencia.- Mecanismo encargado de relacionar clases entre sí de una manera jerárquica. En Java, sólo existe herencia simple.

Hilo.- Thread.

HTML (HyperText Markup Languaje).- Lenguaje que se utiliza para crear páginas Web. Los programas de navegación de la Web muestran estas páginas de acuerdo con un esquema de representación definido por el programa de navegación.

/86


IDE.- Integral Development Environment.

IDL.- Java Interface Definition Language.

Ingeniería del software.- Rama de la ingeniería concerniente con el análisis, diseño, imple-mentación, prueba, y mantenimiento de programas de computadoras.

Instancia.- Objeto de software construido desde una clase. Por ejemplo, puede tener una clase avión, pero una flota de quince instancias de avión.

Integral Development Enviroment (IDE).- Una herramienta de desarrollo visual en la que un programa puede ser construido, ejecutado y depurado.

Interbloqueo.- Condición en la que dos o más entidades de software se bloquean mutua-mente, cada una esperando los recursos que está utilizando la otra.

Interface Definition Language (IDL).- Herramienta mediante la cual los objetos pueden invocar métodos de otros objetos que se encuentren en máquinas remotas, mediante CORBA.

Interfaz gráfica de usuario (GUI).- Una interfaz entre la máquina y el hombre como el Win-dows de Microsoft, el Mac OS, o el Sistema X Windows, que depende de pantallas de alta resolución, un recurso gráfico de puntero como un ratón y una colección de controles en pantalla (denominados Widgets), que el usuario puede manejar directamente.

Interfaz.- Mecanismo Java para decirle al compilador que un conjunto de métodos serán definidos en futuras clases (esas clases estarán definidas para implementar la interfaz).

Java 2D.- Paquete que permite a los desarrolladores incorporar texto, imágenes y gráficos en dos dimensiones de gran calidad.

Java 3D.- Conjunto de clases para crear aplicaciones y applets con elementos en tres dimen-siones. Es parte del JMF.

Java DataBase Connectivity (JDBC).- Lenguaje estándar de Java para interactuar con bases de datos, similar al SQL. Es independiente no sólo de la plataforma, sino también de la base de datos con que interactúe. Desde la versión 1.2 del JDK se permite interactuar con ODBC.

Java Developer Connection (JDC).- Conexión de desarrollo en la que se publican las ver-siones beta de las bibliotecas de Java que se están desarrollando.

/87


Java Foundation Classes (JFC).- Conjunto de componentes y características para construir programas con interfaces gráficas.

Java Media Framework (JMF).- Protocolo de transmisión de datos para la reproducción multimedia (vídeo y sonido).

Java Native Invocation (JNI).- Capacidad de Java para ejecutar código nativo; es decir, código compilado al lenguaje máquina de un determinado ordenador. Permite a la Máquina Virtual Java (JVM) interactuar con programas o bibliotecas escritos en otros lenguajes (C/C++, ensamblador...). No se puede utilizar en applets, pues viola las directrices de seguridad.

Java Runtime Environment (JRE).- Software suministrado por Sun, que permite a los pro-gramas de Java ejecutarse en una máquina de usuario. El JRE incluye la Máquina Virtual Java (JVM).

JRE.- Java Runtime Environment.

JVM.- Java Virtual Machine.

Java Virtual Machine (JVM).- El intérprete de Java que ejecuta los códigos de byte en una plataforma particular.

JavaBeans.- Paquete que permite escribir componentes software Java, que se puedan incorporar gráficamente a otros componentes.

JDBC.- Java DataBase Connectivity.

JDC.- Java Developer Connection.

JFC.- Java Foundation Classes.

JMF.- Java Media Framewok

JNI.- Java Native Invocation.

JVM.- Java Virtual Machine.

Llamada por referencia.- Una forma de transferir parámetros a una subrutina en la que se pasa un puntero o referencia a un elemento; de esta forma, la subrutina puede leer y cambiar el valor del elemento referenciado.

/88


Llamada por valor.- Una forma de transferir parámetros a una subrutina en la que se pasa la copia del elemento; las modificaciones de la copia no afectan al elemento original.

Método.- Conjunto de sentencias que operan sobre los datos de la clase para manipular su estado.

Miniaplicación.- Applet.

Modelo.- En diseño orientado a objetos, una representación del mundo real en unas abs-tracciones de software denominadas clases y la relación entre ellas.

Moldeado.- Suplantación del tipo de un objeto o variable por otro nuevo tipo.

Multiproceso.- En sistemas operativos, la habilidad de efectuar dos o más programas inde-pendientes, comúnmente en un procesador solo (a través de Multitarea).

Navegador Web.- Software que permite al usuario conectarse a un servidor de Web, utili-zando Hypertext Transfer Protocol (HTTP). Microsoft Internet Explorer, Netscape Navigator, HotJava de Sun, son populares navegadores de Web.

Navegador.- Navegador Web.

null.- Valor de Java que significa vacío.

Object DataBase Conectivity (ODBC). Lenguaje estándar de Microsoft; que utiliza un driver del fabricante de una base de datos, para interactuar con ella, más orientado a C/C++ que a Java.

ODBC.- Object DataBase Conectivity.

Paquete.- Nombre de Java para una biblioteca de clases.

Parámetros formales.- Nombres utilizados dentro de una subrutina por sus parámetros.

Parámetros.- Valores u objetos pasados entre una subrutina y la rutina de llamada.

Plug-in.- Un programa de una plataforma específica, diseñado para ser llamado por un navegador Web. Utilizado con frecuencia para mostrar información que el mismo navega-dor no puede mostrar.

/89


Poliforfismo.- En diseño orientado a objetos, la habilidad de utilizar una clase derivada en lugar de su clase base. Por ejemplo, un programador puede escribir un método expresarse() para la clase Mamífero. Un Perro, una Vaca y un Gato se derivan de Mamífero, y todos pueden expresarse(), aunque sus voces sean bastantes diferentes.

Proceso.- Instancia de un programa ejecutable. Por ejemplo, si inicia dos copias de un intérprete de Java, tiene dos procesos de la máquina virtual de Java, ejecutándose en su computadora.

Seudocódigo.- Documentación de diseño que describe el trabajo de un programa en inglés estructurado (o en otro lenguaje), en lugar de un lenguaje de computadora.

Recolector de basura.- En Java, el mecanismo por el cual se recobra y libera la memoria asociada con objetos no utilizados.

Remote Method Invocation (RMI).- Herramienta que incorpora métodos Java para localizar objetos remotos, comunicarse con ellos e incluso enviar objetos como parámetros de un objeto a otro.

RMI. - Remote Method Invocation.

Secure Sockets Layer (SSL). - Sistema para la creación de conexiones seguras en red.

Servlets.- Módulos que permiten sustituir o utilizar el lenguaje Java en lugar de programas CGI.

Shell.- Intérprete de órdenes de un sistema operativo.

Sistema operativo.- Software responsable de asignar a los usuarios los recursos de sistemas de computadoras (incluyendo procesos). UNIX, Windows, NT y Mac OS, son ejemplos de sistemas operativos.

SQL. - Structured Query Language.

SSL. - Secure Sockets Layer.

Estático.- En diseño orientado a objetos, representa la pertenencia a la clase, en vez de a una instancia. Es un espacio compartido por todas las instancias de una clase.

Stream.- Flujo de datos. Por ejemplo las entradas y salidas de un programa.

/90


String.- Objeto Java estandarizado en el lenguaje, que representa una cadena de caracte-res.

Structured Query Language (SQL).- Lenguaje para realizar consultas a Bases de Datos relacionales.

Subclase.- Clase descendiente de otra clase de la que hereda métodos y variables.

Superclase.- Clase de la cual heredan sus métodos y variables otras clases denominadas subclases.

Swing.- Paquete que permite incorporar elementos gráficos en las aplicaciones, de una manera más potente que con el AWT. Aparece en la versión 1.2 del JDK. Es uno de los componentes que están incluidos en las Java Fundation Classes, o JFC.

Thread.- Un “proceso ligero” que puede ser arrancado y utilizado más rápidamente que por un fork o spawn. Véase también: fork, spawn y Proceso.

Tiempo de vida.- El número de líneas sobre las que una variable es activa; esto es, el número de líneas entre la primera y la última referencia a la variable.

Tipo primitivo.- En Java, un tipo de dato que no es un objeto. Los tipos primitivos incluyen caracteres, enteros, número de coma flotante y booleanos.

UML. - Unified Modeling Language.

Unicode. - Conjunto de caracteres de 16 bits, en lugar de los 8 que soportaba ASCII. Así, se pueden representar la mayor parte de los lenguajes del mundo.

Unified Modeling Language (UML).- Notación estándar de facto, utilizada en el análisis y diseño orientado a objetos, basado en el trabajo de Grady Booch, James Rumbaugh, e Ivar Jacobson.

Vector.- Estructura de datos que coloca un tipo de datos en celdas continuas.

Verificador de código de byte.- Rutinas en la máquina virtual de Java, que aseguran que las instrucciones en el archivo de clase no violan ciertas restricciones de seguridad.

Garben Proyectos: C/ General Pardiñas 112 bis 1º A. Madrid.Garben Consultores: C/ Claudio Coello 124. Madrid.

619 javaserver pages

Documents