Categoría: Desarrollo

Inquietudes y problemas encontrados en el desarrollo

Depurar Tomcat con IntelliJ

davidrod Deja un comentario

Vamos a describir los pasos para depurar un Tomcat con IntelliJ, por ejemplo para depurar nuestro OpenCms.

En primer lugar debemos arrancar el Tomcat en modo depuración. Una de las soluciones es modificar el script de arranque, startup.sh y añadir el parámetro jpda. Para ello en ese fichero donde pone
[code]
exec «$PRGDIR»/»$EXECUTABLE» start
[/code]
Debemos poner
[code]
exec «$PRGDIR»/»$EXECUTABLE» jpda start
[/code]

A continuación vamos a indicar al Tomcat el puerto y el modo de depuración. Un a de las opciones es añadir las variables siguientes al .bash_profile de nuestro usuario
[code]
JPDA_ADDRESS=9000
JPDA_TRANSPORT=dt_socket
export JPDA_ADDRESS
export JPDA_TRANSPORT
[/code]

Y tras rearrancar el Tomcat, desde IntelliJ, vamos «Run -> Edit configurations…» y pulsamos al «+», Tomcat Server-> Remote. Nos aparecerá una pantalla como la siguiente:
Tomcat Remoto IntelliJ

Podemos quitar en «Before Launch» el make ya que vamos a depurar directamente el código sin compilarlo, y en «Startup/Connection» debemos seleccionar el puerto que indicamos anteriormente, en este caso el 9000.
Tomcat Remoto IntelliJ

¡¡y ya podemos depurar el tomcat!!. A poner puntos de interrupción como cosacos… ^_^

Libreria Mcrypt de apache

davidrod Deja un comentario

Al instalar esta librería en Mac con un port install php53-mysql o en Ubuntu con un apt-get install php5-mcrypt, y tras reiniciar el apache a veces no nos funciona, y lo vemos porque no sale en un phpinfo o simplemente porque nos da error al cargar la librería.

El problema es que en lugar de dejar la librería mcrypt.so en el sitio por defecto donde php (por ejemplo /opt/local/lib/php/extensions/no-debug-non-zts-20090626/) va a buscarlo deja las librerías en otro directorio, /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/

La solución pasa por modificar el php.ini para añadir un directorio de extensiones. Por ejemplo en Mac sería

[code]

extension_dir=»/opt/local/lib/php53/extensions/no-debug-non-zts-20090626/»

[/code]

Otra solución es crear enlaces simbólicos según las librerías instaladas en la carpeta por defecto. Para ello hacemos un ls de la carpeta y vamos haciendo los enlaces simbólicos.

[code]

ls /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/
ln -s /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/mcrypt.so /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mcrypt.so

[/code]

Y si no nos queremos complicar nada, pues copiamos de una carpeta a otra .

[code]
cp /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/* /opt/local/lib/php/extensions/no-debug-non-zts-20090626/
[/code]

Para comprobar si funciona desde un terminal hacemos

[code]

php -m | grep mcrypt

[/code]

Y ya sólo nos queda reiniciar el apache. Si nos siguiese dando problemas, deberíamos especificar las librerías en el fichero php.ini y en las extensiones añadir

[code]
mcrypt.so
[/code]

Como siempre, espero que os sirva

Generar el war de opencms desde código fuente

davidrod Deja un comentario

Para generar el opencms.war desde el código fuente que OpenCms pone a nuestra disposición en GitHub aunque en la documentación pone que haya que hacer un «ant war» esto os generará un war sin los módulos, con lo cual el opencms se queda tan limpio que no se puede usar. Si bien podemos instalarlos desde el CmsShell mi recomendación es realizar antes del «ant war», hacer un «ant bindist» que generará los ficheros de los módulos y los incluirá en el war.

OpenCms. Compilar versión 9

davidrod Deja un comentario

Si nos costó compilar la MS 9.4.1, también cuesta la versión 9 del Github del día 28 de Enero. Aquí os dejamos una guía paso a paso.

Lo primero, bajar el eclipse para Java EE, aunque con el clásico valdría.

Lo segundo, como usa Gradle, debemos instalar el plugin para eclipse. Esta nueva versión trae en el menú->Help el Marketplace que nos permite instalar el plugin de una manera sencilla.

Después nos bajamos de github la última versión del acacia-editor, un zip que tras descomprimir debemos importar en nuestro workplace como proyecto Gradle.

Seguimos pulsando el botón derecho sobre el proyecto de acacia editor, en el menú que nos aparece, elegimos «Gradle->Refresh Dependencies». Esto nos descargará las librerías necesarias para su compilación.

A continuación, os recomiendo activar la vista «Gradle Task», en el menú->Window->Show view->other …y en Gradle la tenemos. Así podemos lanzar fácilmente las compilaciones. Lanzamos la tarea «clean» y luego la tarea «install». Todo debería ir bien aunque aparezca algún mensaje de error.

A continuación bajamos el minestrone 9.4.1 de opencms, descomprimimos el zip y lo importamos en nuestro workplace como proyecto Gradle.

Debemos hacer un pequeño cambio en el fichero dependencias.gradle ya que no le gusta la librería gwt-dev.  Debemos pulsando con el botón derecho en el proyecto importado de opencms, en «Java Build Path», en «Libraries» añadimos la librería buscándola en la carpeta lib, y luego compile.

Ya casi terminando, con el botón derecho sobre el proyecto de opencms, en el menú que nos aparece, elegimos «Gradle->Refresh Dependencies»

Con todos estos pasos, ya podríamos ejecutar en la ventana de «Gradle Task» la tarea «bindist» y no debería darnos problemas en generar en la carpeta «BuildCms/distributions» un opencms.war perfecto.

Espero que os sirva y muchas gracias a Montse por la ayuda, que esto debería estar contándolo ella ^_^

OpenCms. Compilar Milestone 9.4.1

davidrod Deja un comentario

Llevamos unos días peleándo con la compilación para generar el war con los módulos del Opencms MS 9.4.1. Aquí os dejamos una guía paso a paso.

Lo primero, bajar el eclipse para Java EE, aunque con el clásico valdría.

Lo segundo, como usa Gradle, debemos instalar el plugin para eclipse. Esta nueva versión trae en el menú->Help el Marketplace que nos permite instalar el plugin de una manera sencilla.

Después nos bajamos de github la última versión del acacia-editor, un zip que tras descomprimir debemos importar en nuestro workplace como proyecto Gradle.

Seguimos pulsando el botón derecho sobre el proyecto de acacia editor, en el menú que nos aparece, elegimos «Gradle->Refresh Dependencies». Esto nos descargará las librerías necesarias para su compilación.

A continuación, os recomiendo activar la vista «Gradle Task», en el menú->Window->Show view->other …y en Gradle la tenemos. Así podemos lanzar fácilmente las compilaciones. Lanzamos la tarea «clean» y luego la tarea «install». Todo debería ir bien aunque aparezca algún mensaje de error.

A continuación bajamos el minestrone 9.4.1 de opencms, descomprimimos el zip y lo importamos en nuestro workplace como proyecto Gradle.

Debemos hacer un pequeño cambio en el fichero dependencias.gradle ya que no le gusta la librería server-api.  Debemos comentar la línea «compile group: ‘javax.servlet’, name: ‘servlet-api’, version: ‘2.4’» y añadir a continuación «compile files(‘lib/compile/servlet-api.jar’)».

A continuación, pulsando con el botón derecho en el proyecto importado de opencms, en «Java Build Path», en «Libraries» añadimos la librería buscándola en la carpeta lob, y luego compile.

Ya casi terminando, con el botón derecho sobre el proyecto de opencms, en el menú que nos aparece, elegimos «Gradle->Refresh Dependencies»

Con todos estos pasos, ya podríamos ejecutar en la ventana de «Gradle Task» la tarea «bindist» y no debería darnos problemas en generar en la carpeta «BuildCms/distributions» un opencms.war perfecto.

Espero que os sirva y muchas gracias a Montse por la ayuda.

 

NOTA: Si durante la compilación os da problemas de «Java Heap Space» debéis cambiar en el fichero «grade.properties» el valor «max_heap_size» a un valor mas alto. Yo tengo puesto «max_heap_size=4096m»

Cambiar tipo mime de un fichero

charly Deja un comentario

Recientemente me ha pasado que algún editor modifica la codificación de un fichero como consecuencia si yo tengo un fichero .php que muestre una palabra con acentos y el encoding del fichero no coincide con el encoding que yo le estoy diciendo en el «meta»…pues problema al canto y caracteres raros por ahí…

El encoding se puede solucionar guardando el fichero en el encoding apropiado (algunos editores soportan esta opción) pero para linux (Mac) esta es la solución más sencilla que he encontrado.

Solución en linux:

Para identificar que encoding tiene un fichero concreto:

[code] $file –mime nombrefichero.php [/code]

Esto nos produce una salida…

[code] nombrefichero.php:         text/plain; charset=iso-8859-1[/code]

Para reconvertir al formato que deseamos por ejemplo a utf-8:

[code]  iconv -f iso-8859-1 -t utf-8 nombrefichero.php > nombrefichero_utf8.php[/code]

 

*NOTA: cuidado con intentar encodear un fichero formato ascii a utf-8 porque ascii ya es utf-8 por lo que la reconversión no se lleva a cabo.

OpenCms no permite mas de 100 elementos en un contenedor

davidrod Deja un comentario

Si intentáis meter más de 100 contenidos en un contenedor mediante ADE veréis que al pasar de 100 al meter uno nuevo el último desaparece.

Esto es así porque en OpenCms lo han decidido, pero siempre podemos tunearlo cambiando el código si somos valientes:
[code]
public static final String DEFAULT_MAX_ELEMENTS = «100»;
[/code]
dentro de org.opencms.jsp.CmsJspTagContainer

aunque la opción más sencilla es definir en el contenedor el parámetro «maxElements» con un número mayor que 100:
[code]
cms:container name=»leftcontainer» type=»column» width=»230″ maxElements=»200″
[/code]

Directiva trim whitespaces

charly Deja un comentario

En ocasiones el uso de etiquetas de terceros o la iteración masiva en bucles hace que se introduzcan muchos espacios inecesarios que pueden hacer que el tamaño de nuestras páginas crezca de forma innecesaria, afortunadamente desde la especificación JSP 2.1 existe una directiva para eliminar todos estos espacios innecesarios.

La solución inmediata en un jsp sería:
[code]<@ page trimDirectiveWhitespaces="true" >[code]
Si queremos generalizarlo En el web.xml de  nuestra aplicación podemos hacer que se aplique a determinados patrones.

<jsp-config>
 <jsp-property-group>
  <url-pattern>*.jsp</url-pattern>
  <trim-directive-whitespaces>true</trim-directive-whitespaces>
 </jsp-property-group>
</jsp-config>