Лучшая практика применения Jakarta ee: следует ли использовать реализации с указанием контейнера c? - PullRequest
Новая
       6

Лучшая практика применения Jakarta ee: следует ли использовать реализации с указанием контейнера c?

0 голосов
/ 06 марта 2020

Я создаю свой первый Jakarta ee 8 App. На самом деле я пришел из среды Spring-Framework, поэтому я сосредоточился на ключевых различиях и лучших практиках. Я читал, что Glassfi sh, Wildfly, JBoss EAP et c. обеспечить реализацию спецификаций Jakarta ee. Это подняло вопрос: 

Would the application be dependent on the server it runs on? If an upgrade or change of the application server is necessary, should one consider incompatibility bugs?

Я сделаю вопрос более конкретным, используя следующий пример.

Я создал две версии веб-приложения с помощью JAX-RS. Он работает на JBoss EAP 7.2.2. Первый файл pom выглядит как 

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>8.0.0</version>
  <scope>provided</scope>
</dependency>

Второй файл pom 

<dependencyManagement>
   <dependencies>
     <dependency>
        <groupId>org.wildfly.bom</groupId>
        <artifactId>wildfly-jakartaee8-with-tools</artifactId>
        <version>${version.jboss.bom}</version>
        <type>pom</type>
        <scope>import</scope>
     </dependency>
   </dependencies>
</dependencyManagement>
....
<dependency>
   <groupId>org.jboss.spec.javax.ws.rs</groupId>
   <artifactId>jboss-jaxrs-api_2.1_spec</artifactId>
   <scope>provided</scope>
</dependency>

По следующей ссылке>: http://www.mastertheboss.com/javaee/jakarta-ee/getting-started-with-jakarta-ee, следует использовать второй помп , если вы хотите использовать расширения Wildfly для Jakarta ee.

Запуск вышеуказанных приложений на

  • JBoss EAP -> EasyREST (JBoss реализация JAX-RS) вступит в игру.
  • Glassfi sh -> Будет использоваться Джерси. Приложение 2 не будет запущено?
  • В Tomcat -> оба не работают, потому что реализация не предусмотрена.

Я знаю, что могу включить спецификацию c JAX-RS библиотека в моем pom как зависимость и запуск независимый от контейнера. Но если бы я работал на сервере приложений предприятия, таком как JBoss EAP или Glassfi sh, это было бы наилучшей практикой? В то же время я все еще думаю о переносимости сервера.

Примечание: Я думаю, что когда мы применяем подход, включающий все реализации как явные зависимости в WAR (например, определенную версию easyrest или Jersey) ), тогда следует подумать о переходе на более легкий контейнер сервлетов, например Tomcat, поскольку было бы бесполезно работать на сервере приложений Exnterprise без использования его функций. Я говорю здесь о примере JAX-RS. Конечно, когда требуются другие функции J2EE, например, EJB-компоненты tomcat, будут исключены

1 Ответ

1 голос
/ 08 марта 2020

Всякий раз, когда вы используете специфичные для поставщика функции c, такие как зависимости RESTEasy для WildFly, вы не можете легко перенести ваше приложение на другой сервер приложений (например, Payara / Glassfish / Open Liberty).

В качестве передового опыта просто начните с зависимости Jakarta EE API: 

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>8.0.0</version>
  <scope>provided</scope>
</dependency>

Это включает в себя спецификацию JAX-RS 2.1, которую все серверы приложений поддерживают вне коробка. Если вы просто используете это, вы сможете легко перенести ваше приложение на другой сервер.

Спецификация JAX-RS 2.1 охватывает множество функций, которых, скорее всего, достаточно.

Могут быть некоторые крайние случаи, когда спецификация не предоставляет простого в использовании решения, и вы можете захотеть включить специфичные для поставщика реализации c, которые не являются частью формального JAX-RS Спецификация.

Хорошим примером является отсутствие поддержки MultiPart данных JAX-RS, например, для загрузки файлов на сервер. RESTEasy предоставляет решение для этого, если вы импортируете в свой проект Maven следующее: 

<dependency>
  <groupId>org.jboss.resteasy</groupId>
  <artifactId>resteasy-multipart-provider</artifactId>
  <version>3.6.3.Final</version>
  <scope>provided</scope>
</dependency>

Недостатком здесь является то, что если вы используете какой-либо импорт, который не приходит из javax.ws.rs / jakarta.ws.rs, вы вы используете что-то, выходящее за рамки спецификации.

С другой стороны, вам также следует подумать о вероятности переключения сервера приложений.

ОБНОВЛЕНИЕ:

Что если, например, в обновленной реализации сервера все еще нет ошибок?

Никто не знает, не содержит ли реализация ошибок. Вы все еще должны запланировать некоторое время для проверки / тестирования при обновлении версии вашего сервера. Это также верно, если вы полагаетесь на простую Джакарту EE 8 spe c. В общем, производители серверов также тратят время на тестирование всего (имея большой набор тестов) и, возможно, уже найдут исправления некоторых ошибок. Но тем не менее, вы не можете быть на 100% уверены, что после обновления сервера все работает без ошибок.

Говоря об ошибках после обновления сервера приложений и JAX-RS, у меня был один с Payara, где все мои фильтры запросов JAX-RS выполнялись дважды для входящего запроса.

И, кстати. Вы не должны принимать Tomcat во внимание. Tomcat - это просто контейнер сервлетов, а не полностью совместимый с Jakarta EE сервер приложений. На домашней странице Jakarta EE вы можете просмотреть все Jakarta EE 8 совместимых серверов .

...