|
Buscador
Secciones
Otras zonas
Foros
Ganamos
Registro
|
Inicio > Tutoriales > Lenguajes orientados a objeto > Servidores de Aplicaciones Java > BEA WebLogic: Guía de Administración
|
|
Nota:
Los ficheros JSP se redespliegan automáticamente sólo en el Servidor de Administración. Si queremos que los JSPs sean re-desplegados en el servidores controlados dirigos por la Aplicación Web, debemos re-desplegar la Aplicación Web (ver más abajo). |
Re-Desplegar una Aplicación WebUsamos uno de estos tres procedimientos para re-desplegar una Aplicación Web:
|
Nota:
Re-desplegar una Aplicación Web, también la re-despliega a todos los servidores controlados dirigidos por esta Aplicación Web. |
Desplegar Aplicaciones Web como parte de una Aplicación EnterprisePodemos desplegar una Aplicación Web como parte de una Aplicación Enterprise. Una Aplicación Enterprise es una unidad de despliegue J2EE que empaqueta juntas Aplicaciones Web, EJBs y Adaptadores de Recursos en una sóla unidad desplegable. Si desplegamos una Aplicación Web como parte de una Aplicación Enterprise, podemos especificar un string que se usa en lugar del nombre real de la Aplicación Web cuando el Servidor WebLogic sirve una petición para la Aplicación Web. Especificamos el nuevo nombre con el elemento <context-root> en el descriptor de despliegue application.xml para la Aplicación Enterprise.
Por ejemplo, para una Aplicación Web llamada oranges, normalmente solicitaríamos un recurso de esa Aplicación Web con una URL como esta:
http://host:port/oranges/catalog.jsp
Si la Aplicación Web oranges se empaqueta en una Aplicación Enterprise, podemos especificar un valor para el <context-root> como se ve en el siguiente ejemplo:
<module> <wedestacar> <web-uri>oranges.war</web-uri> <context-root>fruit</context-root> </wedestacar> </module>
Entonces usaríamos la siguiente URL para acceder al mismo recurso de la Aplicación Web oranges:
http://host:port/fruit/catalog.jsp
URIs y Aplicaciones WebConstruirmos la URL usada para acceder a una Aplicación Web desde un cliente usando el siguiente patrón:
http://hoststring/ContextPath/servletPath/pathInfo
donde:
Si estamos usando hosting virtual, podemos sustituir el nombre del host vrital por la porción hoststring de la URL.
Configurar ServletsLos Servlets se registran o configuran como una parte de una Aplicación Web. Para registrar un servlet, añadimos varias entradas al descriptor de despliegue de la Aplicación Web. La primera entrada bajo, el elemento <servlet> define el nombre del servlet y la clase compilada que ejecuta el servlet. Este elemento también contiene definiciones para los parámetros de inicialización y roles de seguridad del servlet. La segunda entrada, bajo el elemento <servlet-mapping> define el patrón URL que llama este servlet.
Mapeo de ServletsEl mapeo de Servlets controla el modo en que accedemos a un servlet. Los siguientes ejemplo, demuestran algunas de las formas que podemos usar para mapear servlets en nuestra aplicación Web.
<servlet> <servlet-name>watermelon</servlet-name> <servlet-class>myservlets.watermelon</servlet-class> </servlet> <servlet> <servlet-name>garden</servlet-name> <servlet-class>myservlets.garden</servlet-class> </servlet> <servlet> <servlet-name>list</servlet-name> <servlet-class>myservlets.list</servlet-class> </servlet> <servlet> <servlet-name>kiwi</servlet-name> <servlet-class>myservlets.kiwi</servlet-class> </servlet> <servlet-mapping> <servlet-name>watermelon</servlet-name> <url-pattern>/fruit/summer/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>garden</servlet-name> <url-pattern>/seeds/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>list</servlet-name> <url-pattern>/seedlist</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>kiwi</servlet-name> <url-pattern>*.abc</url-pattern> </servlet-mapping>
| URL | Servlet invocado |
|---|---|
| http://host:port/mywebapp/fruit/summer/index.html | watermelon |
| http://host:port/mywebapp/fruit/summer/index.abc | watermelon |
| http://host:port/mywebapp/seedlist | list |
| http://host:port/mywebapp/seedlist/index.html | El Servlet por defecto, si está configurado, o un mensaje de error HTTP 404 file not found.
Si el mapeo para el servlet list había sido /seedlist*, se llamará al servlet list. |
| http://host:port/mywebapp/seedlist/pear.abc | kiwi
Si el mapeo para el servlet list había sido /seedlist*, se llamará al servlet list. |
| http://host:port/mywebapp/seeds | garden |
| http://host:port/mywebapp/seeds/index.html | garden |
| http://host:port/mywebapp/index.abc | kiwi |
Parámetros de Inicialización de ServletsDefinimos los parámetros de inicialización para los servlets en el descriptor de despliegue de la Aplicación Web, en el elemento <init-param> del elemento <servlet>, usando etiquetas <param-name> y <param-value>. Por ejemplo, el siguiente listado de configuración de los parámetros de inicialización de Servlets:
Tutoriales
<servlet>
<servlet-name>HelloWorld2</servlet-name>
<servlet-class>examples.servlets.HelloWorld2</servlet-class>
<init-param>
<param-name>greeting</param-name>
<param-value>Welcome</param-value>
</init-param>
<init-param>
<param-name>person</param-name>
<param-value>WebLogic Developer</param-value>
</init-param>
</servlet>
Configurar JSPDesplegamos los ficheros JSP situándolos en la raíz (o en un subdirectorio bajo la raíz) de una Aplicación Web. Los parámetros de configuración adicionales para JSP están definidos en el elemento <jsp-descriptor> del descriptor de despliegue específico de WebLogic, weblogic.xml. Estos parámetros definen las siguientes funcionalidades:
Configurar Librerías de Etiquetas JSPWeblogic Server, en concordancia con la especificación Servlet 2.2 proporciona la habilidad de crear y usar etiquetas JSP personalizadas. Estas etiquetas son clases Java que pueden ser llamadas desde dentro de un página JSP. Para crear etiquetas JSP personalizadas, las situamos en una librería de etiquetas y definimos su comportamiento en un descriptor de librería de etiquetas (TLD). Este TLD debe estar disponible para la Aplicación Web que contiene el JSP definiéndolo en el descriptor de despliegue de la Aplicación Web. Es una buena idea situar el fichero TLD en el directorio WEB-INF de nuestra Aplicación Web, porque este directorio nunca está disponible públicamente.
En el descriptor de despliegue de la Aplicación Web, definimos un patrón URI para la librería de etiquetas. Este patrón URI debe corresponder con al valor de la directiva taglib en nuestras páginas JSP. También definimos la localización del TLD. Por ejemplo, si la directiva taglib en la página JSP es:
<%@ taglib uri="myTaglib" prefix="taglib" %>
y el TLD está localizado en el directorio WEB-INF de nuestra Aplicación Web, podríamos crear la siguiente entrada en el descriptor de despliegue de la Aplicación Web:
<taglidestacar> <taglib-uri>myTaglib</taglib-uri> <tablig-location>WEB-INF/myTLD.tld</taglib-location> </taglidestacar>
WebLogic Server también incluye muchas etiquetas JSP personalizadas que podemos usar en nuestras aplicaciones. Estas etiquetas realizan cacheo, facilitan la consulta de control de flujo basado en parámetros, y facilitan la iteración sobre conjuntos de objetos.
Configurar Páginas de BienvenidaWebLogic Server nos permite seleccionar una página que es servida por defecto si la URL solicitada es un directorio. Esta característica puede hacer nuestra site más fácil de usar, porque el usuario puede teclear una URL sin dar un nombre de fichero específico.
Las páginas de bienvenida se definen a nivel de Aplicación Web. Si nuestro servidor está hospedando varias Aplicaciones Web, necesitamos definir páginas de bienvenida separadas para cada Aplicación Web.
Para definir las páginas de bienvenida, editamos el descriptor de despliegue de la Aplicación Web, web.xml. Si no definimos nuestra página de bienvenida, el Servidor WebLogic buscará los siguientes ficheros en el siguiente orden y servirá el primero que encuentre:
Seleccionar un Servlet por DefectoCada Aplicación Web tiene un Servlet por defecto. Este servlet puede ser un servlet que especifiquemos nosotros, o, si no lo especificamos, el Servidor WebLogic usa un servlet interno llamado FileServlet como servlet por defecto. Para más información puedes ver Como Resuelve las Peticiones HTTP el Servidor WebLogic.
Podemos registrar cualquier servlet como servlet por defecto. Escribir nuestro propio servlet por defecto nos permite usar nuestra propia lógica para decidir cómo manejar una petición que cae dentro del servlet por defecto.
Seleccionar un servlet por defecto reemplaza el FileServlet y debería hacerse cuidadosamente, porque FileServlet se usa para servir la mayoría de los ficheros, como ficheros de texto, HTML, imágenes, etc. Si esperamos que nuestro servlet por defecto sirva dichos ficheros, necesitaremos escribir esa funcionalidad en nuestro servlet por defecto.
Para seleccionar un servlet por defecto definido por el usuario:
Cómo Resuelve WebLogic Server Peticiones HTTPCuando WebLogic Server recibe una petición HTTP, la resuelve analizando las distintas partes de la URL y usando esta información para determinar qué aplicación Web o servidor debería manejarla. Abajo tenemos varios ejemplos de combinaciones de peticiones para Aplicaciones Web, host virtuales, servlets, JSPs y ficheros estáticos y el respuesta resultante.
|
Nota:
Si empaquetamos nuestra Aplicación Web como parte de una Aplicación Enterprise podemos proporcionar un nombre alternativo para una Aplicación Web que se usa para resolver la petición hacia la Aplicación Web. Puedes encontrar más información en Desplegar Aplicaciones Web como parte de una Aplicación Enterprise. |
La siguiente tabla proporciona algunos ejemplos de URLs y los ficheros servidos por el Servidor WebLogic. La columna "Index Directories Checked " se refiere al atributo Index Directories que controla si se ofrece un listado de directorio si no se solicita ningún fichero específicamente. Seleccionamos Index Directories usando la Consola de Administración, sobre el nodo Web Applications, bajo la pestaña Configuration/Files.
| URL | Index
Directories Checked? |
Fichero servidor en la respuesta |
|---|---|---|
| http://host:port/apples | no | Fichero de bienvenida definido en la aplicación Web apples |
| http://host:port/apples | si | Listado del directorio de nivel superior de la aplicación Web apples. |
| http://host:port/oranges/naval | no importa | El Servlet mapeado con <url-pattern> de /naval en la aplicación web oranges |
| http://host:port/naval | ni importa | El Servlet mapeado con <url-pattern> de /naval en la aplicación web oranges y esta aplicación está definida como aplicación web por defecto. |
| http://host:port/apples/pie.jsp | no importa | pie.jsp, del directorio de más alto nivel de la aplicación apples. |
| http://host:port | si | Listado del directorio de nivel superior de la aplicación web por defecto. |
| http://host:port | no | Fichero de bienvenida de la aplicación web por defecto. |
| http://host:port/apples/myfile.html | no importa | myfile.html, del directorio de nivel superior de la aplicación web apples. |
| http://host:port/myfile.html | no importa | myfile.html, del directorio de nivel superior de la aplicación web por defecto. |
| http://host:port/apples/images/red.gif | no importa | red.gif, del subdirectorio images del directorio de más alto nivel de la aplicación web apples |
| http://host:port/myFile.html
donde myfile.html no existe en la aplicación web apples y no se ha definido un servlet por defecto |
no importa | Error 404 |
| http://www.fruit.com/ | no | Fichero de bienvenida de la aplicación web por defecto para un host virtual con el nombre de host www.fruit.com. |
| http://www.fruit.com/ | si | Listado del directorio del nivel superior de la aplicación web por defecto de un host virtual con el nombre www.fruit.com. |
| http://www.fruit.com/oranges/myfile.html | no importa | myfile.html, de la aplicación web oranges que está dirigia a un host virtual con el nombre www.fruit.com. |
Personalizar Respuestas de Error HTTPPodemos configurar WebLogic Server para responder con nuestras páginas Web personalizadas u otros recursos HTTP cuando ocurre un error HTTP o una excepción Java particular, en lugar de responder con las páginas de respuesta de error estándars de WebLogic Server.
Definimos las páginas de error personalizadas en el elemento <error-page> del descriptor de despliegue de la Aplicación Web (web.xml).
Usar CGI con WebLogic ServerWebLogic Server proporciona funcionalidades para soportar nuestros scripts Common Gateway Interface (CGI). Para nuevos proyectos, sugerimos usar Servlets HTTP o JavaServer Pages.
WebLogic Server soporta todos los CGI mediante un servlet interno de WebLogic llamado CGIServlet.TouseCGI, registrando el CGIServlet en el descriptor de despliegue de la Aplicación Web.
Configurar WebLogic Server para usar CGIPara configurar CGI en WebLogic Server:
Entradas de ejemplo incluidas en el descriptor de despligue de la aplicación Web cuando se registra CGIServlet:
<servlet>
<servlet-name>CGIServlet</servlet-name>
<servlet-class>weblogic.servlet.CGIServlet</servlet-class>
<init-param>
<param-name>cgiDir</param-name>
<param-value>
/bea/wlserver6.0/config/mydomain/applications/myWebApp/cgi-bin
</param-value>
</init-param>
<init-param>
<param-name>*.pl</param-name>
<param-value>/bin/perl.exe</param-value>
</init-param>
</servlet>
...
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>
Solicitar un Script CGILa URL usada para solicitar un script perl debe seguir el patrón:
http://host:port/myWebApp/cgi-bin/myscript.pl
donde:
Servir Recursos del Classpath con el ClasspathServletSi necesitamos servir clases u otros recursos desde el CLASSPATH del sistema, o desde el directorio WEB-INF/classes de la aplicación Web, podemos usar un servlet especial llamado ClasspathServlet. Este servlet es útil para aplicaciones que usan applets o clientes RMI y requieren acceder a clases del lado del servidor. ClasspathServlet está registrado implícitamente y está disponible desde cualquier aplicación.
Hay dos formas en las que podemos usar ClasspathServlet:
http://server:port/classes/my/resource/myClass.class
http://server:port/myWebApp/classes/my/resource/myClass.class
En este caso, el recurso está localizado en el siguiente directorio, en relación a la raíz de la aplicación Web:
WEB-INF/classes/my/resource/myClass.class
|
Aviso:
Como ClasspathServlet sirve cualquier recurso localizado en el CLASSPATH del sistema, no deberíamos situar recursos que no deberían estár disponibles públicamente en el CLASSPATH del sistema. |
Pasar Peticiones a otro Servidor WebLogicCuando usamos WebLogic Server como nuestro servidor Web principal, también podríamos querer configurarlo para pasar (actuar como proxy) ciertas peticiones a un servidor HTTP secundario, como Netscape Enterprise Server, Apache, o Microsoft Internet Information Server. Cualquier petición proxy es redirigida a una URL específica. Incluso podemos pasarla a otro servidor Web en una máquina diferente. Nuestras peticiones proxy se basan en la URL de la petición entrante.
El HttpProxyServlet (proporcionado como parte de la distribución) toma una petición HTTP, la redirige a la URL proxy, y envía la respuesta de vuelta al cliente a través del Servidor WebLogic. Para usar el proxy, debemos configurarlo en una Aplicación Web y desplegar esa Aplicación Web sobre el Servidor WebLogic que está redirigiendo las peticiones.
Seleccionar un Proxy a un Servidor HTTP SecundarioPara seleccionar un proxy a un servidor HTTP secundario:
Si seleccionamos <url-pattern> a “/”, entonces cualquier petición que no pueda ser resuelta por el Servidor WebLogic será pasara al servidor remoto. Sin embargo, también debemos mapear específicamente las extensiones *.jsp, *.html, y *.html si queremos pasar los ficheros que terminan en estas extensiones.
Ejemplo de web.xml para usar con ProxyServletLo siguiente es un ejemplo de un descriptor de despliegue de una Aplicación Web para usar el ProxyServlet:
<!-- DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 1.2//EN"
"file:///weblogic/dev/myserver/servlet2.2/WEB-INF/web-jar.dtd"
-->
<web-app>
<servlet>
<servlet-name>ProxyServlet</servlet-name>
<servlet-class>weblogic.t3.srvr.HttpProxyServlet</servlet-class>
<init-param>
<param-name>redirectURL</param-name>
<param-value>
tehama1:7736:7737|tehama2:7736:7737|tehama:7736:7737
</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>
Pasar Peticiones (proxy) a un Cluster WebLogicEl HttpClusterServlet (proporcionado con la distribución de WebLogic Server) pasa peticiones desde un servidor WebLogic a otros servidores WebLogic en un Cluster WebLogic. HttpClusterServlet proporciona balance de carga y proteción de fallos para las peticiones HTTP pasadas.
Configurar el HttpClusterServletPara configurar el HttpClusterServlet:
El nombre de la clase para HttpClusterServlet es weblogic.servlet.internal.HttpClusterServlet.
Si seleccionamos <url-pattern> a “/”, entonces cualquier petición que no pueda ser resuelta por el Servidor WebLogic será pasada al servidor remoto. Sin embargo, también debemos mapear específicamente las extensiones *.jsp, *.html, y *.html si queremos pasar los ficheros que terminan en estas extensiones.
Otra forma de configurar el url-pattern es mapear un url-pattern como /foo y luego configurar el parámetro pathTrim como foo, lo que elimina foo de la URL pasada (proxy).
| <param-name> | <param-value> | Valor por
Defecto |
|---|---|---|
| defaultServers | (Requirido) Una lista de nombres de host y números de puertos de los servidores a los que estámos pasando las peticiones en la forma:
host1:HTTP_Port:HTTPS_Port| host2:HTTP_Port:HTTPS_Port(donde host1 y host2 son los nombres de host de los servidores en el cluster, HTTP_Port es el puerto donde el host está escuchando peticiones HTTP, y HTTPS_Port es el puerto donde el host escucha peticiones HTTP SSL). Separando cada host con un carácter |. Si selecionamos el parámetro secureProxy a ON, el puerto HTTPS usa SSL entre el Servidor WebLogic que ejecuta HttpClusterServlet y los servidores WebLogic del Cluster. Siempre debemos definir un puerto HTTPS, incluso si tenemos secureProxy a OFF. |
Ninguno |
| secureProxy | ON/OFF. Si selecciona a ON, permite SSL entre el HttpClusterServlet y los miembros de un Cluster de Servidores WebLoigc. | OFF |
| DebugConfigInfo | ON/OFF. Si se selecciona a ON, podemos consultar información de depuración del HttpClusterServlet añadiendo un parámetro ?_WebLogicBridgeConfig a cualquier petición.
Por razones de seguridad, se recomienda tener este parámetro a OFF en entornos de producción. |
OFF |
| connectionTimeout | La cantidad de tiempo, en segundos, que un socket espera entre lecturas de bloques de datos. Si el tiempo expira, se lanza una java.io.InterruptedIOException. | 0 = infinito |
| numOfRetries | Número de intentos que hace HttpClusterServlet para recuperar una conexión fallida. | 5 |
| pathTrim | String a recortar del principio de la URI original. | ninguna |
| trimExt | La extensión de fichero a recortar del final de la URI. | Ninguna |
| pathPrepend | String a añadir al principio de la URL orginal, después de que se haya recortado pathTrim, y antes de que la petición sea reenviada al miembro del cluster de servidores WebLogic. | Ninguna |
Ejemplo de Descriptor de Despliegue para HttpClusterServletLo siguiente es un ejemplo de un descriptor de despliegue de una Aplicación Web para usar el HttpClusterServlet:
<!-- DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 1.2//EN"
"file:///weblogic/dev/myserver/servlet2.2/WEB-INF/web-jar.dtd"
-->
<web-app>
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>
weblogic.servlet.internal.HttpClusterServlet
</servlet-class>
<init-param>
<param-name>defaultServers</param-name>
<param-value>
myserver1:7736:7737|myserver2:7736:7737|myserver:7736:7737
</param-value>
</init-param>
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ON</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>
Configuar la Seguridad en Aplicaciones WebPodemos asegurar una Aplicación Web usando autentificación, mediante la restricción de acceso a ciertos recursos en la Aplicación Web, o usando llamadas de seguridad a nuestro código Servlet. Se pueden usar varios reinos de seguridad.
Configurar la Autentificación para Aplicaciones WebDefinimos la autentificación para Aplicaciones Web en el descriptor de despliegue de la Aplicación Web, usando el elemento <login-config>. En este elemento definimos los reinos de seguridad conteniendo credenciales de usuario, el método de autentificación, y la localización de los recursos para autentificación.
Para configurar la autentificación para Aplicaciones Web:
<form method=”POST” action=”j_security_check”> <input type=”text” name=”j_username”> <input type=”password” name=”j_password”> </form>
El recurso usado para generar el formulario HTML podría ser una página HTML, un JSP o un Servlet. Definimos este recurso con el elemento <form-login-page>.
El objeto sesión HTTP se crea cuando se sirve la página logín. Por lo tanto, el método session.isNew() devolverá FALSE cuando se llame desde páginas servidas después de que la autentificación tenga éxito.
Múltiples Aplicaciones Web, Cookies y AutentificaciónPor defecto, WebLogic Server asigna el mismo nombre de cookie (JSESSIONID) para todas las aplicaciones Web. Cuando usamos cualquier tipo de autentificación, todas las aplicaciones Web que usan el mismo nombre de cookie usan una sóla firma para autentificación. Una vez que un usuario se ha autentificado, esa autentificación será válida para peticiones de cualquier aplicación Web que use el mismo nombre de cookie. No se le pedirá al usuario que vuelva a autentificarse.
Si queremos requerir autentificación separada para una Aplicación Web, podemos especificar un nombre de cookie distinto para la Aplicación Web. Podemos hacer esto usando el parámetro CookieName, definido en el descriptor de despliegue específico de WebLogic, weblogic.xml, en el elemento <session-descriptor>.
Restringir el Acceso a Recursos de una Aplicación WebPodemos aplicar restricciones a recursos específicos (servlets, JSPs, o páginas HTML) de nuestra aplicación Web. Para aplicar restricciones de seguridad:
<url-pattern>/*</url-pattern>
Código de ejemplo:
Entradas en web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>SecureOrdersEast</web-resource-name>
<description>
Security constraint for resources in the orders/east directory
</description>
<url-pattern>/orders/east/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>constraint for east coast sales</description>
<role-name>east</role-name>
<role-name>manager</role-name>
</auth-constraint>
<user-data-constraint>
<description>SSL not required</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
...
<security-role>
<description>east coast sales</description>
<role-name>east</role-name>
</security-role>
<security-role>
<description>managers</description>
<role-name>manager</role-name>
</security-role>
Entradas en weblogic.xml:
<security-role-assignment>
<role-name>east</role-name>
<principal-name>tom</principal-name>
<principal-name>jane</principal-name>
<principal-name>javier</principal-name>
<principal-name>maria</principal-name>
</security-role-assignment>
<security-role-assignment>
<role-name> manager </role-name>
<principal-name>peter</principal-name>
<principal-name>georgia</principal-name>
</security-role-assignment>
Usar Usuarios y Roles Programáticamente en ServletsPodemos escribir nuestros servlets para acceder programáticamente a usuarios y roles en nuestro código de servlet usando el método javax.servlet.http.HttpServletRequest.isUserInRole(String role).
El string role es mapeado al nombre suministrado en el elemento <role-name> que está anidado dentro del elemento <security-role-ref> de una declaración <servlet> en el descriptor de despliegue de la aplicación. El elemento <role-link> se mapea a un <role-name> definido en el elemento <security-role> del descriptor de despliegue de la aplicación Web.
Por ejemplo:
Código Servlet:
isUserInRole("manager");
Entradas en web.xml:
<servlet>
...
<role-name>manager</role-name>
<role-link>mgr</role-link>
...
</servlet>
<security-role>
<role-name>mgr</role-name>
</security-role>
Entradas en weblogic.xml:
<security-role-assignment>
<role-name>mgr</role-name>
<principal-name>al</principal-name>
<principal-name>george</principal-name>
<principal-name>ralph</principal-name>
</security-role-ref>
Configurar Recursos Externos de una Aplicación WebCuando accedemos a recursos externos, como una DataSource desde una Aplicación Web mediante JNDI, podemos mapear el nombre JNDI que buscamos en nuestro código al nombre JNDI real unido en el árbol JNDI. Este mapeo se hace usando los dos descriptores de despliegue web.xml y weblogic.xml y nos permite cambiar estos recursos sin tener que modificar el código de nuestra aplicación. Proporcionamos un nombre que se usa en nuestro código Java, el nombre del recurso que está unido al árbol JNDI, y el tipo Java del recurso, e indicamos si la seguridad del recurso se maneja programáticamente por el servlet o desde las credenciales asociadas con la petición HTTP.
Para configurar recursos externos:
El siguiente ejemplo asume que hemos definido una fuente de datos llamada accountDataSource:
Código del Servlet:
javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup
("myDataSource");
Entradas en web.xml:
<resource-ref>
...
<res-ref-name>myDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
...
</resource-ref>
Entradas en weblogic.xml:
<resource-description>
<res-ref-name>myDataSource</res-ref-name>
<jndi-name>accountDataSource</jndi-name>
</resource-description>
Referenciar EJBs en una Aplicación WebReferenciamos EJBs en una aplicación Web dándoles un nombre en el descriptor de despliegue de la aplicación Web que es mapeado al nombre JNDI para el EJB que está definido en el fichero descriptor de despliegue weblogic-ejb-jar.xml.
Para configurar EJBs para usarlos en una Aplicación Web:
Si la Aplicación Web es parte de un Enterprise Application Archive (fichero *.ear), podemos referenciar un EJB por el nombre usado en el .ear con el elemento <ejb-link>.
Configurar el Manejo de SesiónWebLogic Server está configurado para manejar el seguimiento de sesión por defecto. No necesitamos configurar ninguna de estas propiedades para usar seguimiento de sesión. Sin embargo, configurar el modo en que WebLogic Server maneja las sesiones es una parte importante del ajuste de nuestra aplicación para un mejor rendimiento.
El ajuste depende de factores como:
Propiedades de Sesión HTTPConfiguramos WebLogic Server para que haga seguimiento de sesión con las propiedades del descriptor de despliegue específico de WebLogic, weblogic.xml.
Puedes encontrar una lista completa de atributos de sesión en http://e-docs.bea.com/wls/docs60/programming/weblogic_xml.html#session-descriptor.
TimeOut de SesiónPodemos especificar un intervalo de tiempo después del cual expiran las sesiones HTTP. Cuando una sesión expira, todos los datos almacenados en la sesión son descartados. Podemos seleccionar el intervalo de una de estas formas:
Configurar Cookies de SesiónWebLogic Server usa cookies para manejo de sesiones cuando lo soporta el navegador del cliente.
Las cookies que usa WebLogic Server para seguir la sesión son temporales por defecto y no sobreviven a la vida del navegador. Cuando un usuario cierra su navegador, las cookies se pierden y se acaba el tiempo de la sesión. Este comportamiento está en el espiritu del uso de la sesión y se recomienda que usemos las sesiones de esta forma.
Es posible configurar muchos aspectos de las cookies usadas para seguimiento de sesión con atributos definidos en el descriptor de despliegue específico de WebLogic. Puedes encontrar una lista completa de atributos relacionados con la sesión y las cookies en http://e-docs.bea.com/wls/docs60/programming/weblogic_xml.html#session-descriptor.
Usar Cookies de Larga VidaPara datos de usuario de larga vida en el lado del cliente, nuestra aplicación debería crear y configurar sus propias cookies en el navegador mediante el API servlet HTTP, y no deberíamos intentar usar las cookies asociadas con la sesión HTTP. Nuestra aplicación podría usar cookies para auto-login un usuairo desde una máquina particular, en cuyo caso configuraríamos una nueva cookie con un largo tiempo de caducidad. Recuerda que la cookie sólo puede ser enviada desde la máquina del cliente. Nuestra aplicación debería almacenar los datos en el servidor si debe ser accedida por el usuario desde múltiples localizaciones.
No podemos conectar directamente la edad de un cookie de navegador con la longitud de una sesión. Si una cookie expira antes de su sesión asociada, esta sesión se vuelve huerfana. Si una sesión expira antes que su cookie asociada, el servler no podrá encontrar una sesión. En este punto, se asinga una sesión cuando se llama al método getSession(). Sólo deberíamos hacer un uso temporal de las sesiones.
Configurar la Persistencia de SesiónHay cuatro diferentes implementaciones de persistencia de sesión:
Las tres primeras se cubren aquí; la replicación en memoria se cubre en http://e-docs.bea.com/wls/docs60/cluster/servlet.html.
Para la replicación en memoria, fichero, y JDBC, necesitamos configurar atributos adicionales, incluyendo PersistentStoreType. Cada método tiene su propio conjunto de propiedades mostradas abajo:
Propiedades ComunesPodemos configurar el número de sesiones que mantenemos en memoria configurando los siguientes atributos en el descriptor de despliegue específico de WebLogic. Estos atributos sólo són aplicables si estámos usando persistencia de sesión:
Usar Persistencia Basada en Memoria en un Sólo Servidor y no ReplicadaPara usar este tipo de persistencia, seleccionamos la propiedad PersistentStoreType a memory. Cuando usamos el almacenamiento basado en memoria toda la información de sesión se almacena en memoria y se pierde cuando paramos e reiniciamos el Servidor WebLogic.
Usar Persisentica Basada en FicheroPara el almacenamiento de sesiones basado en ficheros persistentes:
Si no seleccionamos explícitamente un valor para este atributo, automáticamente se crea un directorio temporal en el Servidor WebLogic.
Si estámos usando la persitencia basada en ficheros en un cluster, debemos seelccionar explícitamente este parámetro a un directorio compartido que sea accesible por todos los servidores del cluster. Debemos crear el directorio nosotros mismos.
Usar Persistencia Basada en Bases de DatosPara almacenamiento de persistencia de sesiones basado en JDBC:
| Nombre de Columna | Tipo |
|---|---|
| wl_id | Alfanumérico de anchura variable, hasta 100 caracteres, por ejemplo, Oracle VARCHAR2(100).
La clave primaria debe configurarse como: wl_id + wl_context_path |
| wl_context_path | Alfanumérica de anchura variable, hasta 100 caracteres, por ejemplo, Oracle VARCHAR2(100).
Esta columna se usa como parte de la clave primaria. |
| wl_is_new | Single char; Por ejemplo, Oracle CHAR(1) |
| wl_create_time | Numérico, 20 digitos; Por ejemplo Oracle NUMBER(20) |
| wl_is_valid | Single char; por ejemplo, Oracle CHAR(1) |
| wl_session_values | Large binary; Por ejemplo, Oracle LONG RAW |
| wl_access_time | Numérico, 20 digitos; por ejemplo, NUMBER(20) |
| wl_max_inactive_interval | Integer; por ejemplo, Oracle Integer.
Número de sesiones entre peticiones de cliente antes de que la sesión sea invalidada. Un valor negativo indica que la sesión nunca será timeout. |
Si estamos usando una base de datos Oracle, podemos usar la siguiente sentencia SQL para crear la tabla wl_servlet_sessions:
create table wl_servlet_sessions
(
wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_is_new CHAR(1),
wl_create_time NUMBER(20),
wl_is_valid CHAR(1),
wl_session_values LONG RAW,
wl_access_time NUMBER(20),
wl_max_inactive_interval INTEGER,
PRIMARY KEY (wl_id, wl_context_path) );
Podemos modificar la sentencia SQL anterior para usarla con nuestro motor de Base de Datos.
|
Nota:
Podemos configurar la duración máxima de la persistencia de sesión JDBC que debería esperar una conexión JDBC del almacen de conexiones antes de fallar al cargar los datos de la sesión con el atributo JDBCConnectionTimeoutSecs. |
Usar Reescritura de URLEn algunas ocasiones, un navegador podría no aceptar cookies, lo que hace imposible el seguimiento de sesión utilizando cookies. La reescritura de URL es una solución a esta situación que puede ser sustituida automáticamente cuando el Servidor WebLogic detecta que el navegador no soporta cookies. La reescritura de URL implica la codificación de la ID de la sesión en los hiper-enlaces de las páginas web que nuestro servlet devuelve al navegador. Cuando luego el usuario pulsa sobre estos enlaces, el Servidor WebLogic extrae la ID de la dirección URL y encuentra la HttpSession apropiada cuando nuestro servlet llama al método getSession().
Para activar la reescritura de URLs en el Servidor WebLogic, seleccionamos el atributo URLRewritingEnabled en el descriptor de despliegue específico de WebLogic, bajo el elemento <session-descriptor> a TRUE. (El valor por defecto de este atributo es TRUE).
Guias de Codificación para Reescritura de URLsHay algunas guías generales para el modo en que nuestro código debería manejar las URLs para soportar la reescritura de URLs:
out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");
En su lugar, usamos el método HttpServletResponse.encodeURL(), por ejemplo:
out.println("<a href=\"”
+ response.encodeURL(“myshop/catalog.jsp”)
+ “\">catalog</a>");
Llamar al método encodeURL() determina si la URL necesita ser reescrita, y si es así, la reescribe, incluyendo el ID de sesión en la URL. El ID de sesión se añade a la URL y empieza con un punto y coma.if (session.isNew()) response.sendRedirect (response.encodeRedirectUrl(welcomeURL));WebLogic Server usa reescritura de URL cuando una sesión es nueva, incluso si el navegador acepta cookies, porque el servidor no puede decir si el navegador acepta cookies en la primera visita de una sesión.
Reescritura de URL y Wireless Access Protocol (WAP)Si estamos escribiendo una aplicación Wap, debemos usar la reescritura de URL porque el protocolo WAP no soporta cookies. Además, algunos dispositivos WAP tienen un límite de 128 caracteres en la longitud de la URL (incluyendo parámetros), lo que limita la cantidad de datos que se pueden transmitir usando reescritura de URL. Para permitir más espacio para los parámetros, podemos límitar el tamaño de la ID de sesión que genera aleatoriamente el Servidor WebLogic especificando el número de límites con el atributo IDLength
Usar Conjuntos de Caracteres y Datos POSTPodemos seleccionar el conjunto de caracteres que se usa para procesar los datos desde un formulario que usa el método POST. Para informar a la aplicación que procesa los datos del formulario que se está usando un conjunto de caracteres particular debemos añadir caracteres especificos "señales" a la URL usada para procesar los datos del formulario (especificado con el atributo action de ls etiqueta <form>) y luego mapear dichos caracteres a una codificación en el descriptor de despliegue de la Aplicación Web. Los datos POST normalmente se leen usando ASCII a menos que especifiquemos lo contrario usando el siguiente procedimiento.
Para procesar los datos POST en un conjunto de caracteres no ASCII:
<context-param> <param-name>weblogic.httpd.inputCharset./rus/jo*</param-name> <param-value>windows-1251</param-value> </context-param>
<form action="http://some.host.com/myWebApp/rus/jo/index.html"> ... </form>Situamos el string de señal después del nombre de la aplicación Web (también llamado path de contexto —myWebApp— en este caso) y antes de la porción de renombrado de la URL.
 |
Leer comentarios (26) |
 |
Escribir comentario |
Puntuación: (49 votos) |
|
 |
Votar |
 |
Recomendar este tutorial |
 |
Estadísticas |
Copyright © 1999-2007
Programación en castellano.
Todos los derechos reservados.
Formulario de Contacto -
Datos legales -
Publicidad
Mantenida por: Claudio y
Dani.
Hospedaje web y servidores dedicados linux por Ferca Network
red internet: jugar gratis | amor | navidad 2009 | registro de dominios |
servidores dedicados
más internet: comprar | gratis | posicionamiento en buscadores | decoración libre | gifs animados