
Monday February 07, 2005
Pasando de Struts 1.0.X a 1.1 y no morir en el intento.
Hace poco quise hacer unos retoques en una utilityde mi proyecto relacionada con la gestion de errores. Basicamente, queria utilizar los mensajes de error con parametros que proporciona el framework Struts y su clase ActionError, para que admitiera mensajes con un numero ilimitado de parametros.
El caso es que la version de Struts con la que trabajamos era la version 1.0.2 y, en esta version, la API de Struts te da la posibilidad de trabajar con 1,2,3 y 4 parametros pero no mas asi que... ¡Que mejor que esta ocasion para actualizarse!. Craso Error.
A los actualizadores compulsivos, a los que nunca leen las Release Notes (como yo) y a los echaos p'alante... ¡¡¡ QUIETORRRL !!!. La actualizacion no es tan sencilla como actualizar un jar por otro y puede ser bastante traumatica.
Espero que esta enumeracion de "chinitas" pueda servirle a alguien que tenga que pasar por tan traumatica experiencia:
¿ Donde esta mi jar y quien es esa gente ?
¿ Te esperas un struts.jar sencillo y facilito ? Ayyyy alma candida... a partir de la version 1.1, los de JAKARTA decidieron que habia mucho (pero mucho) utilizable dentro de Struts y ademas utilizado por muchos de sus otros proyectos. Para limitar la dependencia de estos de Struts se sacaron un conjunto de librerias de utilidades del "antiguo" Struts. Habian nacido las librerias Jakarta Commons.
Asi que, ademas de el jar de Struts ya os estais descargando e importando todas estas porque, sino, Struts no os va ni a compilar. Es como las lentejas. Si quieres lo tomas y, si no, lo dejas.
Struts es mio y depreco lo que me sale de los c******
Pues si. Y eso ha debido pensar algun guru de JAKARTA... "y lo que no quiero deprecar pero me molesta lo elimino" ... y living la vida loca. Asi que, si habeis hecho un uso mas o menos exhaustivo de Struts ya os podeis preparar para sustituir y rebuscar por la API hasta que deis con algo parecido.
Tu DataSource te lo picas tu.
Antes Struts daba soporte a un conjunto de utilidades para el acceso a Base de Datos. Ahora ya no. Y, como dicen las feministas, NO MEANS NO. No esta deprecado, ni desactualizado, ni desfasado... simplemente NO esta. Lo han quitado por si te entran tentaciones de seguir utilizandolo. En concreto, nosotros hutilizabamos el GenericDataSource y la clasecita, una vez extendida y retocada nos ha dado mucho juego. Afortunadamente, la implementacion de la misma es monolitica y hereda de javax.sql.Datasource y poco mas asi que, si lo deseais, podeis meter la clase directamente en vuestro CLASSPATH y se soluciono el problema.
LOG4J utilizaste... la cagaste
Y esto es lo mejor... Struts deja de funcionar porque no se loga bien con... ¡ tu log4j !. Si amigos, es lo bueno de utilizar la libreria Commons Logging que como encuentre log4j en tu CLASSPATH va y lo utiliza, y claro... tu que tenias tu log4j bien configurado mediante tu properties en un directorio fuera de tu CLASSPATH (porque claro, tus properties los quieres dejar fuera de un supuesto y futuro .war para que puedan ser modificados en caliente) y te curras tu Factoria de Logs que trinca el properties con un configureAndWatch y te has montado el invento del siglo y... ahora resulta que viene Struts, que se carga antes que tu aplicacion y UTILIZA PORQUE SI el log4j y... este todavia no se ha configurado y CASCOTAZO. Asi que, o te pones a hacer reingenieria inversa y averiguas como arreglas el embolao o te das cuenta de que tienes que meter el log4j en el CLASSPATH para que Struts sencillamente cargue. En dos palabras: IN-CREIBLE.
Como conclusion, que cambiar de Struts 1.0.X a 1.1 puede ser bueno pero, desde luego, ni bonito ni barato. Aun con todo, es una decision muy a tomar en cuenta porque la version 1.1 ha sido la gran revolucion a nivel de Struts y, una vez migrado a esta, no hay coste para cambiar a versiones posteriores como la 1.2. No, no me arrepiento de todo el embolao al que me han arrastrado pero, la verdad, siendo Struts un framework tan extensamente utilizado, el cambio de version me ha parecido chapuceril, agresivo y complicado. Quizas todo sea culpa mia, quizas era mi obligacion estar al tanto de todo lo que suponia cambiar de version pero, la verdad, los diseñadores de JAKARTA me tenian muy bien acostumbrado. De momento yo, con la version 1.1 voy a aguantar tooooodo lo que pueda.
(2005-02-07 21:00:45.0)
Permalink
URL de la referencia: http://weblogs.javahispano.org/dbonillaf/entry/pasando_de_struts_1_0
|
David, pues la versión 1.3 está al caer:
http://www.infonoia.com/en/content.jsp?d=inf.02.03<br/>
esta no se te puede ya resistir :)
Enviado por jerolba en February 08, 2005 a las 11:45 AM EST #
Dos cositas, si me permites ...
Primero: a mi, lo de sacar los apache-commons me parece una muy buena idea (si quiero usar algo como las Beanutils, pero no quiero nada de Struts, porque droños tengo que meter el struts.jar?). Aunque es cierto que me han invadido y "... en ocasiones veo apache-commons" :-D
Segundo: Sobre los logs, en este caso el problema no es de Struts, sino de commons-logging, que tiene una forma muy particula de elegir el sistema de logs. Yo no lo uso, porque me he creado una LogFactory a mi gusto, para ser yo el que elija el sistema de logs que necesito: te <a href="http://www.qos.ch/logging/thinkAgain.jsp">recomiendo</a> que hagas algo parecido. Ademas, que yo sepa, puedes seguir utilizando tu log4j fuera del classpath. La version 1.1 de Struts te permite implementar <a href="http://struts.apache.org/api/org/apache/struts/action/PlugIn.html">plugins</a> que se ejecutan antes de cargar la aplicacion, así que puedes configurar tus logs en ese plugin, y que struts tire de ahi...
Aún así, es cierto que el cambio de versión de Struts es un gran paso, así que quizas deberias preguntarte si merece la pena... Espero que la proxima actualización no te resulte tan <i>dolorosa</i> :D
Enviado por Keko en February 08, 2005 a las 03:24 PM EST #
Por alusiones ;) ...
1) Si, la idea de que subpaqueticen Struts es cojonuda pero... al romper tan drasticamente con la estructura de paquetes estas montando un pifostio hacia atras del copon.
2) Yo tambien utilizo mi LogFactory y extiendo del objeto Logger, el problema viene cuando NO PONES TU LOG4J en el Classpath y tu middleware LOCALIZA el log4j en el Classpath e intenta cargar su configuracion (Tomcat, JBoss, etc ...)
Enviado por David Bonilla en February 09, 2005 a las 07:49 AM EST #
Muy buenas... o mas bien malas... :-S
Desesperado empieza a ser la palabra... el problema: Struts + log4j
Vale. Introduzco en el classpath del servidor web, el path del log4j para q lo cargue antes q el resto de librerias de la aplicacion.
A esto se añade el servidor Sun One 6 (a quién se le ocurrirÃa comprar esta licencia :[ ) q no deja claro casi nada.
En fin, q sigo en el mismo punto.. ... llevo con struts (1.0) y log4j un par de años, ahora intento cambiar y casque!!
Alguien tiene alguna idea feliz de q pasa!
Enviado por Permafrost en September 26, 2005 a las 12:21 PM EDT #
Para q no haya dudas aqui muestro la traza cuando intenta desplegar el SunOne la aplicacion .war :
warning: CORE3283: stderr: log4j:WARN No appenders could be found for logger (org.apache.s
truts.util.PropertyMessageResources).
Con la version 1.0 la despliega perfectamente
Enviado por Permafrost en September 26, 2005 a las 12:31 PM EDT #