Следует ли по умолчанию использовать поставщика JPA сервера приложений?

У меня есть 100% совместимое с JPA2 приложение, которое должно быть переносимо на многие серверы приложений. Быть совместимым с JPA (теоретически) означает, что мы можем переключать провайдеров JPA через конфигурацию (например, без изменения исходного кода) -- (верно???).

При запуске в контейнере сервлета (например, Tomcat, Jetty) приложение настраивается на работу с Hibernate. Мы выбираем Hibernate вместо TopLink и Eclipselink для его зрелости и производительности. Пока это работает.

Однако, при запуске в пределах сервера приложений Java EE, мы должны по умолчанию к поставщику JPA в нем, или придерживаться гибернации?

Я знаю, что в JBoss поставщик находится в спящем режиме, поэтому это, вероятно, не имеет значения. Однако я думаю, что провайдер в WebLogic-это Eclipselink. Я понятия не имею, что используют провайдеры WebSphere или Glassfish, но я видел подробные инструкции о том, как использовать Hibernate в качестве провайдера на этих серверах приложений.

Я думаю, есть другой способ спросить вопрос в том, что бы мы упустили, используя Hibernate в этих серверах приложений?

2 4
hibernate jpa-2.0 application-server

2 ответа:

У меня есть 100% совместимое с JPA2 приложение, которое должно быть переносимо на многие серверы приложений. Будучи JPA-совместимым (...) означает, что мы можем переключать провайдеров JPA через конфигурацию (...)

Да.

(...) Однако, при работе на сервере приложений Java EE, должны ли мы по умолчанию использовать поставщика JPA в нем, или придерживаться режима гибернации?

Ну, если вы развертываете на сервере Java EE 6, это не имеет особого значения. Пока не ясно, кто будет баллотироваться. приложение и вы можете, возможно, давать рекомендации, но среда выполнения на самом деле "не ваше дело" :) Также обратите внимание, что вы не можете воспользоваться поддержкой, если вы не используете поставщика по умолчанию (если это имеет значение).

Я знаю, что в JBoss поставщик находится в спящем режиме, поэтому это, вероятно, не имеет значения. Однако я думаю, что провайдер в WebLogic-это Eclipselink. Я понятия не имею, что используют провайдеры WebSphere или Glassfish, но я видел подробные инструкции о том, как использовать Hibernate в качестве поставщик внутри этих серверов приложений.

Прежде всего, имейте в виду, что JPA 2.0 является частью Java EE 6 и что GlassFish v3 является единственным контейнером Java EE 6 в настоящее время. WebLogic и WebSphere-это Java EE 5 server, они могут не поддерживать JPA 2.0.

Теперь, что касается поставщиков по умолчанию:

  • GlassFish v3 использует EclipseLink 2.0 в качестве поставщика по умолчанию, но может быть настроен на использование Hibernate 3.5 (через надстройку).

  • В Weblogic 10.3.2 поставщик JPA по умолчанию является объектом openjpa/Кодо и EclipseLink 1.2 доступна как модуль СПЕКТРОСМЕЩАЮЩИХ. В WLS 10.3.3 (еще не выпущен), EclipseLink 2.0 будет доступен как модуль WLS, по умолчанию все еще OpenJPA / Kodo. но, контейнер JPA API все равно будет JPA 1.0 ! Кажется возможным упаковать провайдера JPA 2.0 внутри вашего приложения. Смотрите этот поток и эту страницу. Но это официально не поддерживается и делать то же самое с Hibernate 3.5 может быть другой историей.

  • В WebSphere 6 и 7 поставщик по умолчанию-OpenJPA. эта ссылка даст вам некоторые сведения о том, как изменить поставщика по умолчанию (и последствия). Но большего я вам сказать не могу.

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

Как я уже упоминал, это может не поддерживаться поставщиком. Кроме того, если вы хотите максимизировать переносимость и планируете развернуть свое приложение в ближайшем будущем, переход на JPA 2.0, возможно, не является разумным выбором (или слишком оптимистичным, если вы предпочитаете).
4

Я не вижу, что вы будете упускать, если только вы не используете конкретный API реализации в своем коде JPA. Т. е. не делайте import org.hibernate нигде в вашем коде JPA,а просто напишите его против API JPA.

2