Los duendes de las estadísticas de WordPress.com prepararon un reporte para el año 2011 de este blog.
Aqui es un extracto
Un tren subterráneo de la ciudad de Nueva York transporta 1.200 personas. Este blog fue visto alrededor de 5.000 veces en 2011. Si fuera un tren de NY, le tomaría cerca de 4 viajes transportar tantas personas.
Buenas, aunque aparentemente no exista diferencias entre OpenJDK, y el JDK de Sun, si estamos trabajando en un entrono de desarrollo, es aconsejable tener instalado el de Sun.
Para ello, tenemos dos formas de hacerlo. Una descargarnos los binarios y ejecutarlos, o bien instalarlo desde el repositorio.
Para esta última, es necesario dar una serie de pasos antes de proceder a su instalación.
Tenemos que agregar al fichero /etc/apt/sources.list la rama non-free siendo este el resultado:
--> deb http://ftp.es.debian.org/debian/ squeeze main non-free <-- aptitude update aptitude install sun-java6-jdk
Actualizamos la lista de paquetes, que llevará unos instantes. Una vez completada la operación ya estamos preparados para instalarlo. Ahora, en caso de que tuviésemos instalado otro JDK, tenemos que especificar cual es el que queremos que este por defecto. Para ello (solo en caso de tener más de un JDK instalado):
update-alternatives --config java
De ser asi, seleccionamos el de Sun, y presionamos espacio para marcar la opción. Si queremos comprobar que todo es correcto podemos ejecutar java -version para comprobar que todo esta correcto:
usuario@maquina:/home/pier# java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
Voila!!! eso es todo, hasta la próxima 
Buscando herramientas para monitorizar Tomcat, a parte de la vista en el post anterior, he encontrado Lambda probe.
Aunque no sea tan completa en cuanto a la monitorización del rendimiento como puede ser Jconsole, aquí podemos ver otros parámetros de administración. La única peculiaridad es que es un .war . Luego para desplegarla, bastará con copiar el probe.war a la carpeta $CATALINA_HOME/webapps.
Como ya sabéis, intento ser los más claro posible para que mis post sean accesibles a todo tipos de usuarios. $CATALINA_HOME corresponde a la ruta /var/lib/tomcat6. Luego una vez descargado y descomprimido el paquete (es un .zip, yo utilizo el comando unzip de la aplicacion zip, que se instala desde los repositorios)
unzip probe.1.7b.zip cp probe.war /var/lib/tomcat6/webapps/
Le dejamos unos instantes para que se despliegue y ya podemos acceder, siendo esta la página principal.
Bueno, esto es todo. Como siempre, espero que haya sido de utilidad, hasta la próxima .
Fruto des despliegue que estaba realizando y de los problemas con la memoria asignada, no quedo mas opción que monitorizar la memoria, para ver si las “cantidades” asignadas las había tomado.
Para ello, utilizaremos Jconsole, una herramienta desarrollada por el equipo de Java con una interfaz gráfica muy amigable, que nos permite en pocos minutos comprobar la carga de la memoria, rendimiento, etc . . .
Para poder monitorizar Tomcat, es necesario añadir unas series de líneas al fichero catalina.sh, que se encuentra $CATALINA_BASE/bin. Para lo que no estén familiarizados con las variables de Tomcat, $CATALINA_BASE corresponde a /usr/share/tomcat6. Justo debajo del comienzo del script agregamos la siguiente línea (una sola línea y sin la \ ):
export CATALINA_OPTS="-Dcom.sun.management.jmxremote \-Dcom.sun.management.jmxremote.port=9004 \-Dcom.sun.management.jmxremote.ssl=false \-Dcom.sun.management.jmxremote.authenticate=false"
Reiniciamos el servicio, /etc/init.d/tomcat6 restart. Introducimos en la consola de comandos jconsole (como administrador).
En nuestro caso, como estamos ejecutándolo en local, escogemos el proceso al que pertenece Tomcat y presionamos sobre connect.
Creada la conexión esta es la pantalla principal, en la que vemos una serie de gráficas de rendimiento. El resto es cuestión de trastearlo durante unos minutillos,
Cabe mencionar que hay varias herramientas de monitorización, pero esta es la más conocida. Como podréis ver, también se puede ejecutar de forma remota, pero eso ya os lo dejo para vosotros, un saludo 
.
Cabe mencionar que hay varias herramientas de monitorización, pero esta es la más conocida. Como podréis ver, también se puede ejecutar de forma remota, pero eso ya os lo dejo para vosotros, un saludo 
.
Hola!!! seguro que a mas de uno le habrá salido en el log de Tomcat. Pues bien, en unas líneas daremos con la solución, pero antes un poquito de cultura general 
.
Bueno en primer lugar, mencionar que estoy trabajando con una máquina virtual , en la que tengo un Debian Squeeze, con JDK 1.6.0_24 de Sun. Y que el objetivo es desplegar sobre Tomcat, dos aplicaciones, Sonar, Jenkins e integrarlas. En lo referente al despliegue todo bien, pero en el momento que empezamos a analizar un proyecto (darle caña) se cuelga, y lo primero que se nos viene a la cabeza, vaya porquería el Tomcat que peta con cualquier cosa. Tras probar varias veces y ver que no se soluciona solo, lo apropiado es irnos al log ( /var/log/tomcat6/catalina.out ) y buscar el error, entonces nos encontraremos con algo parecido a esto:
java.lang.OutOfMemoryError: PermGen space
Pues bien, no hace falta ser un genio con el inglés para llegar a la conclusión de que nos hemos quedado sin memoria en la PermGen 
. Ala… palabrota, PermGen, ¿que es? pues es el espacio de memoria reservado para la máquina virtual, en la que se almacena el código estático de las aplicaciones que corren sobre el servidor. Por defecto está establecida en 64Mb y con nada que hagamos ya nos quedamos sin espacio, produciéndose una serie de errores que derivan en la caida del contenedor de aplicaciones.
La solución es tan sencilla como agregar unas líneas al script de arranque ( /etc/init.d/tomcat6 ). Localizamos la línea JAVA_OPTS y agregamos en las entre las comillas -XX:MaxPermSize=128M, siendo este el resultado:
JAVA_OPTS="-Djava.awt.headless=true -XX:MaxPermSize=128M"
Reiniciamos el servicio, y todo solucionado!!!
Hasta la próxima!
Maldito el dia en el que tuve la idea de escoger como proyecto final la suite de desarrollo de oracle (Oracle Developer Suite). Si bien es cierto que me gusta todo lo relacionado con Oracle, y que da muy bien de comer, experimentar con cualquier “programa”, por llamarlo de alguna manera, es una tarea bastante tediosa. No resulta para nada sencillo, la documentación es muy larga, no abunda y obviamente está en ingles. Lo digo por experiencia porque ya me toco integrar Oracle con un LDAP a través del Oracle Identity Mangnament, también muy divertido
Bueno al grano, la última versión de la suite de desarrollo es la 10g en concreto la 10.1.2.0.2 xD. Para ello voy a utilizar la base de datos 10g XE, que es la que está disponible desde la página de descargas de Oracle. Cabe mencionar que por aquel entonces la versión de Windows que había era el XP. He intentado desplegar el entorno sobre Windows7 con el modo de compatibilidad pero no llega a funcionar, asi que no recomiendo ni que lo intentéis. Lo mejor es montar una máquina virtual con Windows XP sp3 en mi caso he utilizado Virtual Box, que también lo recomiendo, ya que si nunca habéis trabajado con estos programas, es el que más sencillo e intuitivo resulta su manejo.
En primer lugar tenemos que tener localizados los siguientes scripts:
En mi sistema esta en la siguiente ubicación–> C:\oraclexe\app\oracle\product\repadm61\ADMIN, variara en función del ORACLE_HOME que tengáis definido. Localizados estos scripts nos logueamos como sys as sysdba y vamos lanzando los scripts:
C:\oraclexe\app\oracle\product\repadm61\ADMIN\ckqa.sql
A continuación tendremos que ir introduciendo unos parámetros que nos ira solicitando:
Enter TNS connect String for server: Enter TNS : XE (El nombre de la conexion que tenemos en el tsnames.ora) Enter password for SYS .... Enter password: **** (la contraseña del usuario sys cuando instalamos la base de datos) Enter the Repository size you wish to create. Small(S),Medium(M),Large(L) ... Enter S/M/L : S (opción "s" duración 30 min aprox) Enter datafile location and name for CONSTANT_GROW_INDEXES... Enter datafile : CGINDEXES Enter datafile location and name for CONSTANT_GROW_TABLES... Enter datafile : CGTABLES Enter datafile location and name for DEPENDENCY_INDEXES... Enter datafile : DINDEXES Enter datafile location and name for DEPENDENCY_TABLES... Enter datafile : DTABLES Enter datafile location and name for DIAGRAM_INDEXES... Enter datafile : DIAGINDEXES Enter datafile location and name for DIAGRAM_TABLES... Enter datafile : DIAGTABLES Enter datafile location and name for LOB_DATA... Enter datafile : LDATA Enter datafile location and name for RAPID_GROW_INDEXES... Enter datafile : RGINDEXES Enter datafile location and name for RAPID_GROW_TABLES... Enter datafile : RGTABLES Enter datafile location and name for SYSTEM_META_INDEXES... Enter datafile : SMINDEXES Enter datafile location and name for SYSTEM_META_TABLES... Enter datafile : SMTABLES Enter datafile location and name for TEMPORARY_INDEXES... Enter datafile : TINDEXES Enter datafile location and name for TEMPORARY_TABLES... Enter datafile : TTABLES Enter datafile location and name for VERSION_INDEXES... Enter datafile : VINDEXES Enter datafile location and name for VERSION_TABLES... Enter datafile : VTABLES Enter datafile location and name for REPOS_RBS tablespace... Enter datafile : REPRBS Enter datafile location and name for REPOS_TEMP tablespace... Enter datafile : REPTEMP For ten or more subordinate users, we recommend giving access using public synonyms. Do you wish to grant create/drop public synonym privilege to Repository Owner ? Enter Choice (Y/N) : Y
Bien seguirá haciendo de las suyas, y nos mostrara y pedazo de error de esos que pinta Oracle:
Hit enter to Continue with validation process .... SP2-0310: unable to open file "ckvalqa.sql"
Ahora tendremos que pasarle el siguiente script que es el que nos esta solicitando:
C:\oraclexe\app\oracle\product\repadm61\ADMIN\ckvalqa.sql
Con este paso lo único que hacemos es comprobar que lo de antes esta todo correcto, si nos llega a fallar tenemos que repetir el primer paso. Ahora crearemos el usuario para el repositorio, y lanzamos el último script:
create user manager_repos identified by manager; grant execute on utl_file to repos manager; C:\oraclexe\app\oracle\product\repadm61\ADMIN\ckcreate.sql
La concesión de permisos de ejecución es IMPRESCINDIBLE para que todo vaya correctamente, de lo contrario tendemos un ERROR de Oracle que deriva en catástrofe, a mi me llevó cierto tiempo dar con la solución. Mencionar según lo que he leído que ese error es propio de la versión de la versión de la base de datos que estamos usando.
Hecho esto, ya tenemos preparado el sistema para crear el repositorio. Abrimos la aplicación Repository Administration Utility. Para loguearnos no pide usuario, pass y connect string. Introducimos repos_manager, manager y XE respectivamente.
Hacemos clik en install, ok, si, si. Dejamos todo como viene por defecto y y pinchamos en start, confirmamos, y ahora nos toca unos 30 min de siesta o lo que queramos. A la vuelta veremos la siguiente ventana:
Llegados a este punto tenemos el 80% del pastel resuelto, ahora nos queda agregar el usuario al repositorio y permitir que se puedan crear áreas de trabajo.
Para poder crear work areas es suficiente con pinchar en options y despues en Enable Version Support hecho esto cuando se termine el proceso tendremos una ventana como la anterior.
Para agregar el usuario al repositorio pinchamos en Mantain Users, después en el botón con el símbolo más en verde, seleccionamos el usuario y pinchamos OK. Listo usuario agregado al repositorio .
Arrancamos el designer, en mi caso, me logueo con, designer (usuario recién agregado al repositorio), pass, XE. Solo nos queda crear un área de trabajo. Pinchamos en new, y creamos una. La seleccionamos y ya estaaaaa!!!
Ya podemos trastearlo!!! no ha sido tan difícil!!!
Si os ha sido util la entrada se agradecen comentarios!!! y si no también. Hasta la proxima
Bueno en el post anterior hemos visto como hacer para crear un proyecto de prueba en Maven, el objetivo final, era poder crear una tarea en Hudson que junto con un plugin conecta el mismo con Sonar, así poder analizar el proyecto de forma periódica. Pero como todavía falta pulir unos pequeños detalles, por ahora lo agregaremos manualmente, y de paso, veremos como se borra, que aunque parezca una tontería no esta tan a la vista.
Partimos de la base que tenemos nuestro proyecto Maven y evidentemente Sonar desplegado en la misma máquina.
Nos situamos en la raíz del proyecto, y ejecutamos:
mvn sonar:sonar
Tras ver todo el proceso debemos ver un BUILD SUCCESSFUL junto con los datos de la ejecución. Acto seguido podemos ver el resultado en la siguiente dirección http://localhost:8080/sonar.
Hasta aquí todo va bien, ahora solo nos falta poder borrar los proyctos. Para ello es necesario estar logueados como administrador. Hecho esto desde el escritorio, pinchamos sobre el proyecto que queramos borrar. Y en la barra de la izquierda pinchamos sobre Settings. Nos vamos al final de la ventana, y encontramos un boton para borrar el proyecto .
Eso es todo!!! Próximamente integración de Hudson con Sonar, hasta la próxima.
Buenas!!! Con este post crearemos en tan solo unos pasos un proyecto Maven de ejemplo del conocido “Hello world”.
Para ello es necesario que tengamos en nuestro equipo instalado Maven evidentemente. Si estamos con Windows podemos seguir este post para su instalación, o si de lo contrario estamos trabajando con Linux, bastará con instalarlo desde los repositorios.
Un aspecto importante a tener en cuenta, es que la versión de Java que tenemos que tener instalada, tiene que ser la misma que la versión de java que está utilizando Maven. Para ello ejecutamos dos comandos muy sencillos:
A continuación nos situamos en la carpeta en la que queramos crear el proyecto y ejecutamos el comando (en una sola linea):
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
Nos metemos en my-app, y comprobamos que nos ha creado la siguiente estructura:
cd my-app
my-app
|-- pom.xml
`-- src
|-- main
| `-- java
| `-- com
| `-- mycompany
| `-- app
| `-- App.java
`-- test
`-- java
`-- com
`-- mycompany
`-- app
`-- AppTest.java
Ahora solo nos queda construir el proyecto.
mvn package
Si todo sale como es debido tras pintar una serie de lineas en la pantallas que nos muestran el proceso de la ejecución podremos ver un Build Successful!!! Solo nos queda lanzar el proyecto, y ver el resultado:
java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
Voala!!! ya tenemos nuestro proyecto de prueba en Maven!!!
El post es una traducción-resumen de la página oficial.
Últimamente, para bien o para mal, ando metido en despliegues de varias aplicaciones o sistemas de testeo como hemos visto y/o iremos viendo en próximos post.
A continuación veremos una breve introducción a la aplicación Sonar y procederemos a su posterior despliegue.
Sonar es un proyecto de OpenSource que nos sirve para analizar la calidad de nuestro código Java con distintas métricas. Inicialmente solo podremos analizar proyectos construidos con Maven2.
El despliegue lo voy a realizar sobre una máquina virtual con VMware Player, con Debian Squeeze sobre Tomcat6. La versión que vamos a desplegar es la recién estrenada 2.8.
En primer lugar tenemos que instalar el JDK. Personalmente recomiendo hacerlo desde los repositorios, puesto que cuando hagamos un upgrade, se actualizará a la versión mas reciente, entre otras . . .
# aptitude install openjdk-6-jdk
Instalado el JDK instalamos el Tomcat y una serie de paquete que nos facilitara su uso.
# aptitude install tomcat6 # aptitude install tomcat6-admin
Alcanzado este punto, tenemos que decidir con que base de datos queremos conectar la aplicación. Por defecto, Sonar trae “embebida” la base de datos Apache Derby, que se recomienda solo para realizar test, de lo contrario podemos escoger entre las más comunes, MySQL, Oracle, PostgreSQL o SQLServer. Para este post voy a utilizar la conocida MySQL.
Para ello, instalamos la base de datos en si, junto con phpmyadmin, para facilitar su manejo a través de una interfaz web.
# aptitude install mysql-server # aptitude install phpmyadmin
Accedemos al panel de administración, y procedemos a crear una base de datos llamada sonar, con un usuario sonar con pass sonar con privilegios sobre la misma.
Llegados a este punto, podemos decir que ya tenemos nuestro equipo “casi” preparado para desplegar Sonar.
Nos descargamos la última versión. La descomprimimos en el directorio que prefiramos, en mi caso /opt. Damos permisos a Tomcat sobre una carpeta extensions.
# chown -R tomcat6:root /opt/sonar-2.8/extensions
Ahora tenemos que editar el fichero sonar.properties que se encuentra en el directorio conf. En concreto, lo que tenemos que hacer es comentar tres líneas, las que hacen refrencia a la base de datos Derby, y descomentar las referentes a MySQL.
# Comment the following lines to deactivate the default embedded database. #sonar.jdbc.url: jdbc:derby://localhost:1527/sonar;create=true #sonar.jdbc.driverClassName: org.apache.derby.jdbc.ClientDriver #sonar.jdbc.validationQuery: values(1) #----- MySQL 5.x/6.x # Comment the embedded database and uncomment the following properties to use MySQL. The validation query is optional. sonar.jdbc.url: jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8 sonar.jdbc.driverClassName: com.mysql.jdbc.Driver sonar.jdbc.validationQuery: select 1
Es suficiente con esto, puesto que la base de datos esta en local, y el usuario y pass de la bd, es sonar, sonar. Ahora solo nos queda lanzar el script que generará el fichero .war para desplegarlo en nuestro servidor. Para ello, nos situamos en la carpeta war, y ejecutamos el siguiente comando (tarda unos segundos, variará en función del equipo).
# sh build-war.sh
Terminada la ejecución del script, nos pinchamos aquí, nos logueamos, y pocedemos al despliegue del war.
Si todo ha salido correctamente podremos acceder a la pantalla de Sonar. Esto estodo!!! espero que haya sido de utilidad a disfrutarlo
Hola!!! si hemos estado trasteando con nuestro Jmeter, tras haberlo indicado como os indique en entrada anterior, puede que nos hayamos dado cuenta de que los graficos que “pinta” nos habremos dado cuneta de que los gráficos son prácticamente ilegibles. Para ello, googleando, di con uin pluguin muy sencillo de instalar, y que nos agrega un informe de los resultados obtenidos del test.
Para ello nos descargamos el zip, pinchando aqui. Lo descomprimimos en el directorio que prefiramos. Una ves descomprimido, observamos que la estructura es la siguiente, una carpeta lib con tres .jar, y otra carpeta ext que contiene un úlitmo .jar, cuatro en total. Es recomendable no modificar la estructura ya que serán colocados de esa misma forma en la carpeta en la que tenemos Jmeter en nuestro sistema.
Como acabo de mencionar, nos colocamos en la carpeta en la que tenemos el Jmeter en el sistema, y en la carpeta lib, agregamos los tres jar, y el que está en la carpeta ext, respectivamente. Bueno con esto, ya tenemos instalado el plugin para tener unos gráficos como la gente, ahora vamos a probarlos !!!
En primer lugar me gustaría mostrar cómo son los gráficos que podemos agregar por defecto:
Guapo no?¿ pero sobre todo fácil de entender. Ahora vamos a utilizar el que acabamos de agregar, para ello hacemos lo siguiente:
Este es el resultado:
Bueno que me contáis?¿ los gráficos hablan por sí solos . Espero que os haya sido de utilidad!!!
