この記事を書いた趣旨
javax.servlet と書くのは、そろそろヤメにしたい。
jakarta.servlet と書きましょう。
なんでこんな事になったのか？
@tkxlab(隆 川場)様が書かれた以下の記事が、大変よく、まとまっています。
2009年サン・マイクロシステムズをオラクル社が買収しました。
docker（2013年）やKubernetes（2015年）のようなシステムの登場が大きな契機でした。エンタープライズシステム開発の将来を予見するような、エポックメイキングなプロダクトです。ただ、Oracle社の動きは鈍く、意欲も見えなかったので、これに対して、コミュニティでは、 Java EE Guardiansを結成（2016年）し、Orcle社へ働きかけました。
2017年に、Java EEがOaracle社からEclipse財団に移譲される
Javaの商標権をORACLEが持っていて、パッケージ名をjavaxからjakartaに変更しなければ、ならなかった様子です。
じゃぁORACLEは、今何をしているのか？
これは私の推測ですが、Javaのコアな部分(JavaSE)の開発に力を入れている様子です。
例１）GraalVM
例２）新しいCPUへの対応(Intel x64 → Arm → RISC-Vなど）
いつごろ変更されたのか
@miyo4(M)様の記事が良くまとまっています。
Tomcat 10から、変更になったんですかね？
私はいつごろ変更したのか
2023年06月21日に私が書いた記事が、ありました。
私は某中小企業で、社内SE兼PGをやっています。
WEBアプリも内製しています。
AWSのサーバ構築も自分でやっています。
（おそらくTomcat8.5のEOLが2024年で、その半年前ぐらいから危機感を持っていたのだと思われます）
最新技術は、microprofileで検索
(ChatGPTはめったに使わない。ググるのが好きな年寄りです）
上記の図が、わかりやすいかも知れませんが、たぶんこの記事を読んでいる方は、全く理解できないかも知れません。
（私が読んでも、実は よくわかりません（苦笑））
上記の記事を読んで、今知った事があります。
Spring Frameworkは混ぜるなキケンではなく一緒に使えません
SpringとMicroProfileでは目的を同じにした別の仕組みを基盤としているため、両者を1つのアプリケーションで共有して使う理由はありませんし、仕組みとしてもムリがあります。
上記の記事に、おすすめアプリサーバが載っています。
・OpenLiberty
・Payara
・Wildfly
・helidon
・QUARKUS
私流の簡単な説明
フロントエンドの開発がReactやVueになってしまった。
「じゃぁサーバーサイドは何するの？」「RESTful APIだけ作れればいいじゃん」
と考えた様子です。
そのため、JAX-RSが主役になりました。これはJavaでRESTful APIを作る仕組みです。
それ以外だとCDI という SpringFrameworkでいう所の依存性の注入（Dependency Injection、DI）が、マイクロプロファイルでも使えます
じゃぁServlet-APIはどうなったの？
ご安心ください！！
まだまだ使えます。
マイクロプロファイルの外側にJavaEE互換層があるそうです。
ちなみにJavaEEもJakartaEEへと名前が変わりました。
当然パッケージ名もjavax.〜 jakarta.〜に変わっているはずです。
上記のおすすめアプリサーバのうち上３つならServletも使えるそうです。
・OpenLiberty
・Payara
・Wildfly
個人的にはWildflyしか勝たん
気に入っている点
・Tomcatと体感差がない高速起動
・アプリサーバ側にHibernate(JPA)が入っている
（warファイルのサイズが非常に小さくなります)
・DI(CDI)が使える
・トランザクションのアノテーションも、もちろん使えます
途中で例外が発生したら、トランザクションは自動でロールバックされます。
・JAX-RSも使える（ほとんど使ってないけど）
・Mac限定ですが、サーバーのログがカラフルで綺麗です。
ちょっと気に入らない点
・sfl4jなどのログを、全部Wildflyが横取りしてしまう点
(Wildflyが吐くログ入るの中に出力されます)
その他
・ログイン機能でKeyCloakを使っているから、Wildflyも勉強したかった。
KeyCloakはWildfly上で動作しているアプリです。
Tomcatからの移行は大変でしたか？
そんな事はありません。
私が書いていたアプリは３つあり、全て移行済みです。
ちなみにJavaは Java17に移行済みです。
| アプリ１ | アプリ２ | アプリ３ | |
|---|---|---|---|
| 画面数 | 約30画面 | 約20画面 | 約10画面 |
| Servlet使用 | 有 | 有 | 有 |
| JSP使用 | 有 | 有 | 有 |
| JSPのタグリブ使用 | なし | なし | 過去にあった |
| FileUpload | なし | 有 | 有（最近追加） |
| DBアクセス | MyBatis | JDBC | 主にJDBC |
| その他 | なし | POIの使用☆ | HTMX.js |
| CSS | Bulma | 手書き | Bulmaに変更中 |
☆POIはEXCELファイルを作るライブラリです。
ちなみにDBですが、アプリ１、アプリ２はMariaDBに移行済み。
アプリ３のみMySQL5.7が残っています。
また上記アプリはDataSourceは使っていません。
JDBCの機能でConnectionを取得するか、MyBatisの機能でセッションを取得しています。
書き換え時にハマった事
覚えているだけ書きます
アプリ２で commons-fileuploadを使っていた
CSVファイルをアップロードする部品として、commons-fileuploadを使っていた。
この部品は javax.servletに依存していました。
Wildflyに変えて、jakatra.servletの世界線に変わると当然動きません。
→ 解決方法は？
調べていた所、Servlet-APIが機能強化されており、commons-fileuploadを使わなくても、２０行ほどコードを書けば、アップロードを実現できる事がわかった。
commons-fileuploadの使用を廃止しました。
（たしか現在は、jakatra.servlet対応のcommons-fileuploadもあった筈です。
でももう戻る気はありませんが）
アプリ３で、JSPのタグリブを使っていた
c:out とか単純なものだったので、使うのをやめてしまいました。
web.xmlの書き方が変わっているのが、痛いです。
ただし、冒頭の3〜4行だけです。
新しく使うアプリサーバーのサンプルアプリを取得して、そのweb.xmlをベースにすると良いでしょう。
一番外側のタグだけ変わっていて、中身の書き方は基本的に変わっていません。
「JSPのタグリブを実装しているjar」は当然の事ながら javax.servletを使っています。
jakarta.servletに対応した、使いたいタグリブの新しいjarを探して、入れ替えれば使える筈です。
私は、探す時間が、もったいなかったので、やめただけです。
ちなみに、JSPの中にJavaのコードを書く事は、今でも可能です。
移植（バージョンアップ）する上で、問題はありませんでした。
まとめ
Java8 → Java11 → Java17 への変更も楽でした。
上記、豆蔵デベロッパーサイトを見る限り、私は、Spring系の技術を使っていなかったのが、幸いしていたと思います。
最近作っているアプリ（開発途中）
現在開発中のアプリはJPA(Hibernate)を使っています。
MyBatisはやめました。
今回、DataSourceをはじめて使用しました。
トランザクションはアノテーションで行えるようになりました。
CDIも積極利用できるようになりました。@Injectで、依存性注入できます。
| アプリ４ | |
|---|---|
| 画面数 | 約30画面 |
| Servlet使用 | 有 |
| JSP使用 | 有 |
| JSPのタグリブ使用 | なし |
| FileUpload | 有 |
| DBアクセス | JPA |
| DataSource利用 | 有 |
| CDI利用 | 有 |
| その他 | RESTful API少々 |
| ECMAScript | バニラJS派です |
| CSS | Bulma |
JAX-RSは「アプリ１」で、使った事があるのですが、使わない事にしました。
理由はKeyCloakをリバースプロキシー構成で使っているためです。
以下の記事との対比
@K3n_to_n17 さまが、最新技術の大変素晴らしい記事を書かれています。
ただし、
2 認証と認可の進化
JWT（JSON Web Token）と、OAuth 2.0
については、 私が学習した内容とは、だいぶ違う感じがしています。
私が学習した、KeyCloak本には以下のように書かれています。
・認証は、OIDCプロトコルで行うべき
・OAuth2.0は、認可のプロトコルなので、認証で使うべきでない。
と書かれています。
とても不思議なのですが、たとえば、AWSの管理者画面にログインした時、そのURLには、oauth2とか書いてあったりするんですよねー。
OAuth2.0は認証で使うべきでない とあるのに、なぜいまだに認証にも使われている（？）のかが、よくわからない点です。
上記の「認証と認可 KeyCloak入門」という本の６．３章のリバースプロキシー構成（以下リバプロと省略）の後ろに、「アプリ用のサーバー」を配備しています。
リバプロ構成の場合、JWTを学習する必要は全くありません
(もちろん知っておいた方がいいのかも知れませんが)
Keycloak本の６．３章では、Apacheをインストールし、そのモジュールである mod_auth_openidc をインストールします。
JWTのハンドリングは全て、mod_auth_openidcとKeycloakの間で通信を行ってくれます。
そのため、アプリ開発者は、JWTについて学習する必要はありません。
アプリ開発者が知っておくべき事は、「HTTPヘッダーからログインしたユーザーのメールアドレスを取り出す方法」のみです。
もし、グループ等の認可情報もKeyCloakに登録したい場合は、「HTTPヘッダーからログインしたユーザーのグループを取り出す方法」も知っておく必要があります。（認可・権限の話）
豆蔵デベロッパーサイトさんに戻りますと
MicroProfileがカバーする仕様の図の、右から２つめ、上から２つめに
『JWT Auth2.0』と書かれている箱があります。
これは以下の意味だと考えています。
Wildfly（やJakartaEE対応のアプリサーバー）に、『JWT Auth2.0』を有効にする設定をする。そして、Keycloakと連携するための設定が必要と思われます。
・MetadataURLの設定
・クライアントシークレットの設定
などなど。
この設定ができれば、リバプロが不要になると考えています。
・『JWT Auth2.0』がJAX-RSで書いたRESTful APIを保護してくれるようになる。
・Wildflyの『JWT Auth2.0』がやってくれるのでリバプロは不要になる。
ただし、この方法は、まだわかっておりません。
それに私の場合は、JSPによって、HTMLを返すアプリが９５％ぐらいを占めていて、５％ぐらいRESTful APIを使っているという程度なので、リバプロ構成をやめる予定はありません。
MyBatisについて
MyBatisを使っているアプリがあるんだけど、どうしようかーと思っていました。
私が知りたかった事を書いている記事がありました。
ありがとうございます！！
だいぶ先になるかも知れませんが、時間ができた時に、私もやってみたいと、思います。