Java EE 5からJava EE 7へのアップデート

注）このエントリは前置きです。

Java EE 5で作ったアプリケーションをJava EE 7にアップデートすることを検討中。

実は、3年近く前に、Java EE 6 (JBoss AS 7)へのアップデートを試みたのだけど、諸々の事情があって保留になっていました。。

その間に、Java EE 7がローンチされたし、せっかく今やるならJava EE 6ではなくて、きちんとJava EE 7(Java SE 8)に対応しておきたいと思います。

というわけで、Wildfly 8.1.0.Final上で動くJava EE 7アプリケーションについて、色々と検証していきます。

アップデートの進め方

移行する際のガイドラインとしては、こちらが参考になります。

この記事を呼んで変更のポイントをつかんでおくことはもちろん重要なのですが、前回の反省点として、既存のアプリをいきなりWildfly 8.1.0.Finalに載せて、動くようになるまでカスタマイズしていく方法は茨の道のように感じてます。

というのも、実際にやるとなると、アプリの作りによって記事に紹介されていないようなカスタマイズが必要になることもあり、「デプロイ→エラー→原因分析・修正」のサイクルをまともに動くようになるまで繰り返す必要があるからです（そもそもアプリの作りが悪い、ということも原因なのですが…）。

というわけで、既存のアプリのことはとりあえず忘れて、小さく動くJava EE 7アプリケーションを作って、きちんと動く状態を保ちつつ、既存のアプリを少しずつ移植していくアプローチを採用したいと思います。

Java EE 7アプリケーションのひな形を作る

まずはWildfly 8.1.0.Finalで動くJava EE 7アプリケーションのひな形を作ります。

やるべき（やりたい）こと：

  • 自動化された結合テストの仕組みを最初の段階で用意する。
  • 普段の開発をさくさく行うために、一発でデプロイ（ホットデプロイ）、アンデプロイができるようにする。
  • ビルドやデプロイは、メンテナンスとカスタマイズのしやすさから、MavenではなくGradleを使う。
    • プロジェクトの構成はMavenやGradleの標準レイアウトに準じる。
    • 公開されているドキュメントやサンプルは基本的にMavenを前提として書かれているので、悩ましいところではあるのですが…。
  • アプリケーションのパッケージングはEARでなくてWAR
    • Java EE 5の時は必然的にEARでパッケージングしてましたが、EJBもwarに含めることができるようになった昨今、あえてEARでパッケージングする必要ってあるのかな…？

次回からのエントリで、詳しい内容について書いていきます。

参考サイト