Generar javadoc con UML en Eclipse, javadoc+UML+Eclipse

Una imagen vale mas que mil palabras. Aqui va la configuracion del eclipse para generar javadoc con UML incrustado usando ydoc.




Doclet name: Conservar el de la imagen
Doclet Class path: Corresponde a la ruta hasta ydoc.jar, que está en
< ydoc_install_dir>\lib

Damos a siguiente:



-docletpath: directorio con .jar o .war u otro que contenga las clases que documentaremos
-resourcepath: directorio resource de ydoc, esta en < ydoc_install_dir>\resources
-d : Directorio donde queremos que quede la documentacion generada
-umlautogen: Esta opcion indica que queremos que genere los diagramas UML

Ahora damos a Finish y listo, ya tenemos javadoc con UML incrustado

Saludos

Solucionando java.lang.OutOfMemoryError en Axis2

Bueno les dejo este dato para los que ya no pueden dormir con esta excepcion

Problema: Al invocar un Web Service muchas veces seguidas se obtiene la siguiente excepcion

org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren GRAVE: Exception invoking periodic operation: java.lang.OutOfMemoryError: Java heap..

El problema es que para cada llamada al servicio web, se crea una nueva instancia de la clase que define el servicio. Esto sucede porque en Axis2 existen distintas "Jerarquias" para administrar las sesiones de un Web Service, las cuales describo a continuación:

Request session scope

Request session scope es la sesion por defecto en Axis2. Si tu no haz tocado la configuracion de sesiones o no tenias idea que existia,  entonces tu servicio esta siendo desplegado con este tipo de sesion. En este caso la vida del servicio esta dada por el tiempo que demora la invocacion, por lo tanto, entre cada invocación no se guardan valores de atributos de ningun tipo. Es decir, si tu invocas un servicio mil veces, se crearán mil instancias de la clase del servicio con sus respectivos valores de variables de instancia.(Provocando la excepcion que nos convoca :D).
Para hacer explicita la utilizacion de este tipo de sesion hay que editar el archivo services.xml y dejarlo como sigue:

< service name="miServicio" scope="request"> ... < /service>

Soap Session scope

Soap session scope dura un poco mas que la sesion anterior, en este caso ambos, cliente y servicio deben estar habilitados para participar en una Soap Session. En este tipo de session se crea un serviceGroupId el cual es enviado al cliente en la primera conexion, mediante este id de grupo, el cliente es capaz de mantener una sesion con ese grupo de servicios. Para implementar este tipo de session, el archivo services.xml debe contener las siguientes lineas:

< service name="miServicio" scope="soapsession"> ... < /service>

Transport Session Scope

En este tipo de sesion se puede manejar la comunicacion entre distintos grupos de servicios, lo
cual no se podia realizar en la Soap Session en la cual se define un unico grupo con el cual 
interactuar.   Para implementar este tipo de session, el archivo services.xml debe quedar así:

< service name="miServicio" scope="transportsession"> ... < /service>

Y el archivo axis2.xml:

< parameter name="manageTransportSession" locked="false"> true < /parameter>

 
Application scope

Este tipo de sesion es el mas largo, y dura lo mismo que dura en funcionamiento el sistema, en este caso, se genera una sola instancia de la clase que define el Web Service, por lo tanto es lo mas conveniente en terminos de utilizacion de memoria. Para implementar este tipo de sesion, el archivo services.xml debe quedar así:

< service name="miServicio" scope="application"> ... < /service>

Solucion: La solucion a la excepcion fue (en mi caso) utilizar el tipo de sesion Application scope, con el cual puedo llamar al web service en un bucle de millones de veces sin dejar la maquina con la lengua afuera :P

Espero les sirva esta solucion. Si no entendieron revisen esta pagina en ingles