Доступ к источнику данных извне веб-контейнера (через JNDI)

Question

Я пытаюсь получить доступ к источнику данных, определенному в веб-контейнере (JBoss), из толстого клиента вне контейнера.

Я решил поискать источник данных через JNDI. На самом деле, моя структура постоянства (Ibatis) делает это.

При выполнении запросов я всегда получаю эту ошибку:

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),

Мой источник данных:

<?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>

Кто-нибудь знает, откуда это может быть?

Может быть, кто-то даже знает лучший способ, как этого добиться. Любые советы приветствуются!

Приветствия

Michael

Answer 1

@ Michael Ну, java.sql.Connection - это интерфейс - технически возможно, что конкретная реализация, которую вы получаете от JBoss, будет Serializable - но я не думаю, что у вас действительно будут какие-либо варианты ты можешь использовать. Если бы это было возможно, это было бы легко:)

Я думаю, @toolkit, возможно, сказал правильные слова, пригодные для использования вне виртуальной машины - драйверы JDBC будут общаться с собственным кодом драйвера, работающим в базовой ОС, я думаю, что это может объяснить, почему вы не можете просто передать соединение по сети в другом месте.

Мой совет (если вы не получите лучшего совета!) Заключается в том, чтобы найти другой подход - если у вас есть доступ для поиска ресурса в каталоге JBoss, возможно, реализуйте прокси-объект, который вы можете найти и получить из каталога, который позволяет вам использовать подключение удаленно с вашего толстого клиента. Это шаблон проектирования, называемый объектом передачи данных. Я думаю, Запись в Википедии

Answer 2

Не уверены, что это та же проблема?

Конфигурация JBoss DataSource

Оболочки DataSource не могут использоваться вне виртуальной машины сервера

Answer 3

JBoss объединяет все источники данных со своими собственными.

Это позволяет ему выполнять трюки с автоматической фиксацией, чтобы получить указанное поведение J2EE из соединения JDBC. Они в основном пригодны для сортировки. Но вам не нужно им доверять.

Я бы внимательно посмотрел на его обертки. Я написал суррогат для JBoss-оболочки J2EE-оболочек для JDBC, которая работает с OOCJNDI, чтобы получить мой автономный тестируемый модуль кода DAO.

Вы просто оборачиваете java.sql.Driver, указываете OOCJNDI на свой класс и запускаете в JUnit.

Оболочка драйвера может просто создать драйвер SQL и делегировать ему.

Верните упаковщик java.sql.Connection вашего собственного устройства для Connect.

ConnectionWrapper может просто обернуть соединение, которое дает вам драйвер Oracle, и все, что он делает особенным, это установить Autocommit true.

Не забывайте, что «Затмение» может помочь вам. Добавьте члена, которому вы хотите делегировать, затем выберите его и щелкните правой кнопкой мыши, source - => add delgage методов.

Это здорово, когда тебе платят по линии; -)

Bada-bing, Bada-boom, JUnit из коробки J2EE тестирование.

Ваша проблема, вероятно, поддается тому же самому, с вычеркнутым JUnit и написанием FatCLient карандашом.

Мой FatClient использует RMI, сгенерированный с помощью xdoclet, для связи с сервером J2EE, поэтому у меня нет вашей проблемы.

Answer 4

Я уже читал об Ibatis - может быть, вы можете сделать свои реализации Dao и т. Д. Сериализуемыми, опубликовать их в своем каталоге и получить их и использовать в своем толстом клиенте? Из этого вы также получите преимущества от повторного использования.

Вот пример чего-то похожего на Wicket

Answer 5

@ инструментарий: Ну, не совсем так. Так как я могу получить доступ к источнику данных через JNDI, он фактически видим и, следовательно, пригоден для использования.

Или я что-то не так делаю?

@ Brabster: Я думаю, что вы на правильном пути. Разве нет способа сделать сериализуемое соединение? Может быть, это просто проблема конфигурации ...

Answer 6

Я думаю, что исключение указывает на то, что объект SQLConnection, который вы пытаетесь получить, не реализует интерфейс Serializable, поэтому он не может быть передан вам так, как вы его просили.

Из ограниченной работы, которую я проделал с JDNI, если вы запрашиваете объект через JNDI, он должен быть сериализуемым. Насколько я знаю, нет пути к этому - если я подумаю о лучшем способе, я опубликую его ...

ОК, один очевидный вариант - предоставить сериализуемый объект, локальный по отношению к источнику данных, который его использует, но не имеет источника данных в качестве части своего сериализуемого графа объектов. Затем толстый клиент может найти этот объект и запросить его.

Или создайте (веб?) Службу, с помощью которой осуществляется доступ к источнику данных - снова ваш толстый клиент попадет в службу - это, вероятно, будет лучше инкапсулировано и более многократно используется, если это вас беспокоит.