Hibernate, controlador JDBC y problema OSGi

Question

He encontrado un problema algo frustrante. Im utilizando Apache Felix como mi marco OSGi y también estoy usando Hibernate para problemas de persistencia.

Im usando la versión "paquete de osgi" de Hibernate (com.springsource.org.hibernate-3.2.6.ga.jar). Hasta donde sé, este es el Hibernate Core con algunos osgi-metdata adicionales instalados en el META-INF/MANIFEST.mf. Esta información (Package-Export y Package-Import) es vital para los sistemas osgi.

Mi problema es que el paquete de Hibernate no puede encontrar mis controladores JDBC. Se siente muy mal agregar sentencias de importación al paquete de hibernación de Springsource. Debe haber alguna forma mejor de resolver esto.

Answer 1

He encontrado similar problem hace un tiempo. La solución fue registrar paquetes jdbc-provider y jdbc-user bundles como "amigos". Esto se debe a que un paquete no puede usar clases (también los controladores jdbc) de otro sin declararlo explícitamente. Esto fue para Eclipse, así que supongo que puede ser útil.

Answer 2

¿Se hizo cargo del orden correcto de inicio del paquete? Hay una manera de establecer el nivel de inicio de cada paquete, para que su sistema pueda iniciarse correctamente. El nivel de inicio correcto de paquetes puede ser necesario si algunos activadores intentan obtener servicios directamente. En caso de que los servicios no estén disponibles, los consumidores del servicio simplemente se quedarán estancados.

Trate de establecer los niveles de inicio adecuados para sus paquetes y ver si funciona. En concreto, tendría que iniciar el paquete con los controladores JDBC primero antes del paquete de hibernación.

Otro problema podría ser que tiene algunas dependencias sin resolver. Asegúrate de que everythingg esté allí. Puede hacer esto obteniendo una consola OSGi y solicitando una lista de servicios. En Equinox esto se reduce al argumento de línea de comando de la consola y el comando "ss" seguido de "diag" en el shell de OSGi.

EDITAR (respuesta a tu comentario):

Los conductores están registerd por su interfaz. Hibernate entonces probablemente busca un controlador por su interfaz, no es necesario importar clases específicas de controladores. De todos modos, esto introduciría una dependencia no deseada en una clase específica de implementación.

Answer 3

Hibernate no es un buen ciudadano OSGi ya que muchas de las suposiciones que Hibernate hace sobre la visibilidad de clase ya no son ciertas en un contenedor OSGi.

La forma habitual de cargar los controladores JDBC con Class.forName(<jdbc class name>) no funciona dentro de OSGi porque, en este caso, Hibernate intentará cargar el controlador pero no lo encontrará ya que Hibernate no (y no debería) importar el paquete de controladores JDBC.

El administrador de controladores JDBC también intenta ser inteligente al determinar si el cargador de clases de la clase llamante debe ver el controlador y esto también entra en conflicto con OSGi.

Si utiliza Spring para configurar Hibernate, le sugiero que use la clase SimpleDriverDataSource ya que esto funciona en OSGi y Spring le permite configurar Hibernate con una fuente de datos concreta en lugar de pasar un nombre de clase que Hibernate necesita para crear instancias.

Una vez que supere ese problema, probablemente se encuentre con el problema de que Hibernate no vea sus clases de dominio. Solo tengo experiencia con el enfoque de mapeo XML, creo que es más simple en OSGi ya que creo que las anotaciones requieren un tipo de AOP de algún tipo y ese es otro punto de dolor actual con OSGi. Por el momento, a menos que use algo como Spring's dm Server, necesitará familiarizarse mucho más con el mecanismo de carga de clases de Java y cómo puede usar el enfoque de OSGi para evitar las incompatibilidades entre Java y OSGi. mundo.

Específicamente, investigue cómo las bibliotecas empresariales usan el cargador de clases de contexto y cómo puede gestionarlo. Estoy utilizando Spring dm para ajustar el código heredado en los servicios OSGi, ya que esto facilita el control del cargador de clases de contexto.

Answer 4

En un paquete OSGi solo puede ver las clases y los recursos de los paquetes que ha importado. El paquete de Hibernate no importa (y no debería) sus clases de dominio. Por lo tanto, cuando Hibernate intente procesar un archivo de mapeo XML, se quejará de que no puede encontrar la clase que se está mapeando (su clase de dominio).

Solucionamos el problema utilizando la política de amigos de Equinox, por lo que cada paquete que proporciona objetos de dominio es un compañero de clase de Hibernate. No me gusta mucho este enfoque, pero no tengo tiempo para escribir la (afortunadamente) elegante solución que está en mi cabeza.

Como dije en mi publicación anterior, manipular el cargador de clases context es probablemente la mejor apuesta a largo plazo cuando se trata de Hibernate.

Answer 5

No he probado esto (ya que soy anti-RDBMS y por lo tanto también anti-ORM), pero una solución podría ser usar fragmentos OSGi.

Cree un fragmento que contenga sus clases de dominio y especifique el paquete Hibernate como el host. Este fragmento debería exportar los paquetes de tus clases de dominio.

Del mismo modo, puede hacer lo mismo con el controlador JDBC que desea utilizar. Tome las clases de controlador y póngalas en un fragmento OSGi con Hibernate como paquete principal. Sin embargo, no tiene que exportar los paquetes del controlador ya que solo los utilizará el paquete de Hibernate.

Sospecho fragmentos no fueron apoyados en su totalidad por Felix hace 9 meses, pero sin duda son ahora lo que parece: http://osgithoughts.blogspot.com/2009/09/felix-now-fully-supports-osgi-fragments.html