Tomcat
Para habilitar las trazas de logging tal y como se utilizan en la instalación por defecto de Tomcat 7, pero dentro del Eclipse usando WTP, debemos seguir los siguientes pasos:

  1. En la vista Project Explorer (o Navigator o Package Explorer) vamos a Servers –> Tomcat v7.0 Server at localhost-config –> Botón derecho –> Import –> General –> File System –> Next –> Navegamos a la carpeta $CATALINA_BASE/conf/ (donde $CATALINA_BASE es la carpeta de instalación del Tomcat 7) –> Seleccionamos el fichero logging.properties –> Finish
  2. Vamos a Run –> Run Configurations… –> Apache Tomcat –> Tomcat v7.0 Server at localhost –> Arguments –> Y en “VM arguments” añadimos:

    -Djava.util.logging.config.file="${workspace_loc}/Servers/Tomcat v7.0 Server at localhost-config/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

    –> Apply

NOTA: Es posible que el nombre de la carpeta de configuración del servidor (Tomcat v7.0 Server at localhost-config) sea diferente o que el nombre de la configuración del lanzador (Tomcat v7.0 Server at localhost) sea distinta. Será necesario ajustarla acorde a tu configuración particular.

Tomcat
Por defecto el nivel de logging definido en Tomcat 7 es INFO.

Con este nivel de logging, no se detalla ningún tipo de información acerca de la configuración del contexto JNDI que se define para cada módulo desplegado.

Si necesitamos “trazar” la definición de dichos contextos JNDI tenemos que activar el nivel DEBUG en la clase org.apache.catalina.core.NamingContextListener que, según el JavaDoc es una:

Helper class used to initialize and populate the JNDI context associated with each context and server

Para hacer esto, editamos el fichero $CATALINA_BASE/conf/logging.properties y añadimos al final algo así:


# To see debug messages in NamingContextListener
org.apache.catalina.core.NamingContextListener.level = FINE

Si además de trazar la definición de los contextos JNDI queremos trazar las consultas (lookups) que se realizan a dichos contextos, podemos activar la traza a nivel del paquete org.apache.naming añadiendo algo así:


# To see debug messages in org.apache.naming package
org.apache.naming.level = FINE

WebSphere Liberty Profile
A continuación se describen los pasos a seguir para configurar el acceso a transacciones IMS (Information Management System) desde WebSphere Liberty Profile.

WebShpere Liberty Profile, a partir de la versión 8.5.5.2, soporta la configuración de adaptadores de recursos que cumplan con la especificación Java EE Connector Architecture (JCA) 1.6, 1.5 o 1.0.

Leer el resto de esta entrada »

WebSphere Liberty Profile
A continuación se describen los pasos a seguir para configurar el acceso a transacciones CICS (Customer Information Control System) desde WebSphere Liberty Profile.

WebShpere Liberty Profile, a partir de la versión 8.5.5.2, soporta la configuración de adaptadores de recursos que cumplan con la especificación Java EE Connector Architecture (JCA) 1.6, 1.5 o 1.0.

Leer el resto de esta entrada »

WebSphere Liberty Profile
Partimos de que tenemos un Eclipse con las WAS Developer Tools (WDT).

Antes de comenzar vamos a descargar los archivos que contienen el runtime y otras características adicionales que vayamos a necesitar.

Por defecto, la configuración de un entorno de ejecución de Websphere Liberty Profile solamente incluye una serie de features (características) estándar y si queremos añadir soporte para alguna feature adicional debemos seleccionarla en el momento de la definición del runtime (no es posible añadirla “a posteriori” una vez configurado el entorno de ejecución).

Podemos descargar los ficheros desde la página de descargas de WASdev cuya versión actual 8.5.5.4 (Enero 2015) se puede descargar de https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/downloads/wlp/8.5.5.4/

Leer el resto de esta entrada »

WebSphere software
Al intentar instalar un antiguo WebSphere 7.0 en un sitema con Mozilla Firefox 10+ como navegador por defecto, ejecutando el IBM Launchpad usando el script launchpad.she, aparece el siguiente mensaje:

An error occurred while starting the launchpad. This error typically occurs when
the launchpad is unable to find a supported browser. Check your product’s
documentation for a list of supported browsers.

El problema está en que las versiones soportadas de Firefox para esta versión de launchpad se limitan a las veriones 1 a 9. Afortunadamente existe algún “apaño” para soportar versiones superiores.

Según se indica en http://www-01.ibm.com/support/docview.wss?uid=swg21595098 podemos modificar el script launchpad\browser.sh de tal modo que la función supportedFirefoxVersion() quede tal que así:

browser.sh Línea 22:

supportedFirefoxVersion()
{
case "$*" in
*Firefox\ [1-9].*) return 0;;
*Firefox/[1-9].*) return 0;;
*Firefox\ [1-9][0-9].*) return 0;;
...

Una vez modificado este fichero, al intentar arrancar la aplicación IBM Launchpad ejecutando el comando launchad.sh en un sistema cuyo navegador por defecto es un Mozilla Firefox 15+, puedes recibir el siguiente mensaje de error en el navegador:

Unable to find supported browser

An error occurred while starting the launchpad. This error typically occurs when the launchpad is unable to find a supported browser. Check your product’s documentation for a list of supported browsers.
NOTE: This file is a place holder for product specific instructions about how to recover from this error.
You should describe the location of installation programs on the product CD so the user can run them directly without starting launchpad if necessary.
Procedure for correcting the error that is preventing the launchpad from displaying
==============================================================
The launchpad supports the following browsers:
o Mozilla
o Firefox
o Internet Explorer (Microsoft Windows platforms only)
o SeaMonkey

Con un poco de investigación, verás que la variable whichBrowser en el script launchpad\browser.sh (invocado por launchpad.sh) se fija correctamente (con la modificación anterior), y que tu navegador se abre con el siguiente comando:

/usr/bin/firefox -P Profile_2883 -profile /tmp/IBM_LaunchPad_2883/Profile_2883 file:///media/sf_websphere_media/media_80/wp_package/Setup/launchpad/Mozilla.html

Esto, inmediatamente te redirige a file:///media/sf_websphere_media/media_80/wp_package/Setup/launchpad/en/noBrowser.html – puede que ni siquiera notes que la redirección ocurre, lo que puede ser frustrante.

Lo que ocurre es que el fichero javascript “Mozilla.js” (llamado desde “Mozilla.html“) está intentando hacer una llamada a netscape.security.PrivilegeManager.enablePrivilege, que ya no está soportada por Firefox. Esto lanza un error javascript, que produce la redirección.

Mozilla.js Línea 42:

netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

El soporte para enablePrivilege ha sido eliminado de Firefox (Bug 546848), de modo que ya no es posible obtener privilegios especiales usando este método.

Para más detalles sobre este cambio en Firefox, revisa la siguiente nota de soporte: http://support.mozilla.org/en-US/questions/944433

Siguiendo las indicaciones de http://www-01.ibm.com/support/docview.wss?uid=swg21643517 y si nuestra versión de Firefox es la 15 o la 17, podemos solucionar el problema editando el fichero launchpad\firefox.sh de tal modo que quede algo así:

firefox.sh Línea 57:

echo 'user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect UniversalBrowserWrite");' >$userprefpath/user.js
echo 'user_pref("capability.principal.codebase.p0.id", "'${LaunchPadURL}'");' >>$userprefpath/user.js
echo 'user_pref("browser.frames.enabled", true);' >>$userprefpath/user.js
echo 'user_pref("browser.shell.checkDefaultBrowser", false);' >>$userprefpath/user.js
echo 'user_pref("javascript.enabled", true);' >>$userprefpath/user.js
echo 'user_pref("security.fileuri.origin_policy", 4);' >>$userprefpath/user.js
echo 'user_pref("security.enable_java", false);' >>$userprefpath/user.js
echo 'user_pref("security.xpconnect.plugin.unrestricted", true);' >>$userprefpath/user.js
echo 'user_pref("update_notifications.enabled", false);' >>$userprefpath/user.js
echo 'user_pref("security.warn_entering_secure", false);' >>$userprefpath/user.js
echo 'user_pref("security.warn_leaving_secure", false);' >>$userprefpath/user.js
echo 'user_pref("security.warn_entering_weak", false);' >>$userprefpath/user.js
echo 'user_pref("security.warn_viewing_mixed", false);' >>$userprefpath/user.js
echo 'user_pref("security.warn_submit_insecure", false);' >>$userprefpath/user.js
echo 'user_pref("signon.rememberSignons", false);' >>$userprefpath/user.js
echo 'user_pref("browser.bookmarks.added_static_root", true);' >>$userprefpath/user.js
echo 'user_pref("intl.charsetmenu.browser.cache", "ISO-8859-1");' >>$userprefpath/user.js
echo 'user_pref("browser.search.opensidebarsearchpanel", false);' >>$userprefpath/user.js
echo 'user_pref("dom.allow_scripts_to_close_windows", true);' >>$userprefpath/user.js
echo 'user_pref("dom.disable_open_during_load", false);' >>$userprefpath/user.js
echo 'user_pref("nglayout.initialpaint.delay", 0);' >>$userprefpath/user.js
echo 'user_pref("browser.link.open_external", 2);' >>$userprefpath/user.js
echo 'user_pref("security.fileuri.strict_origin_policy", false);' >>$userprefpath/user.js
echo 'user_pref("browser.EULA.3.accepted", true);' >>$userprefpath/user.js
echo 'user_pref("browser.EULA.4.accepted", true);' >>$userprefpath/user.js
echo 'user_pref("browser.EULA.5.accepted", true);' >>$userprefpath/user.js
echo 'user_pref("security.enablePrivilege.enable_for_tests", true);' >>$userprefpath/user.js
...

En caso contrario, para solventar el problema, tendremos que instalar una versión antigua de Firefox. Puedes encontrar versiones antiguas de Firefox aquí: https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/

NOTA: Puede ser necesario establecer la variable de entorno que indica el navegador a utilizar, del siguiente modo:
export BROWSER=/usr/lib64/firefox

vía

Tomcat
Hace algún tiempo me encontré con la necesidad de “simular” el funcionamiento de obtención de recursos de tipo URL mediante JNDI que proporciona WebShpere Application Server, pero en Tomcat.

En su día escribí una factoría para Tomcat pero, lamentablemente, perdí el código así que hoy me he puesto manos a la obra para reescribirla (ya que, realmente, no es nada complicado).

La definición de un recurso URL solamente requiere de un nombre, un nombre JNDI y la URL.

Aquí está disponible la factoría para todo aquel que la desee utilizar (código fuente incluido).

Los pasos a seguir para poder hacer uso de la misma son los siguientes:

  1. Asegúrate que la URLFactory está disponible para Tomcat:
    Pon el fichero tomcat-factory-url.jar en el directorio $CATALINA_HOME/lib.
  2. Declara tu recurso:
    Modifica el descriptor de despliegue de de tu aplicación web (/WEB-INF/web.xml) para definir el nombre JNDI bajo el que solicitarás las nuevas instancias de URL. El modo más sencillo de hacerlo es utilizar el elemento <resource-env-ref>, tal que así:

    <resource-env-ref>
    <description>
    Object factory for URL instances.
    </description>
    <resource-env-ref-name>
    url/MyURL
    </resource-env-ref-name>
    <resource-env-ref-type>
    java.net.URL
    </resource-env-ref-type>
    </resource-env-ref>
  3. Codifica tu aplicación para utilizar este recurso:
    Un uso típico de referencia de recurso de entorno sería algo así:

    Context initCtx = new InitialContext();
    Context envCtx = (Context) initCtx.lookup("java:comp/env");
    URL url = (URL) envCtx.lookup("url/MyURL");
    writer.println(“url = ” + url.toString());
  4. Configura la factoría de recursos de Tomcat:
    Edita el META-INF/context.xml de tu aplicación o el $CATALINA_HOME/conf/server.xml si quieres que el recurso esté disponible para todo el sistema:

    <Resource name="url/MyURL" auth="Container"
    type="java.net.URL"
    factory="org.eu.rubensa.tomcat.factory.URLFactory"
    url="http://blog.rubena.eu.org/" />

Algunos enlaces de interés
Apache Tomcat 6.0 JNDI Resources HOW-TO

A %d blogueros les gusta esto: