Es innegable que trabajar con jBoss tiene innumerables ventajas, pero, en ocasiones, puede darnos una gran cantidad de quebraderos de cabeza.
Por ejemplo, cuando queremos migrar nuestras aplicaciones desde un servidor Tomcat o Weblogic a un servidor jBoss, la tarea puede complicarse tanto que es posible que estemos días tratando de solucionar el mismo problema sin poder avanzar.
Es por eso que esta entrada está dedicada a las tres (de las muchas) excepciones que más lata me dieron en su día cuando, con mi poca experiencia, traté de migrar unas aplicaciones desde Weblogic hasta jBoss.
Probablemente no sean las mejores soluciones, pero gracias a ellas logré hacer funcionar la mayor parte de mis entregables. Se aceptan vuestros comentarios con alternativas para completar esta información.
NoClassDefFoundError
Esta excepción es un clásico y, normalmente, se soluciona con simplemente añadir la librería donde se encuentra la clase no encontrada al ClassPath de nuestro entregable. La cosa se complica cuando la clase que no encuentra se encuentra en nuestra JDK, como es el caso de javax/annotation/processing/ProcessingEnvironment, que se encuentra en la librería rt.jar de la instalación de Java y debería de estarse incluyendo de forma automática.
¿Qué podemos hacer en ese caso? Si estamos completamente seguros de que nuestra variable de entorno JAVA_HOME está definida apuntando al directorio raíz de nuestra instalación de Java (en mi caso, jRockit), podemos indicarle a jBoss que nos incluya las librerías que nos están dando problemas.
Para ello, deberemos acceder al módulo sun.jdk (que se encuentra definido en JBOSS_HOME/modules/sun/jdk/main) y editar el fichero module.xml, añadiendo la siguiente línea dentro del tag <include-set>:
<path name="javax/annotation/processing"/>
Eso le indica a jBoss que debe cargar el paquete indicado, en el que se encuentra definida la clase ProcessingEnviroment. Para el resto de clases, el proceso es similar, cambiando simplemente el paquete en el que se define la clase no encontrada.
Concretamente vamos a hablar de la siguiente excepción:
javax.xml.bind.JAXBException: property "com.sun.xml.bind.defaultNamespaceRemap" is not supported
Al parecer esta excepción está causada por un conflicto con las versiones de Jaxb de CXF y la JDK6. Es por eso que la solución más sencilla es añadir un directorio llamado endorsed en el directorio lib de nuestro JAVA_HOME. En él se incluirá las librerías jaxb-api y jaxb-impl, asegurándonos de que tienen la misma versión que se utilizan en CXF.
Reiniciando nuestro servidor jBoss no debería de volver a aparecer este error.
ClassNotFoundException
Este caso, normalmente, es muy similar a la primera excepción que mencionamos, pero, al igual que en ella, se trata de un caso especial. Concretamente, se trata de la excepción:
ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DocumentImpl
Lo curioso de este caso es que se trata de una clase que se incluye en la JDK6 y, aunque la incluyamos de forma similar a la primera excepción que hemos explicado en esta entrada, no la encuentra de ninguna manera.
Al parecer esta excepción salta ya que las librerías de saaj hacen uso de la librería jaxp-ri, y en ella trata de encontrar la clase DocumentImpl, es por eso que la solución es descargar la versión más actualizada de ésta e incluirla en el mismo módulo en el que se encuentren nuestras liberías de saaj.
Como dije, quizás no sean las mejores solciones, pero son aquellas que a mí me han funcionado. Como siempre, las dudas, comentarios y opiniones, siempre que sean constructivas, son bien recibidas.
No hay comentarios:
Publicar un comentario