Wildfly 10.0.0.Final - элемент jar-файла persistence.xml не поддерживается должным образом при использовании eclipselink

В wildfly 10.0.0.Final eclipselink не поддерживается должным образом. Конечно, спящий режим — это JPA по умолчанию, предоставляемый для wildfly, но включение модуля eclipselink поддерживается, и использование eclipselink вполне возможно. Тем не менее, элементы jar-file файла persistence.xml, по-видимому, разрешаются во время выполнения в некоторые специальные пути wildfly vfs, которые может обрабатывать hibernate, но eclipselink кажется, не знает, как обращаться.

Из того, что мне удалось отладить, и теперь я уверен, что моя конфигурация верна на 100%. Конфигурация работает для

  • wildfly + hibernate / элемент jar-file разрешается в путь vfs:/ во время выполнения
  • Элемент weblogic + eclipselink/jar-file разрешается в файл:/путь во время выполнения
  • widlfy + eclipselink / не работает - застрял с использованием элемента <class>

Я убежден, что корень проблемы в том, что eclipselink не готов работать со специальными путями vfs (виртуальной файловой системы) wildfly.

Хотя eclipselink обрабатывает те же пути vfs, что и hibernate: - Hibernate сканирует путь и находит классы сущностей - другой выходит с пустыми руками.

Я собрал следующий образец приложения. https://github.com/99sono/eclipselink-wildfly-jar-file-issue

Приложение разветвляется на два одинаковых пути.

  • Один для Weblogic,
  • другой для Wildfly.

Приложение weblogic может быть развернуто идеально. Однако в основном его можно использовать для демонстрации того, насколько «нехорошим» может быть определение элемента jar-file, в зависимости от того, выполняет ли человек: - развертывание из eclipse (например, как взорванная война) - или развертывание как настоящее приложение WAR. Скорее всего, это сводится к ошибке плагина weblogic eclipse, но, что ж... его можно заставить работать. А именно, чтобы код можно было развертывать в обоих режимах, я был вынужден использовать в качестве jar-файла значение ../lib/entities.jar, не совместимое со спецификацией JEE. это объясняется более подробно в файле readme приложения.

В любом случае, у Weblogic есть большое преимущество в использовании ваших обычных URL-адресов file:/, с которыми eclipselink отлично справляется. Таким образом, здесь есть обходной путь для этого смешанного поведения родительской папки относительного пути weblogic, связанного с тем, как приложение развертывается.

Второе приложение предназначено для wildfly. Здесь все становится тяжело. В диком виде, когда мы развертываем приложение и отлаживаем либо логику загрузки Hibernate, либо логику загрузки eclipselink, мы видим, что используются URL-адреса виртуальной файловой системы (vfs). Как сказано выше, URL-адреса vfs для jar-файлов идентичны для спящего режима и для eclipselink.

Если мы развернемся из eclipse, наши проекты будут взорваны. Они развертываются не как настоящие файлы .jar, а в развернутых каталогах.

С другой стороны, если мы развернем настоящий WAR-файл с помощью консоли управления, вместо этого наши пути будут ссылаться на каталог wildfly bin. В данном случае эти пути представляют собой 100% виртуализированные каталоги, которые невозможно открыть в нашей реальной файловой системе. Это контрастирует со сценарием, в котором мы развертываем из eclipse с помощью инструментов jboss. Путь к взорванным каталогам можно открыть в нашей файловой системе.

Что, кажется, происходит в wildfly, так это то, что: - в то время как в обоих сценариях спящий режим, кажется, может справиться с любым jar-файлом пути vfs, который встречается на пути - Eclipselink не может.

В ознакомительном файле предоставленного примера приложения содержатся некоторые подсказки относительно некоторых хороших классов для отладки развертывания.

Кто-нибудь знает об обходном пути, чтобы заставить файл jar работать с eclipselink?

Я сделал что-то не так в своем файле persistence.xml для ecipselink, и eclipselink готов обрабатывать vfs jboss?

На данный момент единственное, что работает должным образом, — это подход <class>qualified</class, но, конечно, в большинстве случаев этот подход практически бесполезен и просто помогает создать ад обслуживания.

Я искренне приветствую любую помощь в обеспечении правильной работы элемента jar-file с ecipselink 2.6.4 на wildfly 10.

Есть ли свет в конце туннеля?

С уважением


war wildfly eclipselink persistence.xml
person 99Sono    schedule 20.02.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вопрос сейчас решается.

На самом деле свойство jar-file должным образом поддерживается в wildfly 10. Проблема, с которой я столкнулся, была связана с тем фактом, что наша конфигурация модуля eclipselink была создана на основе устаревшей документации wildfly, в результате чего wildfly на тот момент, скорее всего, еще не изобрели виртуальную файловую систему, а jipijapa-eclipselink-10.0.0.Final.jar не существовало.

Однажды я увидел следующий класс hibernate, реализующий сканирование: jar:file:/C:/dev/Widlfly10/wildfly-10.0.0.Final/modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/jipijapa -hibernate5-10.0.0.Final.jar!/org/jboss/as/jpa/hibernate5/HibernateArchiveScanner.class

И этот класс гибернации принадлежит банке, поддерживаемой jboss, следующий вопрос: почему не такая банка для ссылки на затмение. Который на самом деле существует.

Таким образом, поддержка сканирования файлов vfs обеспечивается следующим образом:

<dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>jipijapa-eclipselink</artifactId>
            <version>10.0.0.Final</version>
            <scope>provided</scope>
</dependency>

И все, что нужно сделать после того, как конфигурация модуля в модулях wildfly станет подходящей, — это заставить eclipselink использовать фабрику архивов jboss:

<property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>

Все это находится в документе: https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-UsingEclipseLink

person 99Sono    schedule 23.02.2017