jboss - example - Acceder a Datasource desde fuera de un contenedor web(a través de JNDI)

jndi jboss

Question

Estoy tratando de acceder a una fuente de datos que se define dentro de un contenedor web (JBoss) desde un cliente gordo fuera del contenedor.

He decidido buscar la fuente de datos a través de JNDI. En realidad, mi marco de persistencia (Ibatis) hace esto.

Cuando realizo consultas siempre termino obteniendo este error:

java.lang.IllegalAccessException: Method=public abstract java.sql.Connection java.sql.Statement.getConnection() throws java.sql.SQLException does not return Serializable
Stacktrace:
org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService.doStatementMethod(WrapperDataSourceS
ervice.java:411),
org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService.invoke(WrapperDataSourceService.java
:223),
sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source),
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25),
java.lang.reflect.Method.invoke(Method.java:585),
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155),
org.jboss.mx.server.Invocation.dispatch(Invocation.java:94),
org.jboss.mx.server.Invocation.invoke(Invocation.java:86),
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264),
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659),

Mi fuente de datos:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/xxxxxDS</jndi-name>
<connection-url>jdbc:oracle:thin:@xxxxxxxxx:1521:xxxxxxx</connection-url>
<use-java-context>false</use-java-context>
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
<user-name>xxxxxxxx</user-name>
<password>xxxxxx</password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</local-tx-datasource>
</datasources>

¿Alguien tiene una pista de dónde podría venir esto?

Tal vez alguien incluso sepa una mejor manera de cómo lograr esto. ¡Cualquier pista es muy apreciada!

Aclamaciones,

Miguel

Answer 1

¿No estoy seguro si este es el mismo problema?

Configuración de JBoss DataSource

Los contenedores de DataSource no son utilizables fuera de la VM del servidor

Answer 2

@toolkit: Bueno, no exactamente. Como puedo acceder a la fuente de datos a través de JNDI, en realidad es visible y, por lo tanto, utilizable.

¿O estoy obteniendo algo totalmente incorrecto?

@Brabster: Creo que estás en el camino correcto. ¿No hay una forma de hacer la conexión serializable? Tal vez es solo un problema de configuración ...

Answer 3

@Michael Bueno, java.sql.Connection es una interfaz (podría ser técnicamente posible que la implementación concreta que recibes de JBoss sea Serializable), pero no creo que realmente tengas ninguna opción que puedas usar . Si fuera posible, probablemente sería fácil :)

Creo que @toolkit podría haber dicho las palabras correctas con utilizable fuera de la máquina virtual: los controladores JDBC hablarán con código de controlador nativo que se ejecuta en el sistema operativo subyacente, supongo, por lo que podría explicar por qué no se puede pasar una conexión a través de la red en otra parte.

Mi consejo (¡si no recibes un consejo mejor!) Sería buscar un enfoque diferente: si tienes acceso para ubicar el recurso en el directorio de JBoss, quizás implemente un objeto proxy que puedas localizar y obtener del directorio que le permite usar la conexión remotamente desde su cliente gordo. Ese es un patrón de diseño llamado objeto de transferencia de datos, creo que la entrada de Wikipedia

Answer 4

He leído sobre Ibatis ahora - tal vez usted puede hacer sus implementaciones de Dao, etc. Serializable, publicarlos en su directorio y así recuperarlos y utilizarlos en su cliente gordo? También obtendrá beneficios de reutilización de eso.

Aquí hay un ejemplo de algo similar para Wicket

Answer 5

JBoss finaliza todos los DataSources con los propios.

Eso le permite jugar trucos con el compromiso automático para obtener el comportamiento J2EE especificado de una conexión JDBC. Son en su mayoría serailizable. Pero no debes confiar en ellos.

Vería cuidadosamente sus envolturas. He escrito un sustituto para el envoltorio de envoltorios J2EE de JBoss para JDBC que funciona con OOCJNDI para que mi unidad de código DAO sea capaz de probarse de manera autónoma.

Simplemente envuelve java.sql.Driver, señala OOCJNDI en tu clase y ejecuta en JUnit.

El contenedor de controladores solo puede crear directamente un controlador SQL y delegarlo.

Devuelve un contenedor java.sql.Connection de tu propio diseño en Connect.

Un ConnectionWrapper puede simplemente envolver la conexión que su controlador de Oracle le brinda, y todo lo que hace especial es configurar el compromiso automático verdadero.

No te olvides de que Eclipse puede crear delgates para ti. Agregue un miembro al que necesite delegar, luego selecciónelo y haga clic con el botón secundario, fuente - => agregar métodos de interacción.

Esto es genial cuando te pagan por la línea ;-)

Bada-bing, Bada-boom, JUnit prueba J2EE de fábrica.

Su problema probablemente sea susceptible de lo mismo, con JUnit tachado y FatClient escrito en un crayón.

Mi FatClient utiliza RMI generado con xdoclet para hablar con el servidor J2EE, por lo que no tengo su problema.

Answer 6

Creo que la excepción indica que el objeto SQLConnection que está intentando recuperar no implementa la interfaz Serializable, por lo que no se le puede pasar de la manera que lo solicitó.

Del trabajo limitado que he hecho con JDNI, si estás pidiendo un objeto a través de JNDI, debe ser serializable. Por lo que sé, no hay forma de evitarlo, si pienso en una mejor forma de publicarlo ...

OK, una opción obvia es proporcionar un objeto serializable local al origen de datos que lo utiliza pero no tiene el origen de datos como parte de su gráfico de objetos serializables. El cliente gordo podría buscar ese objeto y consultarlo en su lugar.

O cree un servicio (web?) A través del cual se puede acceder al origen de datos; de nuevo, su cliente gordo accedería al servicio; esto sería probablemente un enfoque más encapsulado y más reutilizable si eso le preocupa.