мы работаем над веб-приложением для Spring, Hibernate / JPA и Maven. У нас есть несколько модулей, которые определяют различные объекты, все на основе основного модуля, определяющего доступ к данным, и проекта веб-представления, который развертывается как война с котом.
Теперь у меня немало проблем с размещением файла persistence.xml.
На самом деле я вообще не хочу его использовать, так как я делаю все настройки hibernate (то есть jpa) внутри некоторых файлов datasource.xml, которые присутствуют во всех папках java / test / resources, а также в реальной сети. проект. Тем не менее, похоже, что hibernate все равно нужен, так как я продолжаю получать
...
Caused by: java.lang.IllegalArgumentException: Not an entity: class ....model.Customer
at org.hibernate.ejb.metamodel.MetamodelImpl.entity(MetamodelImpl.java:160)
at org.springframework.data.jpa.repository.support.JpaMetamodelEntityInformation.<init>(JpaMetamodelEntityInformation.java:58)
at org.springframework.data.jpa.repository.support.JpaPersistableEntityInformation.<init>(JpaPersistableEntityInformation.java:44)
at org.springframework.data.jpa.repository.utils.JpaClassUtils.getMetadata(JpaClassUtils.java:100)
at ...JpaProvider.init(JpaProvider.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:340)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:293)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:130)
... 58 more
для всех моих моделей.
(e.g.:)
@Entity
@Table(name="customer")
public class Customer extends AbstractPersistable<Long> {
Итак, настройки для моих пакетов следующие:
src/main/java - contains the model classes
src/main/resources - contains application context
src/test/java - contains unit tests
src/test/resources - contains test context and datasource (JPA setup)
если я поместу META-INF / persistence.xml в main / resources, все в порядке, то есть maven соберет проект, выполнив тесты, в которых hibernate автоматически создаст таблицы. Однако, так как у меня есть много модульных проектов, которые объединяются в моем веб-приложении, я получу
IllegalStateException: No single default persistence unit defined
Мой веб-проект настроен на
src/main/resources/META-INF - containing the persistence.xml being deployed to WEB-INF/classes
src/main/webapp/WEB-INF - containing web.xml, faces-config, application-context, ... being deployed to /
src/main/java - containing controller classes being deployed to WEB-INF/classes
так что это в значительной степени первая упомянутая установка здесь и должно быть в порядке.
Если в моих «модельных банках» я помещаю META-INF / persistence.xml внутри test / resources, я получаю вышеупомянутое исключение «не сущность».
Итак ... Как мне настроить мои проекты, если я хочу определить (и протестировать) объекты сущностей в моих jar-файлах "module" и использовать их все в моей войне "view"?
Спасибо, куча!
редактирование:
Выяснил причину
IllegalStateException: No single default persistence unit defined
Кажется, мне нужно назвать все единицы персистентности одинаковыми в моих модельных банках. Однако теперь мое веб-приложение жалуется на одну банку, в то время как другая в порядке, в то время как обе имеют одинаковую настройку. Я просто не могу избавиться от исключения "Не сущность".
редактировать 2:
Как ни странно, у меня теперь есть проект, который будет собирать и тестировать свои собственные модели, но при использовании внутри веб-контейнера будет жаловаться, что только эти модели не являются сущностью, в то время как второй проект с точно такой же настройкой будет работать просто хорошо. Заставь меня думать, что в моем веб-приложении что-то не так, но я просто не вижу, что.
Кто-нибудь когда-нибудь испытывал это? Я не могу найти в Google ничего полезного, которое подходит под мои настройки или предлагает подходящее решение ..
редактировать 3:
Кажется, проблема интеграции maven. В моем веб-приложении POM у меня есть следующие настройки:
<dependency>
<groupId>...</groupId>
<artifactId>view-jsf</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>...</groupId>
<artifactId>prototype</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>...</groupId>
<artifactId>security</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
view-jsf предоставляет специфичные для jsf вещи и здесь это не важно.
prototype содержит некоторые определения прототипа модели (enitity), включая менеджеров и поставщиков.
security содержит определения модели безопасности, такие как учетная запись, роль и т. Д., А также специфичные для Spring-security вещи, которые еще предстоит реализовать;)
и прототип, и безопасность также ссылаются на основные проекты, которые, в свою очередь, определяют доступ к данным, а также другие зависимости, такие как spring.
СЕЙЧАС для забавной части: если в моем веб-приложении я передвигаю защиту перед прототипом, объекты-прототипы будут нормально загружаться, а объекты безопасности будут генерировать исключение IllegalArgumentException и сообщать «Не объект». Если я поставлю прототип перед безопасностью, объекты-прототипы сгенерируют исключение.
Так что похоже, что maven переопределяет что-то одинаковое в обоих проектах, так что только второй загружается успешно. Будем расследовать дальше ...
редактировать 4:
Дальнейшее исследование показало, что проблема заключается в том, что внутри одной персистентной единицы (пример) существует несколько jar-ов, определяющих сущности JPA. Откроет новый вопрос и по этой проблеме и опубликует ссылку здесь, так как эта тема становится слишком длинной и запутанной.