今回は、私たちが開発しているサービス「CotoGoto（コトゴト）」において、Seasar2フレームワークのサポート終了（EOL）にどう対処したかについて詳しくお伝えします。移行の過程での各選択肢のメリット・デメリットを評価しながら、その背景にあった私たちの判断基準を説明していきます。

1. Controllerの移行：Struts2の継続使用

移行前後

  • 移行前: Struts2
  • 移行後: Struts2

メリット

Struts2はSeasar2のファミリーには含まれておらず、Seasar2のサポート終了の影響を受けなかったため、移行の必要がありませんでした。この点は、私たちにとって大きな利点でした。Struts2の継続使用は、コードの大幅な修正が不要だったことから、移行コストを大幅に削減できた点が非常に良かったです。

デメリット

Struts2自体も古い技術であり、将来的にはさらなる更新や移行の必要性が出てくる可能性があります。現時点での変更は見送りましたが、技術的負債の観点からは、モダンなフレームワークへの移行も検討すべきという意見もありました。

2. DI（依存性注入）の移行：Google Guiceの選択

移行前後

  • 移行前: Seasar2
  • 移行後: Google Guice

メリット

Google Guiceはシンプルで軽量なDIフレームワークであり、学習コストが低く、導入も比較的容易でした。フルスタックフレームワークのように全体を一括して管理するのではなく、必要な部分だけを置き換えることができるため、柔軟な運用が可能です。また、マイクロサービスアーキテクチャへの適合性も高く、今後の拡張性を考えると最適な選択肢でした。

デメリット

一方で、Google GuiceはSpringほどのエコシステムが整っておらず、他のコンポーネントとの統合には多少の工夫が必要となる場面もありました。また、コミュニティの規模もSpringに比べると小さいため、情報の取得や問題解決のスピードには限界がある点もデメリットです。

3. DAO（データアクセスオブジェクト）の移行：Doma2への移行

移行前後

  • 移行前: S2Dao
  • 移行後: Doma2

メリット

Doma2はS2Daoと同じく、2 Way SQLを活用できるため、既存のSQLファイルをほぼそのまま利用できました。この点は、再構築のコストを抑え、移行の効率を高める大きなメリットでした。また、Doma2はシンプルな設計であり、Javaとの相性も良く、Javaの標準機能を活用しながら開発を進めることができました。

デメリット

しかし、Doma2はJavaのバージョン依存が強く、環境によっては互換性の問題が発生することもあります。さらに、既存の`java.sql.Timestamp`から`java.time.LocalDateTime`への変換でエラーが頻発し、その対応に手間がかかりました。このため、導入時には適切なバージョン管理と、変換の対応をしっかり行う必要がありました。

4. その他の対応と課題

モデルマッパーとして使用していたS2Dxoの置き換えには、Apache Commons BeanUtilsを使用しましたが、この変更に伴い、変換処理の手間が増えました。特に`null`の扱いや型の違いによるエラー対応が必要で、移行後のシステムの安定稼働にはいくつかの追加作業が必要でした。

良かった点

変換部分を自作することで、より細かいカスタマイズが可能になり、システムの精度と安定性を高めることができました。

改善が必要な点

手作業が多かったため、将来的には自動化やさらなるツールの導入で効率化する余地があります。また、テストの強化と継続的なメンテナンスが求められます。

最後に

Seasar2のEOLに伴う移行は、単なるフレームワークの置き換えにとどまらず、今後の開発方針や技術スタックの見直しにもつながる重要なプロジェクトでした。多くの企業やプロジェクトでSpringへの移行が選ばれる中、私たちはGoogle GuiceやDoma2といった選択肢を選び、柔軟性と効率を重視しました。これらの選択が最適であったかどうかは今後の運用で評価されるべきですが、現時点では移行の負担を最小限に抑えつつ、確実に次のステップへ進むことができたと感じています。

もし、同じような課題に直面している方がいれば、この記事が少しでも参考になれば幸いです。皆さんのプロジェクトにも最適な選択肢が見つかりますように。

CotoGoto eol seasar2