2010-10-08 2 views
2

Я реализовал веб-службу EJB3/JPA без каких-либо серьезных проблем, и теперь я перешел на веб-службу Spring-WS/JPA. Оба они развертываются в Glassfish.Конфигурация и развертывание Spring-WS и Straight-JPA (EclipseLink)

Мое понимание JPA ограничено, но по умолчанию транзакции управляются контейнерами? Как вы это измените? С EJB3 все было прямо, так как я мог просто ввести EntityManager в «DAO» (обсуждение в другое время!) С @PersistentContext, и контейнер позаботится о демаркации транзакций. Что касается базовой конфигурации, то об этом. Поскольку контейнер использует JTA, тогда я указал тип транзакции «JTA» в модуле сохранения. В моем очень простом примере приложения с одним модулем персистентности мне не нужно заботиться о его имени. Что-то усложняется, если у вас несколько единиц сохранения или контейнер позаботится об этом?

Теперь я создал равновероятную веб-службу с Spring-WS и повторно использовал свои сущности/dao, но я изо всех сил старался заставить ее работать. Я включил в свой контекст приложения определение компонента для EntityManagerFactory (LocalContainerEntityManagerFactoryBean), а также для JpaTransationManager (ссылка bean на EntityManagerFactory). Я также включил PersistenceAnnotationBeanPostProcessor и пространство имен tx. Я бы не подумал, что мне нужно будет сделать что-нибудь еще, но он не будет разворачиваться с помощью . Отсутствуют провайдеры персистентности, доступные для ошибки «null».

Должен ли я указать фактический блок непрерывности, для которого я хочу создать диспетчер?

Спасибо,

Update:

Хорошо, я получаю следующее сообщение об ошибке: javax.persistence.PersistenceException: Нет поставщика Persistence для EntityManager с именем нуль.

Это, вероятно, моя конфигурация пружины для заводского/менеджер:

<bean id="entityManagerFactory" 
    class="org.springframework.orm.jpa.LocalContainerEntityManager" /> 

<bean 
    class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" /> 

<tx:annotation-driven/> 

Я думаю, что я, возможно, потребуется или вводить что-то другое в него ...

Еще одно обновление:

Исправлено issue - Использовал LocalEntityManager вместо LocalContainerEntityManager.

Теперь у меня проблемы с сохранением моих объектов. У меня есть родительский объект с дочерним объектом как свойство. Я вижу, что дочерний объект сохраняется в журналах, когда я вызываю em.persist(parent), но родительский элемент не сохраняется.

Последнее обновление:

Родительский объект получал сохранялось, но сделка не совершил, прежде чем я пытался получить его (я насмехаясь, не издевается, так сказать). Подумайте, у меня теперь есть смешок.

+0

Теперь это совершенно другая проблема. Я предлагаю опубликовать другой вопрос (с кодом для иллюстрации проблемы и т. Д.). –

+0

Удалось исправить ошибку (см. Править). Не думал, что сейчас стоит задавать новый вопрос. – pertinky

ответ

0

My understanding of JPA is limited, but by default transactions are container managed?

В среде Java EE, объект по умолчанию менеджер типа для сессионного компонента является управляемого контейнера и сделки в области видимости.

How do you change this?

Изменить, что именно? И в каком контексте?В среде Java EE вам нужно будет использовать сессионный bean Managed Transaction (BMT) и управлять UserTransaction.

Do things get more complicated if you have multiple persistence units or will the container take care of this?

Я не уверен в этом, это может быть конкретный контейнер. Поэтому, если у вас есть несколько единиц сохранения, мой совет будет заключаться в определении unitName.

Now I've built an equivelent web service with Spring-WS (...) Do I need to specify the actual persistence unit I want to create a manager for?

Это не должно требоваться. Это article обеспечивает хороший обзор механизмов по умолчанию (возможно, это объясняется в документации тоже, но я не мог найти что-то, как сжатое):

Spring's LocalContainerEntityManagerFactoryBean loads the persistence unit configuration from the persistence unit descriptor (e.g., META-INF/persistence.xml) whose name is equivalent to the value of the persistenceUnitName property specified on this factory bean (refer to Listings 1 and 2). If a persistence unit name is not provided, the first configuration in the persistence unit descriptor is selected. The injection of the persistence manager into properties of Spring beans annotated with @PersistenceContext is handled by a special bean post-processor, which must be registered in the Spring configuration file, shown in Listing 9.

(...)

When Spring encounters a @PersistenceContext annotation on a bean property, it uses the value of the annotation's unitName attribute to locate an EntityManagerFactory -producing factory bean with a matching persistenceUnitName property value, matching against the bean ID as a fallback. If a unitName attribute is not specified in the annotation, then Spring uses the first EntityManagerFactory -producing factory bean defined in the Spring configuration. An example of using the @PersistenceContext to inject a transaction-scoped EntityManager into a Spring bean is shown in Listing 10. (If there is only a single persistence unit in your application, you can safely leave off the unitName attribute.) (...)

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

  • обновить свой вопрос с соответствующими битами конфигурации persistence.xml и Spring
  • активировать вход (в частности org.springframework.orm), чтобы увидеть, если все идет хорошо во время инициализации
  • Посмотрите, что вы получаете, когда указываете unitName
+0

Cheers fella, позже я получу соответствующие фрагменты. – pertinky