[Hibernate] MappingException: property mapping has wrong number of columns

Ésta es una entrada rápida para evitar perder dos días de trabajo como me ha ocurrido. Sé que hacía mucho que no escribía, pero esta nota debe ser recordada, ya que lo que no se apunta, se olvida.

En un proyecto que hace uso de Hibernate para persistir datos en una base de datos PostgreSQL desde clases Java, estaba obteniendo la excepción "MappingException: property mapping has wrong number of columns" a la hora de crear los bean de los objetos mapeados.

Buscando en internet, aparecen decenas de entradas en blogs y foros diciendo que ese error aparece en casos en los que el mapeo es erróneo, y bien en la clase que se muestra en la excepción se han declarado atributos del tipo java.lang.Object o bien están definidos en el XML del mapeo como Object (ambas cosas no son soportadas por Hibernate, por lo visto).

Al estar haciendo el mapeo a través de anotaciones, la segunda opción estaba descartada y, tras revisar numerosas veces la clase en cuestión, la primera no tenía sentido...

Lo que no vi mencionar en ningún sitio es que debía poner estas anotaciones en la declaración de los atributos y no en el método getter, que normalmente es como lo había hecho. No sé si se trata de algo puntual debido a la configuración de mi proyecto o no, pero la cuestión es que se solucionó al cambiar esto:

        private String mmpIdParametro;

@Id
@Column(name = "COLUMNA", unique = true, nullable = false, length = 64)
public String getColumna() {
return this.mmpIdParametro;
}

Por esto:

        @Id
@Column(name = "COLUMNA", unique = true, nullable = false, length = 64)
        private String mmpIdParametro;

public String getColumna() {
return this.mmpIdParametro;
}

No sé si esto servirá a alguien más, pero si le puedo ahorrar a tan solo una persona el trago de perder 2 días de trabajo por semejante chorrada, me doy por satisfecho.

jBoss - Tres excepciones, tres soluciones

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.

javax.xml.bind.JAXBException

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.