Dos Ideas. - Contribuciones del usuario [es]

Mock de un WS mediante Spring WS

2012-03-29T17:58:26Z

Fguerra: /* Fuente */

===Introducción===

En esta página explicaremos de qué forma podemos simular el entorno de un Web Service en memoria, de modo tal de poder realizar un test de componentes contra dicho entorno.

===Requerimientos===

Para mockear un Web Service mediante Spring WS, necesitaremos agregar a nuestro proyecto los siguientes jars:
* jaxb-api-2.0.jar
* jaxb-impl-2.0.3.jar
* xalan-2.7.1.jar (importante que sea esta versión o superior)
* xmlunit-1.1.jar

===Ejemplo===

Básicamente, el código para crear un test contra dicho entorno será como el siguiente:

<code java>
@RunWith(SpringJUnit4ClassRunner.class)

// indicamos a Spring que levante los archivos de configuración que veremos más adelante
@ContextConfiguration("spring-configuration.xml")
public class ClienteIntegracionTest {

// Creamos el request a enviarle al WS
private String request = "<ns2:ClienteRequest xmlns:ns2='http://ejemplo.com.ar/'><ns2:APELLIDO_RAZONSOCIAL>Una razon social</ns2:APELLIDO_RAZONSOCIAL></ns2:ClienteRequest>";

// Creamos el response que nos responderá el WS
private String response = "<ns2:ClienteResponse xmlns:ns2='http://ejemplo.com.ar/'><ns2:ID_CLIENTE>123</ns2:ID_CLIENTE></ns2:ClienteResponse>";

//Inyectamos el WebServiceTemplate
@Autowired
private WebServiceTemplate webServiceTemplate;

// Mockeamos el WebServiceServer
private MockWebServiceServer server;

// Clase nuestra que lo consumirá
@Autowired
private Cliente cliente;

// En el Before levantamos el server pasandole como parámetro al constructor
// el webServiceTemplate
@Before
public void setup() {
server = MockWebServiceServer.createServer(webServiceTemplate);
}

@Test
public void testInvocacionWs() {

// Le damos comportamiento a nuestro WS con el request y el response
// antes configurado
server.expect(RequestMatchers.payload(new StringSource(request))).andRespond(ResponseCreators.withPayload(new StringSource(response)));

cliente.invocarMetodoQueLlamaAlWs();

// Nos aseguramos que el servicio fue invocado
server.verify();
}

}
</code>

Dentro de los archivos de configuración que levante Spring, tendremos que configurarle los siguientes beans:

<code xml>
<bean id="wsTemplate" class="org.springframework.ws.client.core.WebServiceTemplate">

<property name="defaultUri" value="http://localhost:8080/" />
<property name="marshaller" ref="marshaller" />
<property name="unmarshaller" ref="marshaller" />
</bean>

<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="classesToBeBound">
<list>

<value>com.dosideas.ejemplo.schemas.ClienteRequest</value>
<value>com.dosideas.ejemplo.schemas.ClienteResponse</value>
</list>
</property>
</bean>
</code>

Finalmente, el método de nuestra clase cliente, deberá contener

<code java>
public void invocarMetodoQueLlamaAlWs() {
...
ClienteRequest clienteRequest = new ClienteRequest();
...
ClienteResponse clienteResponse = (clienteResponse) webServiceTemplate
.marshalSendAndReceive(clienteRequest);
...
}
</code>

====Fuente====
*[http://static.springsource.org/spring-ws/site/reference/html/client.html Spring MVC Test ]
*[http://www.developer.com/java/ent/integration-testing-support-in-spring-ws-2.0.html Otro ejemplo ]

Mock de un WS mediante Spring WS

2012-03-29T17:57:09Z

Fguerra: /* Ejemplo */

Mock de un WS mediante Spring WS

2012-03-29T17:29:06Z

Fguerra: /* Ejemplo */

===Introducción===

En esta página explicaremos de qué forma podemos simular el entorno de un WS en memoria, de modo tal de poder realizar un test de componentes contra dicho entorno.

===Requerimientos===

Para mockear un WS mediante Spring WS, necesitaremos agregar a nuestro proyecto los siguientes jars:
* jaxb-api-2.0.jar
* jaxb-impl-2.0.3.jar
* xalan-2.7.1.jar (importante que sea esta versión o superior)
* xmlunit-1.1.jar

===Ejemplo===

Básicamente, el código para crear un test contra dicho entorno será como el siguiente:

<code java>
@RunWith(SpringJUnit4ClassRunner.class)

// indicamos a Spring que levante los archivos de configuración que veremos más adelante
@ContextConfiguration("spring-configuration.xml")
public class ClienteIntegracionTest {

// Creamos el request a enviarle al WS
private String request = "<ns2:UserProfileCreateRequest xmlns:ns2='http://shekhar.com/usermanagement/schemas'> Shekhar Gulati 27 ";

// Creamos el response que nos responderá el WS
private String response = "<ns2:UserProfileCreateResponse xmlns:ns2='http://shekhar.com/usermanagement/schemas'> user created successfully ";

//Inyectamos el WebServiceTemplate
@Autowired
private WebServiceTemplate webServiceTemplate;

// Mockeamos el WebServiceServer
private MockWebServiceServer server;

// Clase nuestra que lo consumirá
@Autowired
private Cliente cliente;

// En el Before levantamos el server pasandole como parámetro al constructor
// el webServiceTemplate
@Before
public void setup() {
server = MockWebServiceServer.createServer(webServiceTemplate);
}

@Test
public void testInvocacionWs() {

// Le damos comportamiento a nuestro WS con el request y el response
// antes configurado
server.expect(RequestMatchers.payload(new StringSource(request))).andRespond(ResponseCreators.withPayload(new StringSource(response)));

cliente.invocarMetodoQueLlamaAlWs();

// Nos aseguramos que el servicio fue invocado
server.verify();
}

}
</code>

Dentro de los archivos de configuración que levante Spring, tendremos que configurarle los siguientes beans:

<code xml>
<bean id="wsTemplate" class="org.springframework.ws.client.core.WebServiceTemplate">

<property name="defaultUri" value="http://localhost:8080/" />
<property name="marshaller" ref="marshaller" />
<property name="unmarshaller" ref="marshaller" />
</bean>

<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="classesToBeBound">
<list>

<value>com.dosideas.ejemplo.schemas.ClienteRequest</value>
<value>com.dosideas.ejemplo.schemas.ClienteResponse</value>
</list>
</property>
</bean>
</code>

Finalmente, el método de nuestra clase cliente, deberá contener

<code java>
public void invocarMetodoQueLlamaAlWs() {
...
ClienteRequest clienteRequest = new ClienteRequest();
...
ClienteResponse clienteResponse = (clienteResponse) webServiceTemplate
.marshalSendAndReceive(clienteRequest);
...
}
</code>

====Fuente====
*[http://static.springsource.org/spring-ws/site/reference/html/client.html Spring MVC Test ]

Mock de un WS mediante Spring WS

2012-03-29T17:27:00Z

Fguerra: /* Ejemplo */

===Introducción===

En esta página explicaremos de qué forma podemos simular el entorno de un WS en memoria, de modo tal de poder realizar un test de componentes contra dicho entorno.

===Requerimientos===

Para mockear un WS mediante Spring WS, necesitaremos agregar a nuestro proyecto los siguientes jars:
* jaxb-api-2.0.jar
* jaxb-impl-2.0.3.jar
* xalan-2.7.1.jar (importante que sea esta versión o superior)
* xmlunit-1.1.jar

===Ejemplo===

Básicamente, el código para crear un test contra dicho entorno será como el siguiente:

<code java>
@RunWith(SpringJUnit4ClassRunner.class)

// indicamos a Spring que levante los archivos de configuración que veremos más adelante
@ContextConfiguration("spring-configuration.xml")
public class ClienteIntegracionTest {

// Creamos el request a enviarle al WS
private String request = "<ns2:UserProfileCreateRequest xmlns:ns2='http://shekhar.com/usermanagement/schemas'> Shekhar Gulati 27 ";

// Creamos el response que nos responderá el WS
private String response = "<ns2:UserProfileCreateResponse xmlns:ns2='http://shekhar.com/usermanagement/schemas'> user created successfully ";

//Inyectamos el WebServiceTemplate
@Autowired
private WebServiceTemplate webServiceTemplate;

// Mockeamos el WebServiceServer
private MockWebServiceServer server;

// Clase nuestra que lo consumirá
@Autowired
private Cliente cliente;

// En el Before levantamos el server pasandole como parámetro al constructor
// el webServiceTemplate
@Before
public void setup() {
server = MockWebServiceServer.createServer(webServiceTemplate);
}

@Test
public void testInvocacionWs() {

// Le damos comportamiento a nuestro WS con el request y el response
// antes configurado
server.expect(RequestMatchers.payload(new StringSource(request))).andRespond(ResponseCreators.withPayload(new StringSource(response)));

cliente.invocarMetodoQueLlamaAlWs();

// Nos aseguramos que el servicio fue invocado
server.verify();
}

}
</code>

Dentro de los archivos de configuración que levante Spring, tendremos que configurarle los siguientes beans:

<code xml>
<bean id="wsTemplate" class="org.springframework.ws.client.core.WebServiceTemplate">

<property name="defaultUri" value="http://localhost:8080/" />
<property name="marshaller" ref="marshaller" />
<property name="unmarshaller" ref="marshaller" />
</bean>

<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="classesToBeBound">
<list>

<value>com.dosideas.ejemplo.schemas.ClienteRequest</value>
<value>com.dosideas.ejemplo.schemas.ClienteResponse</value>
</list>
</property>
</bean>
</code>

====Fuente====
*[http://static.springsource.org/spring-ws/site/reference/html/client.html Spring MVC Test ]

Mock de un WS mediante Spring WS

2012-03-29T17:23:43Z

Fguerra:

Mock de un WS mediante Spring WS

2012-03-29T17:18:50Z

Fguerra:

Mock de un WS mediante Spring WS

2012-03-29T17:18:18Z

Fguerra:

Mock de un WS mediante Spring WS

2012-03-29T17:14:10Z

Fguerra:

Mock de un WS mediante Spring WS

2012-03-29T15:55:16Z

Fguerra: Página creada con '===Requerimientos=== Para mockear un WS mediante Spring WS, necesitaremos agregar a nuestro proyecto los siguientes jars: * jaxb-api-2.0.jar * jaxb-impl-2.0.3.jar * xalan-2.7.1…'

===Requerimientos===

Para mockear un WS mediante Spring WS, necesitaremos agregar a nuestro proyecto los siguientes jars:
* jaxb-api-2.0.jar
* jaxb-impl-2.0.3.jar
* xalan-2.7.1.jar (importante que sea esta versión)
* xmlunit-1.1.jar

Web Service

2012-03-29T15:52:51Z

Fguerra: /* Ver también */

[[Category:Web Service]]
Un servicio web (en inglés Web service) es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.

==Ver también==
* [[Apache CXF]]
* [[WSDL]]
* [[Web Service Con Spring]]
* [[JAX-WS]]
* [[Clientes De Web Service]]
* [[Cliente Web Service con Ant y Axis2]]
* [[Parámetros Para Web Service]]
* [[Invocar Web Service Desde Eclipse]]
* [[StackTrace Dentro De AxisFault]]
* [[Dirección IP En WebService]]
* [[Autenticación HTTP Básica en cliente con Axis2]]
* [[SoapUI]]
* [[Mock de un WS mediante Spring WS]]
* [http://es.wikipedia.org/wiki/Web_service Web Service en la Wikipedia]
* [http://ws.apache.org/axis2/ Axis2]

Log4J

2011-12-28T13:19:05Z

Fguerra: /* Modificar log4j en ejecución */

[[Category:Java]]
Log4J es una librería para resolver el log de aplicaciones [[Java]].

==Los Appender==
Log4J utiliza "appenders" para guardar el log generado por las aplicaciones. Un appender es el encargado de procesar un mensaje de log enviado por la aplicación. Usualmente se encarga de almacenarlo en algún medio persistente, como ser un archivo.

Existen distintos appenders para guardar logs en archivos, base de datos o colas de mensajeria.

===JMSAppnder===

Log4J cuenta con un Appender especial que redirecciona los eventos de log a un Topic [[JMS]].

El appender a utilizar es ''org.apache.log4j.net.JMSAppender'', el cual se encarga de enviar los eventos de log a un Topic asociado. Un topic es parecido a una cola, pero con la diferencia que los mensajes se distribuyen a todos los suscriptores de la misma. Si no hay suscriptores, el mensaje se pierde.

El JMSAppnder es muy útil en un ambiente en cluster, para centralizar la información de los log en un único lugar.

==== Ejemplo de uso ====

En la práctica, utilizar log4j con este appender es igual que en cualquier otro caso. En el archivo de configuración ''log4j.properties'' es necesario agregar el appender en cuestión.

log4j.logger.com.zim=DEBUG, jms
log4j.appender.jms=org.apache.log4j.net.JMSAppender
log4j.appender.jms.InitialContextFactoryName=weblogic.jndi.WLInitialContextFactory
log4j.appender.jms.ProviderURL=t3://miApplicationServer:7001
log4j.appender.jms.TopicConnectionFactoryBindingName=JmsZimCF
log4j.appender.jms.TopicBindingName=ZimTopic
log4j.appender.jms.locationInfo=true

En el ejemplo, utilizamos el Connection Factory ''JmsZmiCF'' para conectarnos al topic ''ZimTopic'' (ambos teniendo que estar configurados en algún [[Servidor de Aplicaciones]]).

Con esta configuración todos los logs de las clases que pertenezcan al paquete "com.zim" se enviaran como mensajes al topic. Al Topic se envian objetos de tipo ''LoggingEvent'', clase que contiene la información de un evento de log.

Luego, podrá haber distintos suscriptores que tomen las acciones necesarias sobre el mensaje. Por ejemplo, podriamos tener suscriptores que guarden el log en una base de datos, u otros que envien un mail o sms.

====Sobre el locationInfo====

Por default, el atributo locationInfo está en "false". Esto hace que NO se envien los datos para el objeto ''LocationInfo'' de ''LoggingEvent''. Al setearlo en true, el objeto ''LocationInfo'' contendrá la información sobre la clase, método y número de línea en donde ocurrió el error.

====Procesando el mensaje====

Luego, queda tan solo decidir qué hacer con el mensaje. Usualmente, será un [[Message Driven Bean]] que procese de alguna manera el mensaje que envia Log4J.

¿Y qué envia exactamente? Log4J enviará un ''ObjectMessage'' de JMS, que contiene una instancia de ''LoggingEvent'', la cual contiene la información relativa al log que generó la aplicación.

===SMTPAppender===

Es un Appender muy útil para la generación de alarmas vía mail.

NOTA 1: Por estar pensado para casos de error (o tal vez por bug) sólo se envía el mail cuando el nivel de log es ERROR o superior.

NOTA 2: Utilizar la versión de log4j 1.2.16 o superior (en las anteriores hay algún inconveniente sobre todo si se utiliza smtp.gmail.com).

==== Ejemplo de uso ====

Configuración en ''log4j.properties'':

<code>
# Acordate!!! Nivel ERROR o superior

log4j.logger.com.demo.smtpAppender.MyService=ERROR, mailAppender

# SMTP appender para alarmas via mail

log4j.appender.mailAppender=org.apache.log4j.net.SMTPAppender
log4j.appender.mailAppender.Threshold=WARN
log4j.appender.mailAppender.BufferSize=10
log4j.appender.mailAppender.To=<mails_destino_separados_por_coma>
log4j.appender.mailAppender.From=<mail_from>
log4j.appender.mailAppender.SMTPHost=<smtp_host>
log4j.appender.mailAppender.SMTPPort=<puerto>
log4j.appender.mailAppender.SMTPUsername=<username>
log4j.appender.mailAppender.SMTPPassword=<password>
log4j.appender.mailAppender.SMTPProtocol=smtps
log4j.appender.mailAppender.Subject=Alarma generada con Log4J
log4j.appender.mailAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.mailAppender.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
</code>

Con esta configuración los logs de nivel error o superior de la clase MyService enviarán un mail con la información que se loguee.

==Log4j en J2EE, en servidores WebLogic==

Si queres compartir los mismos componentes log4j en un módulo EJB y Web, y el EJB se usa localmente, en el ear tienen que estar el EJB y el Web. El log4-*.jar en /APP-INF/lib, y log4.properties en /APP-INF/classes. /APP-INF/ en la raíz del ear.

Y dentro del build-impl.xml del ear, los sgtes. pasos para la tarea que crea el META-INF:

<code>
<copy todir="${build.dir}/APP-INF/lib">
<fileset file="${log4j.jar}"/>
</copy>
<copy todir="${build.dir}/APP-INF/classes">
<fileset file="${log4j.properties}"/>
</copy>
</code>

==Log4J en Debug==

Se puede usar el argumento '''-Dlog4j.debug''' como parametro para la JVM y muestra algunas cosas de log4J por consola, como por ejemplo, el archivo desde donde está levantando las propiedades.

==Obtención del Logger==
Existe una serie de variantes para definir y obtener el logger de una clase:

===Los modificadores===
====private====
Por lo general queremos que el logger se reporte como la clase que se está ejecutando. Utilizando private nos aseguramos que una clase que herede tenga que declarar su propio Logger y no usará accidentalmente el de la superclase. Contrariamente, si queremos por granularidad que utilice el de la superclase, habrá que declararlo como protected.

====final====
La referencia al logger es la misma durante todo el ciclo de vida de una clase (si se declara static) o de un objeto (si es atributo de instancia). Por lo tanto, declarándola final se expresa esto, se protege a una asignación errónea y se mejora la performance.

====static====
La creación del Logger está administrada por una fábrica a la que le pedimos las instancias. Es responsabilidad de la fábrica darnos la instancia correcta. En este caso, la motivación de utilizar static no es la de tener una sola copia. La motivación es que los logger no deben serializarse, deberían ser transient. Siendo static es una variable de la clase y no un atributo de la instancia, por lo que no será serializado. La razón de no marcarlo como transient (que sería conceptualmente más acertado) es que se debería implementar un mecanismo para que cuando la instancia es des-serializada, vuelva a obtener una copia del logger.

====transient====
Los logger no deben ser serializados, por eso deberían ser marcados como transient. Es más fácil marcarlos como static ya que de esta forma no es necesario volver a obtenerlos cuando la clase es des-serializada. Si la clase no es serializable, no es necesario.

===Clave para la obtención del logger===
El logger se le pide a la fábrica a través de una clave. Esta clave es de tipo String. El método está sobrecargado para recibir también un objeto de tipo class que luego la fábrica convertirá a String.

====String====
private static final Logger log = Logger.getLogger("com.foo.bar.Blah");
Utilizando un String se obtiene un logger independientemente de la clase donde se esté. Si lo que se busca el logger para la clase, esta es la forma más riesgosa ya que no está verificada por el compilador.

====Objeto class====
private static final Logger log = Logger.getLogger(Blah.class);
Utilizando un objeto de tipo Class permite que el compilador verifique el nombre de la clase. También se actualiza si se utiliza alguna herramienta o IDE para cambiar el nomre de la clase.

====método getClass()====
private transient Logger log = Logger.getLogger(getClass());
En este caso la clave se genera en tiempo de ejecución pidiendo al objeto su clase a través del método getClass(). Esto tiene la ventaja de que siempre tendrá el nombre apropiado de la clase. Tiene la restricción de que sólo se podrá utilizar si el logger es un atributo de instancia (no static).

Otra particularidad es que el método getClass() invocado en una clase padre responderá desde la clase hija.

En caso de que el objeto sea serializable habrá que agregar el modificador transient para que no se serialice el logger.

===Conclusión===
La forma práctica de no cometer errores es la de utilizar la combinación más restrictiva y cambiarla sólo si se tiene alguna razón claramente justificada e implementando los mecanismos necesarios.

Forma típica:

<code>
public class Blah {
private static final Logger log = Logger.getLogger(Blah.class);
}
</code>

== Log4JMDC ==
MDC es una característica de [[Log4J]] que permite agregar información adicional (de forma "clave=valor"), que luego puede ser referenciada en el patrón de log. Aquí entonces podemos almacenar datos generales (como ser, el nombre de usuario) y mostrarlos en todos los logs que se generen.

En el patrón de log, se pueden hacer referencia a las variables del MDC usando:
%X{clave}

Los datos del MDC se guardan en el thread en ejecución. Un uso común es crear un Filter web, y allí guardar el nombre de usuario logueado en el entorno MDC, para que luego pueda loguearse.

=== Filter web con MDC ===
El siguiente es un filter web común que guarda la variable "username" en el MDC, para luego referenciarla en patrón de log4j.xml

<code java5>
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package com.dosideas.mdc.filter;

import java.io.IOException;
import javax.servlet.*;
import org.apache.log4j.MDC;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;

/**
* Adds MDC information for Log4j. In particular, it adds the username (if
* available) to MDC.
*/
public class Log4jMDCFilter implements Filter {

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

String username = obtenerNombreDeUsuarioLogueado();

try {
MDC.put("username", username);
chain.doFilter(request, response);
} finally {
MDC.remove("username");
}
}

@Override
public void init(FilterConfig filterConfig) throws ServletException { }

@Override
public void destroy() { }

private String obtenerNombreDeUsuarioLogueado() { .... }
}
</code>

Luego, en el archivo log4j.xml podemos hacer uso de la variable username (noten el valor del atributo "ConversionPattern"):
<code xml>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="console" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%X{username}] %c - %m%n"/>
</layout>
</appender>

<root>
<priority value ="debug" />
<appender-ref ref="console" />
</root>

</log4j:configuration>
</code>

== Modificar log4j en ejecución ==
Utilizando un listener de spring se puede configurar la ruta del archivo log4j.properties (fuera del empaquetado) y el tiempo en que se vuelve a leer el mismo, lo cual nos permite modificar sus valores en ejecucion sin necesidad de redeployar la aplicacion.

Para esto se configura dentro del web.xml

<code xml>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>file:/path/log4j.properties</param-value>
</context-param>
<context-param>
<param-name>log4jRefreshInterval</param-name>
<param-value>5000</param-value>
</context-param>
</code>

Un error con el que nos podemos topar al momento de agregar esta configuración e intentar desplegar en Weblogic es el siguiente:

<code xml>Cannot set web app root system property when WAR file is not expanded</code>

Ante este error, la solución es agregar en el weblogic.xml dentro del tag <weblogic-web-app> el siguiente código:

<code xml>
<container-descriptor>
<show-archived-real-path-enabled>true</show-archived-real-path-enabled>
</container-descriptor>
</code>

==Ver también==
* [http://logging.apache.org/log4j Web oficial de Log4J]
* [http://logging.apache.org/log4j/docs/api/org/apache/log4j/spi/LoggingEvent.html Javadoc del LogginEvent]
* [http://www.slideshare.net/Emmerson_Miranda/log4j-1215-short-manual Introducción a Log4j]
* [http://books.google.com.ar/books?id=vHvY008Zq-YC&pg=PA158&lpg=PA158&dq=weblogic+same+class+loader+log4j&source=bl&ots=yh8Z3e1X7C&sig=x81fCioIEn5nGAZNRg8kLNcOk0Y&hl=es&ei=x267Sum5HprKtgfD1NXEDQ&sa=X&oi=book_result&ct=result&resnum=7#v=onepage&q=weblogic%20same%20class%20loader%20log4j&f=false Pro Apache Log4j]

Log4J

2011-12-28T13:18:44Z

Fguerra: /* Modificar log4j en ejecución */

[[Category:Java]]
Log4J es una librería para resolver el log de aplicaciones [[Java]].

==Los Appender==
Log4J utiliza "appenders" para guardar el log generado por las aplicaciones. Un appender es el encargado de procesar un mensaje de log enviado por la aplicación. Usualmente se encarga de almacenarlo en algún medio persistente, como ser un archivo.

Existen distintos appenders para guardar logs en archivos, base de datos o colas de mensajeria.

===JMSAppnder===

Log4J cuenta con un Appender especial que redirecciona los eventos de log a un Topic [[JMS]].

El appender a utilizar es ''org.apache.log4j.net.JMSAppender'', el cual se encarga de enviar los eventos de log a un Topic asociado. Un topic es parecido a una cola, pero con la diferencia que los mensajes se distribuyen a todos los suscriptores de la misma. Si no hay suscriptores, el mensaje se pierde.

El JMSAppnder es muy útil en un ambiente en cluster, para centralizar la información de los log en un único lugar.

==== Ejemplo de uso ====

En la práctica, utilizar log4j con este appender es igual que en cualquier otro caso. En el archivo de configuración ''log4j.properties'' es necesario agregar el appender en cuestión.

log4j.logger.com.zim=DEBUG, jms
log4j.appender.jms=org.apache.log4j.net.JMSAppender
log4j.appender.jms.InitialContextFactoryName=weblogic.jndi.WLInitialContextFactory
log4j.appender.jms.ProviderURL=t3://miApplicationServer:7001
log4j.appender.jms.TopicConnectionFactoryBindingName=JmsZimCF
log4j.appender.jms.TopicBindingName=ZimTopic
log4j.appender.jms.locationInfo=true

En el ejemplo, utilizamos el Connection Factory ''JmsZmiCF'' para conectarnos al topic ''ZimTopic'' (ambos teniendo que estar configurados en algún [[Servidor de Aplicaciones]]).

Con esta configuración todos los logs de las clases que pertenezcan al paquete "com.zim" se enviaran como mensajes al topic. Al Topic se envian objetos de tipo ''LoggingEvent'', clase que contiene la información de un evento de log.

Luego, podrá haber distintos suscriptores que tomen las acciones necesarias sobre el mensaje. Por ejemplo, podriamos tener suscriptores que guarden el log en una base de datos, u otros que envien un mail o sms.

====Sobre el locationInfo====

Por default, el atributo locationInfo está en "false". Esto hace que NO se envien los datos para el objeto ''LocationInfo'' de ''LoggingEvent''. Al setearlo en true, el objeto ''LocationInfo'' contendrá la información sobre la clase, método y número de línea en donde ocurrió el error.

====Procesando el mensaje====

Luego, queda tan solo decidir qué hacer con el mensaje. Usualmente, será un [[Message Driven Bean]] que procese de alguna manera el mensaje que envia Log4J.

¿Y qué envia exactamente? Log4J enviará un ''ObjectMessage'' de JMS, que contiene una instancia de ''LoggingEvent'', la cual contiene la información relativa al log que generó la aplicación.

===SMTPAppender===

Es un Appender muy útil para la generación de alarmas vía mail.

NOTA 1: Por estar pensado para casos de error (o tal vez por bug) sólo se envía el mail cuando el nivel de log es ERROR o superior.

NOTA 2: Utilizar la versión de log4j 1.2.16 o superior (en las anteriores hay algún inconveniente sobre todo si se utiliza smtp.gmail.com).

==== Ejemplo de uso ====

Configuración en ''log4j.properties'':

<code>
# Acordate!!! Nivel ERROR o superior

log4j.logger.com.demo.smtpAppender.MyService=ERROR, mailAppender

# SMTP appender para alarmas via mail

log4j.appender.mailAppender=org.apache.log4j.net.SMTPAppender
log4j.appender.mailAppender.Threshold=WARN
log4j.appender.mailAppender.BufferSize=10
log4j.appender.mailAppender.To=<mails_destino_separados_por_coma>
log4j.appender.mailAppender.From=<mail_from>
log4j.appender.mailAppender.SMTPHost=<smtp_host>
log4j.appender.mailAppender.SMTPPort=<puerto>
log4j.appender.mailAppender.SMTPUsername=<username>
log4j.appender.mailAppender.SMTPPassword=<password>
log4j.appender.mailAppender.SMTPProtocol=smtps
log4j.appender.mailAppender.Subject=Alarma generada con Log4J
log4j.appender.mailAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.mailAppender.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
</code>

Con esta configuración los logs de nivel error o superior de la clase MyService enviarán un mail con la información que se loguee.

==Log4j en J2EE, en servidores WebLogic==

Si queres compartir los mismos componentes log4j en un módulo EJB y Web, y el EJB se usa localmente, en el ear tienen que estar el EJB y el Web. El log4-*.jar en /APP-INF/lib, y log4.properties en /APP-INF/classes. /APP-INF/ en la raíz del ear.

Y dentro del build-impl.xml del ear, los sgtes. pasos para la tarea que crea el META-INF:

<code>
<copy todir="${build.dir}/APP-INF/lib">
<fileset file="${log4j.jar}"/>
</copy>
<copy todir="${build.dir}/APP-INF/classes">
<fileset file="${log4j.properties}"/>
</copy>
</code>

==Log4J en Debug==

Se puede usar el argumento '''-Dlog4j.debug''' como parametro para la JVM y muestra algunas cosas de log4J por consola, como por ejemplo, el archivo desde donde está levantando las propiedades.

==Obtención del Logger==
Existe una serie de variantes para definir y obtener el logger de una clase:

===Los modificadores===
====private====
Por lo general queremos que el logger se reporte como la clase que se está ejecutando. Utilizando private nos aseguramos que una clase que herede tenga que declarar su propio Logger y no usará accidentalmente el de la superclase. Contrariamente, si queremos por granularidad que utilice el de la superclase, habrá que declararlo como protected.

====final====
La referencia al logger es la misma durante todo el ciclo de vida de una clase (si se declara static) o de un objeto (si es atributo de instancia). Por lo tanto, declarándola final se expresa esto, se protege a una asignación errónea y se mejora la performance.

====static====
La creación del Logger está administrada por una fábrica a la que le pedimos las instancias. Es responsabilidad de la fábrica darnos la instancia correcta. En este caso, la motivación de utilizar static no es la de tener una sola copia. La motivación es que los logger no deben serializarse, deberían ser transient. Siendo static es una variable de la clase y no un atributo de la instancia, por lo que no será serializado. La razón de no marcarlo como transient (que sería conceptualmente más acertado) es que se debería implementar un mecanismo para que cuando la instancia es des-serializada, vuelva a obtener una copia del logger.

====transient====
Los logger no deben ser serializados, por eso deberían ser marcados como transient. Es más fácil marcarlos como static ya que de esta forma no es necesario volver a obtenerlos cuando la clase es des-serializada. Si la clase no es serializable, no es necesario.

===Clave para la obtención del logger===
El logger se le pide a la fábrica a través de una clave. Esta clave es de tipo String. El método está sobrecargado para recibir también un objeto de tipo class que luego la fábrica convertirá a String.

====String====
private static final Logger log = Logger.getLogger("com.foo.bar.Blah");
Utilizando un String se obtiene un logger independientemente de la clase donde se esté. Si lo que se busca el logger para la clase, esta es la forma más riesgosa ya que no está verificada por el compilador.

====Objeto class====
private static final Logger log = Logger.getLogger(Blah.class);
Utilizando un objeto de tipo Class permite que el compilador verifique el nombre de la clase. También se actualiza si se utiliza alguna herramienta o IDE para cambiar el nomre de la clase.

====método getClass()====
private transient Logger log = Logger.getLogger(getClass());
En este caso la clave se genera en tiempo de ejecución pidiendo al objeto su clase a través del método getClass(). Esto tiene la ventaja de que siempre tendrá el nombre apropiado de la clase. Tiene la restricción de que sólo se podrá utilizar si el logger es un atributo de instancia (no static).

Otra particularidad es que el método getClass() invocado en una clase padre responderá desde la clase hija.

En caso de que el objeto sea serializable habrá que agregar el modificador transient para que no se serialice el logger.

===Conclusión===
La forma práctica de no cometer errores es la de utilizar la combinación más restrictiva y cambiarla sólo si se tiene alguna razón claramente justificada e implementando los mecanismos necesarios.

Forma típica:

<code>
public class Blah {
private static final Logger log = Logger.getLogger(Blah.class);
}
</code>

== Log4JMDC ==
MDC es una característica de [[Log4J]] que permite agregar información adicional (de forma "clave=valor"), que luego puede ser referenciada en el patrón de log. Aquí entonces podemos almacenar datos generales (como ser, el nombre de usuario) y mostrarlos en todos los logs que se generen.

En el patrón de log, se pueden hacer referencia a las variables del MDC usando:
%X{clave}

Los datos del MDC se guardan en el thread en ejecución. Un uso común es crear un Filter web, y allí guardar el nombre de usuario logueado en el entorno MDC, para que luego pueda loguearse.

=== Filter web con MDC ===
El siguiente es un filter web común que guarda la variable "username" en el MDC, para luego referenciarla en patrón de log4j.xml

<code java5>
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package com.dosideas.mdc.filter;

import java.io.IOException;
import javax.servlet.*;
import org.apache.log4j.MDC;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;

/**
* Adds MDC information for Log4j. In particular, it adds the username (if
* available) to MDC.
*/
public class Log4jMDCFilter implements Filter {

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

String username = obtenerNombreDeUsuarioLogueado();

try {
MDC.put("username", username);
chain.doFilter(request, response);
} finally {
MDC.remove("username");
}
}

@Override
public void init(FilterConfig filterConfig) throws ServletException { }

@Override
public void destroy() { }

private String obtenerNombreDeUsuarioLogueado() { .... }
}
</code>

Luego, en el archivo log4j.xml podemos hacer uso de la variable username (noten el valor del atributo "ConversionPattern"):
<code xml>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="console" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%X{username}] %c - %m%n"/>
</layout>
</appender>

<root>
<priority value ="debug" />
<appender-ref ref="console" />
</root>

</log4j:configuration>
</code>

== Modificar log4j en ejecución ==
Utilizando un listener de spring se puede configurar la ruta del archivo log4j.properties (fuera del empaquetado) y el tiempo en que se vuelve a leer el mismo, lo cual nos permite modificar sus valores en ejecucion sin necesidad de redeployar la aplicacion.

Para esto se configura dentro del web.xml

<code xml>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>file:/path/log4j.properties</param-value>
</context-param>
<context-param>
<param-name>log4jRefreshInterval</param-name>
<param-value>5000</param-value>
</context-param>
</code>

Un error con el que nos podemos topar al momento de agregar esta configuración e intentar desplegar en Weblogic es el siguiente:

Cannot set web app root system property when WAR file is not expanded

Ante este error, la solución es agregar en el weblogic.xml dentro del tag <weblogic-web-app> el siguiente código:

<code xml>
<container-descriptor>
<show-archived-real-path-enabled>true</show-archived-real-path-enabled>
</container-descriptor>
</code>

==Ver también==
* [http://logging.apache.org/log4j Web oficial de Log4J]
* [http://logging.apache.org/log4j/docs/api/org/apache/log4j/spi/LoggingEvent.html Javadoc del LogginEvent]
* [http://www.slideshare.net/Emmerson_Miranda/log4j-1215-short-manual Introducción a Log4j]
* [http://books.google.com.ar/books?id=vHvY008Zq-YC&pg=PA158&lpg=PA158&dq=weblogic+same+class+loader+log4j&source=bl&ots=yh8Z3e1X7C&sig=x81fCioIEn5nGAZNRg8kLNcOk0Y&hl=es&ei=x267Sum5HprKtgfD1NXEDQ&sa=X&oi=book_result&ct=result&resnum=7#v=onepage&q=weblogic%20same%20class%20loader%20log4j&f=false Pro Apache Log4j]

Log4J

2011-12-27T20:01:39Z

Fguerra: /* Modificar log4j en ejecución */

[[Category:Java]]
Log4J es una librería para resolver el log de aplicaciones [[Java]].

==Los Appender==
Log4J utiliza "appenders" para guardar el log generado por las aplicaciones. Un appender es el encargado de procesar un mensaje de log enviado por la aplicación. Usualmente se encarga de almacenarlo en algún medio persistente, como ser un archivo.

Existen distintos appenders para guardar logs en archivos, base de datos o colas de mensajeria.

===JMSAppnder===

Log4J cuenta con un Appender especial que redirecciona los eventos de log a un Topic [[JMS]].

El appender a utilizar es ''org.apache.log4j.net.JMSAppender'', el cual se encarga de enviar los eventos de log a un Topic asociado. Un topic es parecido a una cola, pero con la diferencia que los mensajes se distribuyen a todos los suscriptores de la misma. Si no hay suscriptores, el mensaje se pierde.

El JMSAppnder es muy útil en un ambiente en cluster, para centralizar la información de los log en un único lugar.

==== Ejemplo de uso ====

En la práctica, utilizar log4j con este appender es igual que en cualquier otro caso. En el archivo de configuración ''log4j.properties'' es necesario agregar el appender en cuestión.

log4j.logger.com.zim=DEBUG, jms
log4j.appender.jms=org.apache.log4j.net.JMSAppender
log4j.appender.jms.InitialContextFactoryName=weblogic.jndi.WLInitialContextFactory
log4j.appender.jms.ProviderURL=t3://miApplicationServer:7001
log4j.appender.jms.TopicConnectionFactoryBindingName=JmsZimCF
log4j.appender.jms.TopicBindingName=ZimTopic
log4j.appender.jms.locationInfo=true

En el ejemplo, utilizamos el Connection Factory ''JmsZmiCF'' para conectarnos al topic ''ZimTopic'' (ambos teniendo que estar configurados en algún [[Servidor de Aplicaciones]]).

Con esta configuración todos los logs de las clases que pertenezcan al paquete "com.zim" se enviaran como mensajes al topic. Al Topic se envian objetos de tipo ''LoggingEvent'', clase que contiene la información de un evento de log.

Luego, podrá haber distintos suscriptores que tomen las acciones necesarias sobre el mensaje. Por ejemplo, podriamos tener suscriptores que guarden el log en una base de datos, u otros que envien un mail o sms.

====Sobre el locationInfo====

Por default, el atributo locationInfo está en "false". Esto hace que NO se envien los datos para el objeto ''LocationInfo'' de ''LoggingEvent''. Al setearlo en true, el objeto ''LocationInfo'' contendrá la información sobre la clase, método y número de línea en donde ocurrió el error.

====Procesando el mensaje====

Luego, queda tan solo decidir qué hacer con el mensaje. Usualmente, será un [[Message Driven Bean]] que procese de alguna manera el mensaje que envia Log4J.

¿Y qué envia exactamente? Log4J enviará un ''ObjectMessage'' de JMS, que contiene una instancia de ''LoggingEvent'', la cual contiene la información relativa al log que generó la aplicación.

===SMTPAppender===

Es un Appender muy útil para la generación de alarmas vía mail.

NOTA 1: Por estar pensado para casos de error (o tal vez por bug) sólo se envía el mail cuando el nivel de log es ERROR o superior.

NOTA 2: Utilizar la versión de log4j 1.2.16 o superior (en las anteriores hay algún inconveniente sobre todo si se utiliza smtp.gmail.com).

==== Ejemplo de uso ====

Configuración en ''log4j.properties'':

<code>
# Acordate!!! Nivel ERROR o superior

log4j.logger.com.demo.smtpAppender.MyService=ERROR, mailAppender

# SMTP appender para alarmas via mail

log4j.appender.mailAppender=org.apache.log4j.net.SMTPAppender
log4j.appender.mailAppender.Threshold=WARN
log4j.appender.mailAppender.BufferSize=10
log4j.appender.mailAppender.To=<mails_destino_separados_por_coma>
log4j.appender.mailAppender.From=<mail_from>
log4j.appender.mailAppender.SMTPHost=<smtp_host>
log4j.appender.mailAppender.SMTPPort=<puerto>
log4j.appender.mailAppender.SMTPUsername=<username>
log4j.appender.mailAppender.SMTPPassword=<password>
log4j.appender.mailAppender.SMTPProtocol=smtps
log4j.appender.mailAppender.Subject=Alarma generada con Log4J
log4j.appender.mailAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.mailAppender.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
</code>

Con esta configuración los logs de nivel error o superior de la clase MyService enviarán un mail con la información que se loguee.

==Log4j en J2EE, en servidores WebLogic==

Si queres compartir los mismos componentes log4j en un módulo EJB y Web, y el EJB se usa localmente, en el ear tienen que estar el EJB y el Web. El log4-*.jar en /APP-INF/lib, y log4.properties en /APP-INF/classes. /APP-INF/ en la raíz del ear.

Y dentro del build-impl.xml del ear, los sgtes. pasos para la tarea que crea el META-INF:

<code>
<copy todir="${build.dir}/APP-INF/lib">
<fileset file="${log4j.jar}"/>
</copy>
<copy todir="${build.dir}/APP-INF/classes">
<fileset file="${log4j.properties}"/>
</copy>
</code>

==Log4J en Debug==

Se puede usar el argumento '''-Dlog4j.debug''' como parametro para la JVM y muestra algunas cosas de log4J por consola, como por ejemplo, el archivo desde donde está levantando las propiedades.

==Obtención del Logger==
Existe una serie de variantes para definir y obtener el logger de una clase:

===Los modificadores===
====private====
Por lo general queremos que el logger se reporte como la clase que se está ejecutando. Utilizando private nos aseguramos que una clase que herede tenga que declarar su propio Logger y no usará accidentalmente el de la superclase. Contrariamente, si queremos por granularidad que utilice el de la superclase, habrá que declararlo como protected.

====final====
La referencia al logger es la misma durante todo el ciclo de vida de una clase (si se declara static) o de un objeto (si es atributo de instancia). Por lo tanto, declarándola final se expresa esto, se protege a una asignación errónea y se mejora la performance.

====static====
La creación del Logger está administrada por una fábrica a la que le pedimos las instancias. Es responsabilidad de la fábrica darnos la instancia correcta. En este caso, la motivación de utilizar static no es la de tener una sola copia. La motivación es que los logger no deben serializarse, deberían ser transient. Siendo static es una variable de la clase y no un atributo de la instancia, por lo que no será serializado. La razón de no marcarlo como transient (que sería conceptualmente más acertado) es que se debería implementar un mecanismo para que cuando la instancia es des-serializada, vuelva a obtener una copia del logger.

====transient====
Los logger no deben ser serializados, por eso deberían ser marcados como transient. Es más fácil marcarlos como static ya que de esta forma no es necesario volver a obtenerlos cuando la clase es des-serializada. Si la clase no es serializable, no es necesario.

===Clave para la obtención del logger===
El logger se le pide a la fábrica a través de una clave. Esta clave es de tipo String. El método está sobrecargado para recibir también un objeto de tipo class que luego la fábrica convertirá a String.

====String====
private static final Logger log = Logger.getLogger("com.foo.bar.Blah");
Utilizando un String se obtiene un logger independientemente de la clase donde se esté. Si lo que se busca el logger para la clase, esta es la forma más riesgosa ya que no está verificada por el compilador.

====Objeto class====
private static final Logger log = Logger.getLogger(Blah.class);
Utilizando un objeto de tipo Class permite que el compilador verifique el nombre de la clase. También se actualiza si se utiliza alguna herramienta o IDE para cambiar el nomre de la clase.

====método getClass()====
private transient Logger log = Logger.getLogger(getClass());
En este caso la clave se genera en tiempo de ejecución pidiendo al objeto su clase a través del método getClass(). Esto tiene la ventaja de que siempre tendrá el nombre apropiado de la clase. Tiene la restricción de que sólo se podrá utilizar si el logger es un atributo de instancia (no static).

Otra particularidad es que el método getClass() invocado en una clase padre responderá desde la clase hija.

En caso de que el objeto sea serializable habrá que agregar el modificador transient para que no se serialice el logger.

===Conclusión===
La forma práctica de no cometer errores es la de utilizar la combinación más restrictiva y cambiarla sólo si se tiene alguna razón claramente justificada e implementando los mecanismos necesarios.

Forma típica:

<code>
public class Blah {
private static final Logger log = Logger.getLogger(Blah.class);
}
</code>

== Log4JMDC ==
MDC es una característica de [[Log4J]] que permite agregar información adicional (de forma "clave=valor"), que luego puede ser referenciada en el patrón de log. Aquí entonces podemos almacenar datos generales (como ser, el nombre de usuario) y mostrarlos en todos los logs que se generen.

En el patrón de log, se pueden hacer referencia a las variables del MDC usando:
%X{clave}

Los datos del MDC se guardan en el thread en ejecución. Un uso común es crear un Filter web, y allí guardar el nombre de usuario logueado en el entorno MDC, para que luego pueda loguearse.

=== Filter web con MDC ===
El siguiente es un filter web común que guarda la variable "username" en el MDC, para luego referenciarla en patrón de log4j.xml

<code java5>
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package com.dosideas.mdc.filter;

import java.io.IOException;
import javax.servlet.*;
import org.apache.log4j.MDC;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;

/**
* Adds MDC information for Log4j. In particular, it adds the username (if
* available) to MDC.
*/
public class Log4jMDCFilter implements Filter {

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

String username = obtenerNombreDeUsuarioLogueado();

try {
MDC.put("username", username);
chain.doFilter(request, response);
} finally {
MDC.remove("username");
}
}

@Override
public void init(FilterConfig filterConfig) throws ServletException { }

@Override
public void destroy() { }

private String obtenerNombreDeUsuarioLogueado() { .... }
}
</code>

Luego, en el archivo log4j.xml podemos hacer uso de la variable username (noten el valor del atributo "ConversionPattern"):
<code xml>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="console" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%X{username}] %c - %m%n"/>
</layout>
</appender>

<root>
<priority value ="debug" />
<appender-ref ref="console" />
</root>

</log4j:configuration>
</code>

== Modificar log4j en ejecución ==
Utilizando un listener de spring se puede configurar la ruta del archivo log4j.properties (fuera del empaquetado) y el tiempo en que se vuelve a leer el mismo, lo cual nos permite modificar sus valores en ejecucion sin necesidad de redeployar la aplicacion.

Para esto se configura dentro del web.xml

<code xml>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>file:/path/log4j.properties</param-value>
</context-param>
<context-param>
<param-name>log4jRefreshInterval</param-name>
<param-value>5000</param-value>
</context-param>
</code>

==Ver también==
* [http://logging.apache.org/log4j Web oficial de Log4J]
* [http://logging.apache.org/log4j/docs/api/org/apache/log4j/spi/LoggingEvent.html Javadoc del LogginEvent]
* [http://www.slideshare.net/Emmerson_Miranda/log4j-1215-short-manual Introducción a Log4j]
* [http://books.google.com.ar/books?id=vHvY008Zq-YC&pg=PA158&lpg=PA158&dq=weblogic+same+class+loader+log4j&source=bl&ots=yh8Z3e1X7C&sig=x81fCioIEn5nGAZNRg8kLNcOk0Y&hl=es&ei=x267Sum5HprKtgfD1NXEDQ&sa=X&oi=book_result&ct=result&resnum=7#v=onepage&q=weblogic%20same%20class%20loader%20log4j&f=false Pro Apache Log4j]

Cache De Hibernate

2011-09-07T12:48:27Z

Fguerra: Deshecha la edición 5830 de 31.193.8.94 (disc.)

[[Category:Hibernate]]
Uso y configuración de la funcionalidad de cache en Hibernate.

Generalmente todos los cache se basan en almacenar objetos en memoria para acelerar accesos posteriores, pero debemos aclarar que en Hibernate hay dos tipos de cache: el Primer Nivel y el Segundo Nivel.

===Cache de Primer Nivel===
Es el que mantiene automáticamente Hibernate cuando dentro de una transacción interactuamos con la base de datos, en éste caso se mantienen en memoria los objetos que fueron cargados y si mas adelante en el flujo del proceso volvemos a necesitarlos van a ser retornados desde el cache, ahorrando accesos sobre la base de datos.
Lo podemos considerar como un cache de corta duración ya que es válido solamente entre el begin y el commit de una transacción, en forma aislada a las demás.
Hibernate lo maneja por defecto, no hay que configurar nada, si por alguna razón queremos deshabilitar o evitar el uso del cache, podemos usar un tipo especial de session: StatelessSession, se obtiene de la sessionFactory con el método openStatelessSession().
Se usa en el caso de los procesos batch, por ejemplo cuando se tiene que hacer inserts o updates masivos, así se evita que cada vez que se hace el save de un objeto, el mismo se quede en memoria y en el correr del proceso se produzca un error del tipo OutOfMemoryError. La StatelessSession no interactúa con el Cache de Primer Nivel ni con el Cache de Segundo Nivel, es casi como si se utilizara JDBC directamente.

===Cache de Segundo Nivel===
El Cache de Segundo Nivel permite ir varios pasos mas adelante en la mejora de la performance. La diferencia fundamental es que éste tipo de cache es válido para todas las transacciones y puede persistir en memoria durante todo el tiempo en que el aplicativo esté online, lo podríamos considerar como un cache global.

Para habilitar el Cache de Segundo Nivel hay que realizar lo siguiente:
#Seleccionar un Proveedor de Cache. Por ejemplo [[EhCache]].
#Agregar en el hibernate.cfg.xml los siguientes properties:
<property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
<property name="hibernate.cache.use_structured_entries">true</property>
#Poner en el classpath del aplicativo el archivo de configuración ehcache.xml, según las instrucciones del proveedor.
#Agregar en el mapping de las clases que se queren seleccionar como "cacheables" la siguiente entrada:
<cache usage="nonstrict-read-write"></cache>

Hibernate define cuatro niveles de cache que determinan el aislamiento:

*'''transactional''': Garantiza un nivel de aislamiento hasta repeatable read. Es el nivel más estricto. Solamente se puede utilizar en clusters, es decir, con cachés distribuidas.
*''''read-write''': Mantiene un aislamiento hasta el nivel de commited.
*'''nonstrict read-write''': No ofrece garantía de consistencia entre el caché y la base de datos. Es una es'trategia ideal para almacenar datos que no cambian habitualmente y que no sean demasiado críticos.
*'''read-only''': Es la estrategia de concurrencia menos estricta. Recomendada para datos que nunca cambian.

Otro tema importante es definir qué entidades se van a "cachear", los candidatos naturales son por ejemplo las clases que representan: provincias, países, monedas o similares.
Hay que tener en cuenta que cuando se tienen relaciones one-to-many hacia éstas entidades, se debe configurarlas como fetch=select, no como fetch=join porque si no Hibernate va a "levantar" la relación haciendo un join en lugar de intentar obtener el objeto desde el cache.

===Query Cache===
Para mejorar la performance y rendimiento de las aplicaciones podemos utilizar Query Cache.

Si lo que interesa es "cachear" el resultado exacto de una consulta, no objetos individuales. Por ejemplo, si tenemos un método en un DAO que retorna la lista de Paises registrados en la base de datos, es muy probable que siempre retorne el mismo resultado ya que esa tabla no cambia a menudo, entonces es recomendable establecer la consulta como "cacheable".

Hay que tener en cuenta que el query cache solo almacena los identificadores de los objetos del resultado, es decir que lo debemos usar combinado con el Cache de Segundo Nivel.
Los pasos serían:

#Establecer el property hibernate.cache.use_query_cache=true en el hibernate.cfg.xml
#Configurar la entidad Pais como "cacheable"
#Establecer la consulta como "cacheable":

<code java>
List paises = sess.createQuery("from Pais")
.setCacheable(true)
.list();
</code>

Por lo tanto, la primera vez que se ejecuta la consulta, se retorna la lista de Paises desde la tabla mediante un select, pero a partir de ese momento toda vez que se repita el query, el resultado va a ser retornado desde el cache, evitando la comunicación con la base de datos.

====¿Que pasa si agrego un nuevo Pais?====
Entonces el query dejaría de ser válido, solo si agregamos un nuevo Pais pasando por la session de Hibernate, el query se invalida automáticamente para que la próxima vez que se ejecute la consulta vuelva a obtener el resultado desde la base de datos.
Es importante aclarar que el comportamiento anterior no se cumple si se inserta un Pais por afuera del aplicativo, es decir con un insert directo a la tabla, o si se tiene dos aplicativos separados que apuntan a la misma base de datos, en ese caso habría que usar JNDI para que todos compartan la misma SessionFactory.

Es recomendable usar el query cache solo en los casos en que una consulta se repite constantemente y la entidad resultado no cambia frecuentemente, por ejemplo: Países, Provincias, etc.

== Ver también ==
* [[Hibernate]]
* [[Hibernate Con Spring]]
* [http://www.hibernate.org/ Web oficial de Hibernate]
* [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html#tutorial-firstapp Tutorial de Hibernate]

Cache De Hibernate

2011-09-07T12:48:10Z

Fguerra: Deshecha la edición 5881 de 89.135.83.116 (disc.)

[[Category:Hibernate]]
Uso y configuración de la funcionalidad de cache en Hibernate.

Generalmente todos los cache se basan en almacenar objetos en memoria para acelerar accesos posteriores, pero debemos aclarar que en Hibernate hay dos tipos de cache: el Primer Nivel y el Segundo Nivel.

Whoa, things just got a whole lot esaier.

===Cache de Segundo Nivel===
El Cache de Segundo Nivel permite ir varios pasos mas adelante en la mejora de la performance. La diferencia fundamental es que éste tipo de cache es válido para todas las transacciones y puede persistir en memoria durante todo el tiempo en que el aplicativo esté online, lo podríamos considerar como un cache global.

Para habilitar el Cache de Segundo Nivel hay que realizar lo siguiente:
#Seleccionar un Proveedor de Cache. Por ejemplo [[EhCache]].
#Agregar en el hibernate.cfg.xml los siguientes properties:
<property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
<property name="hibernate.cache.use_structured_entries">true</property>
#Poner en el classpath del aplicativo el archivo de configuración ehcache.xml, según las instrucciones del proveedor.
#Agregar en el mapping de las clases que se queren seleccionar como "cacheables" la siguiente entrada:
<cache usage="nonstrict-read-write"></cache>

Hibernate define cuatro niveles de cache que determinan el aislamiento:

*'''transactional''': Garantiza un nivel de aislamiento hasta repeatable read. Es el nivel más estricto. Solamente se puede utilizar en clusters, es decir, con cachés distribuidas.
*''''read-write''': Mantiene un aislamiento hasta el nivel de commited.
*'''nonstrict read-write''': No ofrece garantía de consistencia entre el caché y la base de datos. Es una es'trategia ideal para almacenar datos que no cambian habitualmente y que no sean demasiado críticos.
*'''read-only''': Es la estrategia de concurrencia menos estricta. Recomendada para datos que nunca cambian.

Otro tema importante es definir qué entidades se van a "cachear", los candidatos naturales son por ejemplo las clases que representan: provincias, países, monedas o similares.
Hay que tener en cuenta que cuando se tienen relaciones one-to-many hacia éstas entidades, se debe configurarlas como fetch=select, no como fetch=join porque si no Hibernate va a "levantar" la relación haciendo un join en lugar de intentar obtener el objeto desde el cache.

===Query Cache===
Para mejorar la performance y rendimiento de las aplicaciones podemos utilizar Query Cache.

Si lo que interesa es "cachear" el resultado exacto de una consulta, no objetos individuales. Por ejemplo, si tenemos un método en un DAO que retorna la lista de Paises registrados en la base de datos, es muy probable que siempre retorne el mismo resultado ya que esa tabla no cambia a menudo, entonces es recomendable establecer la consulta como "cacheable".

Hay que tener en cuenta que el query cache solo almacena los identificadores de los objetos del resultado, es decir que lo debemos usar combinado con el Cache de Segundo Nivel.
Los pasos serían:

#Establecer el property hibernate.cache.use_query_cache=true en el hibernate.cfg.xml
#Configurar la entidad Pais como "cacheable"
#Establecer la consulta como "cacheable":

<code java>
List paises = sess.createQuery("from Pais")
.setCacheable(true)
.list();
</code>

Por lo tanto, la primera vez que se ejecuta la consulta, se retorna la lista de Paises desde la tabla mediante un select, pero a partir de ese momento toda vez que se repita el query, el resultado va a ser retornado desde el cache, evitando la comunicación con la base de datos.

====¿Que pasa si agrego un nuevo Pais?====
Entonces el query dejaría de ser válido, solo si agregamos un nuevo Pais pasando por la session de Hibernate, el query se invalida automáticamente para que la próxima vez que se ejecute la consulta vuelva a obtener el resultado desde la base de datos.
Es importante aclarar que el comportamiento anterior no se cumple si se inserta un Pais por afuera del aplicativo, es decir con un insert directo a la tabla, o si se tiene dos aplicativos separados que apuntan a la misma base de datos, en ese caso habría que usar JNDI para que todos compartan la misma SessionFactory.

Es recomendable usar el query cache solo en los casos en que una consulta se repite constantemente y la entidad resultado no cambia frecuentemente, por ejemplo: Países, Provincias, etc.

== Ver también ==
* [[Hibernate]]
* [[Hibernate Con Spring]]
* [http://www.hibernate.org/ Web oficial de Hibernate]
* [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html#tutorial-firstapp Tutorial de Hibernate]

Actualizacion Dinamica Con Hibernate

2011-09-07T12:47:09Z

Fguerra: Deshecha la edición 6262 de 203.229.219.153 (disc.)

[[Category:Hibernate]]
[[Hibernate]], al iniciar, lee el archivo de configuracion ''hibernate.cfg.xml''. De manera predeterminada se generan y se levantan a memoria todas las sentencias de select, insert, update, delete de cada clase.

Estas sentencias son las básicas por ID.

Con respecto a los UPDATE esto presenta el inconveniente que ante un update de un solo campo del objeto, hibernate me genera el update de todos los campos del objeto.

Para las bases de datos esto es poco beneficioso ya que estamos generando mas undo (guardar en el rollback el valor anterior de los campos) del necesario.

Y pensemos lo malo que puede ser este comportamiento si ademas por el update de alguno de los campos, en la base de datos se dispara un trigger, independientemente si el valor es distinto o no.

Estaríamos generando no solo undo innecesariamente, sino que tambien estaríamos aumentando el procesamiento.

Para evitar esto Hibernate permite configurar la clase como '''dynamic-update'''

===Dynamic-Update en archivo XML===

<code xml>
<class name="Message" table="MESSAGES" dynamic-update="true">
...
</class>
</code>

===Dynamic-Update con anotaciones===

<code java>
@Entity
@org.hibernate.annotations.Entity(dynamicUpdate = true)
@Table(name="MESSAGES")
@SequenceGenerator(name="seq", sequenceName = "MESSAGES_SEQ", allocationSize=1)
public class Message {
...
}
</code>

En estas anotaciones vemos que además de usar las anotaciones estandar de JPA, estamos usando extensiones propias de Hibernate. Es el caso de la annotation Entity.

Utilizar la Entity de Hibernate no nos libra de tener que utilizar la anotación estandar Entity, ya que cada tiene funcionalidad diferente. La de Hibernate no incluye el significado de la estandar, solo la extiende.

Las annotations standard estan en la libreria ''ejb3-persistence.jar'' y para usarlas debemos importar el package ''javax.persistence.*''

Para el caso de las anotaciones propias de Hibernate se recomienda no importar el package y escribirlas completas para diferenciarlas de las estandar.

==Ver también==
* [[Hibernate]]

Cache De Hibernate

2011-09-07T12:43:27Z

Fguerra: Deshecha la edición 6263 de 58.64.172.138 (disc.)

Archivo:Imagen 5.jpg

2011-04-28T14:29:53Z

Fguerra:

Archivo:Imagen 4.jpg

2011-04-28T14:29:25Z

Fguerra:

Archivo:Imagen 3.jpg

2011-04-28T14:29:10Z

Fguerra:

Archivo:Imagen 2.jpg

2011-04-28T14:27:58Z

Fguerra:

Archivo:Imagen 1.jpg

2011-04-28T14:27:16Z

Fguerra:

BEA Aqualogic BPM 5.7 (Fuego)

2011-04-28T14:25:17Z

Fguerra:

===Comunicando con Base de Datos con PBL (Process Business Language)===

Para ejecutar comandos SQL en Aqualogic BPM 5.7 hay que seguir los siguientes pasos:

====Primer paso====

Se debe crear nuevo "External Resource", haciendo click derecho en el directorio del proyecto "External Resources", del tipo "SQL Database". Los campos se deben completar con la información de la base de datos que queremos consultar y con un nombre significativo.

====Segundo paso====

Se debe crear un nuevo "BPM Object", haciendo click derecho sobre el modulo deseado en el directorio de "Catalog", y luego crear un método en nuestro objeto, haciendo click derecho sobre el objeto y seleccionando la opción "New Method". Ahora se debe editar el nuevo método, expandiendo el objeto bpm y haciendo doble click sobre el nombre del método creado. Ahora podemos editarlo e incluir el código necesario para comunicarnos con la BD a través de una clase propia de Fuego, un ejemplo de implementación puede ser el siguiente:

<code java>
String queryAEjecutar ="SELECT campo1, campo2, campo3 FROM nombreTabla WHERE nombreColumna in (?,?)";

String nombreDeLaBDCreada = "NombreBD";

String[] arrayDeParametros = {"valor1", "valor2"};

Iterator <Any[Any]> iterator = DynamicSQL.executeQuery(sentence : queryAEjecutar, implname : nombreDeLaBDCreada, inParameters : arrayDeParametros);
</code>

Como se puede observar, el resultado de realizar la consulta va a ser un iterador, que luego puede ser recorrido con un "foreach".

<code java>
foreach (e in iterator) {

logMessage("campo1: "+e["campo1"], severity : INFO);

logMessage("campo2: "+e["campo2"], severity : INFO);

logMessage("campo3: "+e["campo3"], severity : INFO);

logMessage("nombreColumna: "+e["nombreColumna"], severity : INFO);

}
</code>

=== Versionando con CVS ===
El producto Aqualogic BPM 5.7 incluye un cliente de CVS que permite agregar, remover, actualizar en un repositorio CVS.

==== Configurar el cliente CVS ====
* Levantar el Studio BPM.
* File -> Preference ->Default Version Control
** Version Control Manger: CVS
** Host: host del servidor CVS
** User Name: usuario del CVS
** User Password: password del usuario CVS
** path: ruta dentro del repositorio donde se guardará el proyecto.

==== Subir el proyecto al CVS ====
* Levantar el Studio BPM.
* Abrir el proyecto a versionar.
* File -> Project Preference -> Project Version Control.
** Version Control Manager: CVS (nos carga la información ingresada en el punto anterior).
* File -> VCS -> Store project in repository
** Path: directorio en el que se creará el proyecto en el repositorio.
** Si es la primera vez que se sube un proyecto de Aqualogic BPM, pedirá que se ingrese la ruta del directorio donde se creará el "common catalog"
*** Common catalog: Es un catalogo de componente, el cual puede ser compartido por otros proyectos de Aqualogic BPM.
En el repositorio quedarán creados 2 directorios, el del proyecto y el del common catalog, ademas se crearán 2 alias en el CVS que apuntan al proyecto y al common catalog.

==== Obtener el proyecto del CVS ====
* Levantar el Studio BPM.
* File -> Project Preference -> Project Version Control.
* File -> Import -> Project -> from Repository.
** Version Control Manager: CVS
** En la siguiente pantalla, seleccionar el proyecto del repositorio.

==== Trabajar con proyectos versionados ====
Aqualogic BPM 5.7, posee una política restrictiva de edición para los proyecto versionados.
La política, consiste en que todo el proyecto se encuentra en modo lectura y solo un usuario puede editar un determinado archivo versionado (Ej.: un proceso).
===== Editar un procesos =====
* Seleccionar el proceso a editar.
* Menú contextual -> VCS -> edit.
Esto habilita al usuario a modificar el proceso. En caso de que exitiera otro usuario modificando el proceso nos aparecerá un mensaje de error.

===== Grabar los cambios realizados en un proceso =====
* Seleccionar el proceso que se esta editando.
* Menú contextual -> VCS -> commit.
Este paso es importante, debido a que si se libera la edición del proceso sin realizar el commit se perderán los cambios.

===== Liberar la edición del proceso =====
* Seleccionar el proceso que se esta editando.
* Menú contextual -> VCS -> unedit.

===Pasaje de Parametros===

Para pasar parámetros al proceso desde una actividad de creación (aquellas que dan inicio al proceso) que tenga asociada un ScreenFlow, hay que seguir los siguientes pasos.

El primer paso es decirle al proceso que va a recibir parametros de la siguiente manera:

* Doble click en la tarea "begin" y luego en "Argument Mapping"
[[Archivo:Imagen 1.jpg]]
* Click en el botón que parece una flecha violeta hacia abajo y ahí agregamos el nombre del parametro que va a recibir. Es recomendable utilizar nombres descriptivos ya que sino se puede volver bastante confuso.
[[Archivo:Imagen 2.jpg]]
* Ahora lo único que falta es mapear el parámetro a una variable del proceso (puede ser creada en la misma pantalla haciendo click sobre el botón que está al lado del de crear parametros)
[[Archivo:Imagen 3.jpg]]

El segundo paso es realizar un proceso similar al primer paso, con la diferencia que debe hacerce en la tarea "end" del ScreenFlow asociado a la actividad de creación.

El tercer paso es mapear las salidas del ScreenFlow con las Entradas del proceso de la siguiente manera:

* Doble click en la actividad que tiene asociada el ScreenFlow, luego en "Argument Mapping" y luego en la barra de la izquiera seleccionar "NombreDelScreenFlow Out"
[[Archivo:Imagen 4.jpg]]
* Luego solo basta con mapear los argumentos, seleccionando los nombres
[[Archivo:Imagen 5.jpg]]

===Incluir un jar y utilizarlo===
Una vez que tenemos creado nuestro proyecto BPM podemos llegar a necesitar utilizar ciertas clases de java, tanto para modelar entidades como para invocar servicios externos a nuestro proyecto.

En el caso que necesitemos incluír alguna librería al proyecto BPM los pasos a realizar son los siguientes:

* En "Recursos externos" hacer botón derecho y seleccionar la opción "Nuevo recurso externo".
* Seleccionar un nombre y en tipo seleccionar "Biblioteca de clase Java".
* Le damos clic al botón "Agregar" y buscamos el jar correspondiente que vamos a querer incluír.
* Aceptar.

Finalizado estos pasos vamos a ver que se agregó a "Recursos externos" la librería que acabamos de incluir. Lo siguiente va a ser crear un módulo desde el cual invocar a las clases de nuestro jar. Para esto tenemos que hacer lo siguiente:

* En "Catálogo" hacemos botón derecho y seleccionamos la opción "Crear módulo".
* Le ponemos un nombre y le damos Aceptar.
* Realizado esto, veremos que se agregó un módulo al Catálogo. Lo que tenemos que hacer ahora es indicarle a ese módulo que contenga la configuración de nuestro jar. Para esto hacemos clic derecho sobre el módulo > Componente de catálogo > Java.
* Seleccionamos la opción "Usar una configuración existente" (está marcada por defecto) y en el combo seleccionamos nuestro recurso externo que agregamos antes.
* Luego, seleccionaremos las clases Java que quiero incluír en mi módulo.
* Se hará la carga de clases automáticamente.
* Finalizado esto deberíamos ver dentro de "Catálogo" nuestro módulo nuevo y al amplicar su contenido ver el árbol de las clases que incluímos en él.

Para poder usar estas clases que incluímos, dentro de una actividad se podrán crear instancias de esta forma:

<code java>ClaseDeMiBiblioteca instancia = new ClaseDeMiBiblioteca();</code>

e invocar a sus métodos de esta forma:

<code java>ObjetoRespuesta respuesta = (ObjetoRespuesta) instancia.metodo(arg1 : parametroAEnviar);</code>

===Tratamiento de excepciones de servicios externos===
Puede suceder que, al momento de invocar algún servicio externo a nuestro proyecto de BPM, este retorne como respuesta una excepción. Para poder darle un comportamiento a nuestro proceso en BPM se puede utilizar una transición del tipo "Excepción" entre dos actividades.

Para dar un ejemplo concreto vamos a imaginarnos 2 actividades a las que llamaremos "Inicio" y "Comportamiento correcto". La actividad "Inicio" invocará a un servicio, y si sale todo bien, se pasará luego a la actividad "Comportamiento correcto".

[[Archivo:1.jpg]]

Ahora, puede suceder que cuando "Inicio" invoca al servicio, éste devuelva una Excepción. ¿Qué hacemos en ese caso? Creamos una actividad (en nuestro ejemplo es "Comportamiento excepción"), la cual nuestro sistema ejecutará en caso de que el servicio falle, y le asociamos una transición entre "Inicio" y esta nueva actividad de esta forma:

[[Archivo:2.jpg]]

Para crear dicha transición, debemos crear la actividad a la cual asociarla, dale doble clic y luego seleccionar como tipo de transición aquella que dice "Excepción". Para indicarle para qué tipo de Excepción queremos que se siga dicho flujo, en "Nombre de excepción" deberemos cargar la clase con la excepción que puede llegar.

=== Ver también ===
* [[Oracle BPM]]

[[Category:Oracle]]

Archivo:2.jpg

2011-04-28T14:22:09Z

Fguerra:

Archivo:1.jpg

2011-04-28T14:21:31Z

Fguerra: