Nablarch 5から6への移行ガイド¶

Java EEの依存関係をJakarta EEに変更する¶

Java EEのAPIの依存関係(dependency)を、Jakarta EEのものに変更する必要がある。 例えば代表的なものとしては、Java Servletなどが挙げられる。

ただ、Java EEのAPIの dependency は、jarの提供元やバージョンによってバラバラになっており統一されていない。 このため、 groupId などから機械的に判断することはできない。 どの dependency がJava EEのAPIなのかは、 groupId や artifactId 、jarの中に含まれるクラスなどから判断しなければならない。

参考までに、Nablarchが提供しているアーキタイプやExampleでの変更内容を以下に記載する。 なお、ExampleではJakarta EEが提供しているBOMを読み込むことで、個別にバージョンを指定しないようにしている。 バージョンを調べる手間や指定のミスが減り管理も楽になるため、BOMを読み込むことを推奨する。

<dependencyManagement>
  <dependencies>
    ...
    <dependency>
      <groupId>jakarta.platform</groupId>
      <artifactId>jakarta.jakartaee-bom</artifactId>
      <version>10.0.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

また、ここで記載されていない依存関係を変更するための参考として、本ページ末尾の付録に Java EEとJakarta EEの仕様の対応表 を記載する。 Jakarta EEでの dependency が何になるかは各仕様のページに記載されているので、そちらも参考にすること。 （例えば Jakarta Servlet 6.0 の仕様のページ (外部サイト、英語) には、「Maven coordinates」のところに jakarta.servlet:jakarta.servlet-api:jar:6.0.0 と記載されている）

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>...</version>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>jakarta.servlet</groupId>
  <artifactId>jakarta.servlet-api</artifactId>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>javax.servlet.jsp</groupId>
  <artifactId>javax.servlet.jsp-api</artifactId>
  <version>...</version>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>jakarta.servlet.jsp</groupId>
  <artifactId>jakarta.servlet.jsp-api</artifactId>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>javax.servlet.jsp.jstl</groupId>
  <artifactId>javax.servlet.jsp.jstl-api</artifactId>
  <version>...</version>
</dependency>

<dependency>
  <groupId>jakarta.servlet.jsp.jstl</groupId>
  <artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
</dependency>

<dependency>
  <groupId>org.apache.geronimo.specs</groupId>
  <artifactId>geronimo-jpa_2.0_spec</artifactId>
  <version>...</version>
</dependency>

<dependency>
  <groupId>jakarta.persistence</groupId>
  <artifactId>jakarta.persistence-api</artifactId>
</dependency>

<dependency>
  <groupId>javax.ws.rs</groupId>
  <artifactId>javax.ws.rs-api</artifactId>
  <version>...</version>
</dependency>

<dependency>
  <groupId>jakarta.ws.rs</groupId>
  <artifactId>jakarta.ws.rs-api</artifactId>
</dependency>

<dependency>
  <groupId>javax.annotation</groupId>
  <artifactId>javax.annotation-api</artifactId>
  <version>...</version>
</dependency>

<dependency>
  <groupId>jakarta.annotation</groupId>
  <artifactId>jakarta.annotation-api</artifactId>
</dependency>

Java EE仕様の実装ライブラリを更新する¶

Java EE仕様の実装ライブラリをアプリケーションに組み込んでいる場合は、これらをJakarta EEのものに置き換える。

どの dependency がJava EE仕様の実装ライブラリであるのかは、それぞれの dependency ごとに個別に調査する必要がある。 また、Java EE仕様の実装ライブラリであることが分かった場合、Jakarta EE対応版の dependency が何になるかは実装ライブラリごとに異なる。 したがって、プロジェクトで使用している実装ライブラリごとに公式サイトなどを確認する必要がある。

参考までに、Nablarchが提供しているアーキタイプやExampleでの変更内容を以下に記載する。

また、Jakarta EEの各仕様のページでも互換実装が紹介されているので、そちらも参考にすること。 (例えば、 Jakarta RESTful Web Services 3.1 の仕様のページ (外部サイト、英語) では、互換実装として Eclipse Jersey 3.1.0 が紹介されている)

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-validator</artifactId>
  <version>5.3.6.Final</version>
</dependency>

<dependency>
  <groupId>org.hibernate.validator</groupId>
  <artifactId>hibernate-validator</artifactId>
  <version>8.0.0.Final</version>
</dependency>

<dependency>
  <groupId>taglibs</groupId>
  <artifactId>standard</artifactId>
  <version>...</version>
</dependency>

<dependency>
  <groupId>org.glassfish.web</groupId>
  <artifactId>jakarta.servlet.jsp.jstl</artifactId>
  <version>3.0.0</version>
</dependency>

<dependencyManagement>
  <dependencies>
    ...
    <dependency>
      <groupId>org.glassfish.jersey</groupId>
      <artifactId>jersey-bom</artifactId>
      <version>...</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependency>
  <groupId>org.glassfish.jersey.media</groupId>
  <artifactId>jersey-media-json-jackson</artifactId>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.core</groupId>
  <artifactId>jersey-client</artifactId>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.inject</groupId>
  <artifactId>jersey-hk2</artifactId>
</dependency>

<dependencyManagement>
  <dependencies>
    ...
    <dependency>
      <groupId>org.glassfish.jersey</groupId>
      <artifactId>jersey-bom</artifactId>
      <version>3.1.1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependency>
  <groupId>org.glassfish.jersey.media</groupId>
  <artifactId>jersey-media-json-jackson</artifactId>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.core</groupId>
  <artifactId>jersey-client</artifactId>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.inject</groupId>
  <artifactId>jersey-hk2</artifactId>
</dependency>

<dependency>
  <groupId>org.apache.activemq</groupId>
  <artifactId>activemq-all</artifactId>
  <version>...</version>
</dependency>

<dependency>
  <groupId>org.apache.activemq</groupId>
  <artifactId>artemis-server</artifactId>
  <version>2.28.0</version>
</dependency>
<dependency>
  <groupId>org.apache.activemq</groupId>
  <artifactId>artemis-jakarta-server</artifactId>
  <version>2.28.0</version>
</dependency>
<dependency>
  <groupId>org.apache.activemq</groupId>
  <artifactId>artemis-jakarta-client</artifactId>
  <version>2.28.0</version>
</dependency>

gsp-dba-maven-pluginを更新する¶

nablarch-example-webをはじめ、アーキタイプから作ったプロジェクトには gsp-dba-maven-plugin (外部サイト) があらかじめ組み込まれている。 このプラグインは、データベーステーブルのメタデータからJavaのエンティティクラスを生成する機能(generate-entity)を提供している。 このエンティティクラスにはJPAなどのJava EEのアノテーションが設定されるため、そのままではJakarta EE環境で使用できない。

gsp-dba-maven-pluginは5.0.0でJakarta EE対応が入ったので、 pom.xml でgsp-dba-maven-pluginの <version> を変更する。

<plugin>
  <groupId>jp.co.tis.gsp</groupId>
  <artifactId>gsp-dba-maven-plugin</artifactId>
  <version>5.0.0</version>
  <configuration>
  ...

さらに、Jakarta EE対応されたgsp-dba-maven-pluginの generate-entity を使うためには、 dependency やJVM引数の追加が必要となる。 詳細については gsp-dba-maven-pluginのガイド (外部サイト) を参照のこと。

以上で、Jakarta EEのアノテーションが設定されたエンティティが生成されるようになる。

waitt-maven-pluginをjetty-ee10-maven-pluginに変更する¶

nablarch-example-webをはじめ、アーキタイプから作ったウェブアプリケーションのプロジェクトには waitt-maven-plugin (外部サイト、英語) があらかじめ組み込まれている。 このプラグインは、プロジェクトのコードを組み込みサーバ(Tomcatなど)にデプロイして簡単に実行できる機能を提供している。 しかし、このプラグインはJakarta EE対応がされていないので、同様の機能を提供していてJakarta EEにも対応しているjetty-ee10-maven-pluginに変更する。

修正前、nablarch-example-webでは以下のようにwaitt-maven-pluginが pom.xml に設定されている。

修正前

<plugin>
  <groupId>net.unit8.waitt</groupId>
  <artifactId>waitt-maven-plugin</artifactId>
  <version>1.2.3</version>
  <configuration>
    <servers>
      <server>
        <groupId>net.unit8.waitt.server</groupId>
        <artifactId>waitt-tomcat8</artifactId>
        <version>1.2.3</version>
      </server>
    </servers>
  </configuration>
</plugin>

これを、以下のようにしてjetty-ee10-maven-pluginに変更する。

修正後

<plugin>
  <groupId>org.eclipse.jetty.ee10</groupId>
  <artifactId>jetty-ee10-maven-plugin</artifactId>
  <version>12.0.3</version>
</plugin>

これで、アプリケーションのコードをJettyにデプロイして実行できるようになる。

実際に動かしたい場合は、以下のコマンドでJettyを起動できる。

mvn jetty:run

nablarch-testing-jetty6をnablarch-testing-jetty12に変更する¶

ウェブアプリケーションのプロジェクトでNTF (Nablarch Testing Framework)を使用している場合、JUnitのテストで組み込みサーバを実行するために nablarch-testing-jetty6 というモジュールを使用する。 このモジュールで起動するJetty 6はJakarta EEに対応していない。 JettyがJakarta EE 10に対応したのはJetty 12なので、Jetty 12を起動できる nablarch-testing-jetty12 を使うように変更する必要がある。

まずは、 pom.xml を以下のように修正する。

<dependency>
  <groupId>com.nablarch.framework</groupId>
  <artifactId>nablarch-testing-jetty12</artifactId> <!-- artifactId を nablarch-testing-jetty12 に変更する -->
  <scope>test</scope>
</dependency>

次に、 HttpServerFactory のコンポーネントを定義している部分を以下のように修正する。

修正前

<component name="httpServerFactory" class="nablarch.fw.web.httpserver.HttpServerFactoryJetty6"/>

修正後

<component name="httpServerFactory" class="nablarch.fw.web.httpserver.HttpServerFactoryJetty12"/>

nablarch-example-webの場合は、 src/test/resources/unit-test.xml に上記設定が存在する。

以上で、NTF実行時に起動される組み込みサーバがJakarta EE対応版に切り替わる。

javax名前空間をjakarta名前空間に変更する¶

Jakarta EE 9で入った名前空間の変更の対応を、アプリケーションのコードにも実施する。 名前空間の変更対応の大まかな流れを以下に記載する。

1. javax 名前空間で import している部分等がコンパイルエラーになるため、 jakarta 名前空間に変更する
2. コンパイルエラーにならない場所を対応するため、プロジェクト全体を javax でGrep検索する
3. 検索で見つかった箇所に関して、Java EEの名前空間かどうか判定する
4. Java EEの名前空間である場合は、 javax を jakarta に置換する

以下で、詳細について説明する。

javax の記述は、多くの場合はJavaソースコード上の import 文に現れる。 ここまでの修正でJava EEの依存関係がなくなりJakarta EEの依存関係に置き換わっているため、 javax 名前空間で import している部分はコンパイルエラーが発生するようになっている。 そのため、まずはコンパイルエラーが発生している箇所を確認し、 jakarta 名前空間に変更する。

しかし、 javax が現れるのは import 文だけとは限らず、コンパイルエラーにならない場所にも存在する可能性がある。 たとえば、Java Servletでフォワード元のリクエストURIを取得するためのキー javax.servlet.forward.request_uri は文字列で指定するため、コンパイルエラーにはならない（このキーは、Jakarta Servletでは jakarta.servlet.forward.request_uri に変える必要がある）。 他にも、JSPや設定ファイルの中に記述されている場合も、コンパイルエラーにはならないが修正対象となる。

したがって javax 名前空間の有無を調査するには、プロジェクト全体に対してGrep検索を行わなければならない。

次に、 javax で検索にヒットした箇所について、それが本当にJava EEの名前空間であるかどうかを判定する。 例えば、nablarch-example-webを javax で検索すると、以下のような記述がヒットする。

import javax.validation.ConstraintValidator;

これは、Bean Validationのクラスを import している箇所なので、Java EEの名前空間と判断できる。

一方で、以下のような記述もヒットする。

import javax.crypto.SecretKeyFactory;

これは標準ライブラリに含まれる暗号処理に関するクラスを import している箇所になるので、Java EEの名前空間ではない。

このように、 javax でヒットしたからといって、それらが全てJava EEの名前空間とは一概には判断できない。 本ページ付録の Java EEとJakarta EEの仕様の対応表 に各仕様の名前空間を記載しているので、これを参考にヒットした javax がJava EEのものか判断すること。

Java EEの名前空間であると判断できた場合は、 javax の部分を jakarta に置換する。 以下は、前述の import を jakarta に置換した場合の例になる。

import jakarta.validation.ConstraintValidator;

XMLスキーマ指定をJakarta EE 10のスキーマに変更する¶

web.xml 等のXMLファイルではXMLスキーマを指定しているが、これをJakarta EE 10に対応したスキーマに変更する。 Jakarta EE 10で提供されているスキーマは、 Jakarta EE XML Schemas (外部サイト、英語) で確認できる。

修正前

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
         http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

修正後

<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
                             web-app_6_0.xsd"
         version="6.0">

タグライブラリのネームスペースをJakarta EE 10のネームスペースに変更する¶

JSPファイルでは taglib ディレクティブでタグライブラリのネームスペースを指定しているが、これをJakarta EE 10に対応したネームスペースに変更する。 Jakarta EE 10で提供されているネームスペースは、 Jakarta Standard Tag Library 3.0 (外部サイト、英語) で確認できる。

修正前

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

修正後

<%@ taglib prefix="c" uri="jakarta.tags.core" %>

NoClassDefFoundErrorになる場合¶

org.jboss.weld.exceptions.WeldException
    at org.jboss.weld.executor.AbstractExecutorServices.checkForExceptions (AbstractExecutorServices.java:82)
    ...
Caused by: java.lang.NoClassDefFoundError
    at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method)
    ...
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jboss.weld.logging.BeanLogger
    at org.jboss.weld.util.Beans.getBeanConstructor (Beans.java:279)

実行時に上記のようなスタックトレースが出力されてエラーになる場合、クラスパスの順序において slf4j-nablarch-adaptor をLogbackより後にすることでエラーを解消できる。 Mavenで実行する場合は、 pom.xml 上の slf4j-nablarch-adaptor の位置をLogbackより下に配置することで順序を変更できる。

<dependency>
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.2.4</version>
</dependency>

<!-- Logbackより下にslf4j-nablarch-adaptorを配置する -->
<dependency>
  <groupId>com.nablarch.integration</groupId>
  <artifactId>slf4j-nablarch-adaptor</artifactId>
  <scope>runtime</scope>
</dependency>