Roadmap - The Apache Struts Web Application Framework Craig R. McClanahan Ted Husted Steve Byrne 高見沢 徳明 高橋 達男 completion 2005/01/22

This document outlines some of changes we expect to see in future releases of Struts.

このドキュメントはStrutsの将来のリリースにおいて予想されるいくつかの変更について説明します。

This document is provided for discussion purposes only. All releases and changes to the codebase are subject to a vote of the Struts PMC.

このドキュメントは議論目的でのみ提供されています。 コードベースへの全てのリリースと変更はStruts PMCの投票対象となります。

The Struts development teams uses the Apache Bug Database (Bugzilla) to manage problem reports and enhancement requests. For your convenience, here are some common Bugzilla queries:

Struts開発チームは問題報告や機能拡張要求を管理するために、 Apache Bug Database (Bugzilla) を利用しています。ご参考までに、Bugzilla でよく行なわれる検索の結果へのリンクをいくつか示しておきます。

The platform requirements throughout the Struts 1.x series will remain the same (Servlet 2.2 / JSP 1.1). Though, later platforms may be supported as an option.

Struts 1.x シリーズを通してプラットフォーム要件は変更ありません(Servlet 2.2 / JSP 1.1)。 しかし、それ以降のプラットフォームもオプションとしてサポートするかも知れません。

Releases in the 1.x series will focus on refactoring of existing functionality, with a continued emphasis on backward compatibility, as were seen in Struts 1.1. However, we expect there to releases to be incremental throughout the rest of the 1.x series, so that improvements and fixes become available to production teams every few weeks.

Struts 1.xシリーズの各リリースはStruts 1.1がそうであったように、 引き続き下位互換性に重点を置き、既存の機能のリファクタリングに注力します。 ただし、数週間ごとに改善やバグフィックスを製作チームにリリースできるように、 今後の1.xシリーズでは、リリースをインクリメンタルにしたいと考えています

Any feature that can be implemented under Servlet 2.2/JSP 1.1 may be considered for the Struts 1.x series. This may include, but is not limited to, better support for alternate view technologies (like XLST), integrated unit testing, integrated support for HTTP/HTTPS mode switching, better workflow handling, support for alternative action types (e.g. BSF actions), a chainable request processor, support for an Action context, and so forth.

Servlet 2.2/JSP 1.1で実装可能な機能はすべて Struts 1.x シリーズ向けに検討される可能性があります。 そうした機能としては、(XLSTといった)ビュー[訳注：MVCのV]の代替技術のサポートの改善、 単体テストの組み込み、HTTP/HTTPSモード切替のサポートの組み込み、 ワークフローの扱いの改善、(BSF[Bean Scripting Framework]アクションといった)代替アクションタイプのサポート、 連鎖可能なリクエストプロセッサ、Actionコンテキストのサポートなどがあります。

Features most likely to be considered are those that have already been implemented as third-party extensions and are in active use by the Struts Community, such as those distributed through the Struts SourceForge site.

検討される可能性の高い機能は既にサードパーティによる拡張機能として実装されており、 Struts SourceForgeサイトを通じて、 すでにStrutsコミュニティで積極的に活用されています。

Throughout the 1.x series, there will be a continued emphasis on expanding unit test coverage for the framework. Bug reports should include a failing test case when possible. Proposals for new features should include a working test suite. (Creating features through Test Driven Development is strongly encouraged.)

1.xシリーズを通して、フレームワークの単体テスト網羅率の向上には引き続き重点を置く予定です。 バグ報告ではできれば失敗したテストケースも記載して下さい。 新機能の提案の際には、動作するテストスイートも含めて下さい。 （[提案する]新機能はテスト駆動で開発することを強く推奨します）

Enhancement requests are logged in Bugzilla they are suggested. The listing of an enhancement in Bugzilla does not imply that is being "planned", merely that some member of the community has suggested it, and the idea hasn't been ruled out (yet).

機能拡張要求は提案時にBugzillaに記録されます。 Bugzillaに機能拡張要求として載っているからといって、「実装決定」というわけではありません。 単にコミュニティのメンバーが提案していて、（今のところ）その提案が却下されていないだけなのです。

Future release milestones are provided for enhancements which are being actively planned or developed but may not be ready for the very next release. If a report has not been tagged for a specific milestone by a working developer, then it may never be resolved. When developers (including non-Committers) are actually working on an enhancement, they should re-tag it for a specific release milestone, such as "1.2.1" or "1.2.2".

現在、実装決定・開発中の機能拡張のためにリリースのマイルストーンが設定されていますが、 直近のリリースでは実装完了しないかもしれません。 開発者が特定のマイルストーン向けのタグをつけていないバグ報告は、永遠に解決しない可能性もあります。 開発者(コミッタ以外も含む)が実際に機能拡張に着手した場合は、1.2.1や1.2.2といった特定のマイルストーンのタグをつけるはずです。

If an enhancement has not been tagged for a specific target, feel free to start working on it yourself. Many of our best features have been contributed by developers, just like you. If you would like to announce your active interest in an enhancement, please post a note on the ticket, and tag it to an appropriate release milestone.

特定のターゲットのタグがついていない機能拡張については自由に着手していただいてかまいません。 Strutsのすばらしい機能の多くは、まさに皆さんのような開発者たちのおかげなのです。 もしある機能拡張に対して積極的な関心を表明したい場合は、[Bugzillaの]報告にメモを投稿し、 適切なリリースマイルストーンのタグをつけてください。

These are some general ideas we have about what may happen in the Struts 1.x series. This is a whiteboard and everything here is subject to change.

Struts 1.x シリーズで今後行なうかも知れない変更に関する検討項目の概要です。 これはあくまでホワイトボードであり、いずれも変更される可能性があります。

  • Struts 1.0.0 (complete) - Major refactoring of Struts internals to provide support for modules and a new "config" object series. Bundles Struts Tiles and Struts Validator into main distribution. The initial release of Struts EL is provided as an optional package.
  • Struts 1.0.0 (完了) - モジュールのサポートと新たに「設定」オブジェクト一式を提供するためにStruts内部を大幅にリファクタリング。 Struts Tiles と Struts Validator をメインの配布にバンドル。 Struts EL の初期リリースはオプションパッケージとして提供。
  • Struts 1.2.x (alpha) - Continued refactorings of the Struts 1.x product series. The current release trigger for 1.2.0 is resolving outstanding problem reports. There are also several patches that could be applied prior to rolling 1.2.0.
    • Remove deprecations created in the 1.0 to 1.1 timeframe, and prior
    • Add support for wildcard mappings.
    • Other minor enhancements and refactorings
    •
  • Struts 1.2.x (アルファリリース) - Struts 1.x 製品シリーズのリファクタリングを継続。現行の1.2.0をリリースしたのは、 際立って多い問題報告を解決するため。 1.2.0リリース前にいくつかのパッチを適用。
    • 1.0 から 1.1 の間やそれ以前に発生した「推奨されない」機能を削除
    • ワイルドカードマッピングのサポートを追加
    • その他マイナーな拡張やリファクタリング
  • Struts 1.3.x (pending) - More substantial enhancements to product base
    • Consider moving repository to Subversion (pending)
    • Complete support for Maven builds (pending)
    • Move taglibs and apps into separate subprojects
    • Launch Flow subproject
    • Launch Scripting subproject
    • Move to "Struts Chain" Request Processor (now in Contrib)
    • Move to Commons Resources when available
    • Enhance all configs to extend one configuration element from another, as is done with Tiles Definitions
    •
  • Struts 1.3.x (保留) - 製品ベースへのより本質的な機能拡張
    • Subversionへのリポジトリ移行を検討（保留）
    • Mavenビルドを完全サポート（保留）
    • タグライブラリとアプリケーションをそれぞれ別のサブプロジェクトに移動
    • Struts Flowサブプロジェクトの立ち上げ
    • Struts BSFサブプロジェクトの立ち上げ
    • (現在、Contribにある)「Struts Chain」リクエストプロセッサへ移行
    • 可能ならばCommons Resourcesへ移行
    • あらゆる設定ファイルで、Tiles定義ファイル[tiles-defs.xml]のように設定要素を継承できるように機能拡張
  • Struts 1.4.x - More substantial enhancements to product base
    • Consider migration to an Action context (which also might be based on the Commons Chain of Responsiblity package)
    • Consider enhanced support for other platforms (2.3/1.2) if this can be accomplished by specifying an alternate Request Processor
    •
  • Struts 1.4.x - 製品ベースへのより本質的な機能拡張
    • Actionコンテキストへの移行を検討（これもCommons Chainパッケージをベースにする可能性あり）
    • (代替的なリクエストプロセッサの仕様策定で実現可能なら)他のプラットフォーム(2.3/1.2)向けの拡張サポートを検討
  • Other potential enhancements for the 1.x.x series
  • その他、1.x.xシリーズで実装可能性のある機能拡張

Struts 2.x (aka Struts "Next Generation") will include broader enhancements. We anticipate that the implementation will utilize the Servlet 2.4 / JSP 2.0 platform, but may optionally support earlier platforms.

Struts 2.x （別名「次世代」Struts）では大幅な機能拡張を行ないます。 Servlet 2.4 / JSP 2.0プラットフォームを利用しての実装が予想されますが、 それ以前のプラットフォームもオプションでサポートするかもしれません。

We anticipate that Struts 2.x will rely on JSTL and the JavaServer Faces API as supporting technologies. However, the focus of the Struts framework will remain on the Controller aspect of a Model 2/MVC architecture. The core framework will continue to be both Model and View independent.

Struts 2.xはサポート技術として JSTL と JavaServer Faces (JSF) APIに依存することが予想されます。 しかしながら、Strutsフレームワークは Model 2/MVC アーキテクチャのコントローラの役割を引き続き担当します。 今後も中心となるフレームワークはモデルにもビューにも依存しません。

Development of Struts 2.x will include taking a completely fresh look at the architecture. The goal for 2.x will be to incorporate everything we've learned in the past years of Struts usage, and create something even better. Development will follow current best practices, like Test Driven Development, and rely on technologies like Maven for project management.

Struts 2.xの開発ではアーキテクチャの根本的な見直しを行ないます。 2.xの目標は我々が過去何年もStrutsを使ってきた中で学んできた全てを組み込み、 より良いものを作り上げることです。 開発作業ではテスト駆動開発など最新の成功事例に追随し、 プロジェクト管理ではMavenなどの技術に依存します。

Of course, it is anticipated that the Struts team will continue to support the 1.x codebase for a long time with bugfixes and incremental enhancements. (Mainly because many of us will still be using it on our production sites!) Accordingly, it is anticipated that the development of the 2.x and 1.x series will occur in tandem. At some point, 2.x milestones may appear alongside new 1.x releases.

もちろん、Strutsチームは1.xコードベースのサポートも、 バグフィックスや機能拡張の追加といった形で長期にわたり行なわれることが予想されます。 （実稼動しているサイトで多くの人が今後も利用するだろうというのが主な理由です）。 従って、2.xと1.xシリーズの開発は平行して行う予定です。 2.xのマイルストーンリリースが1.xの新規リリースと同時に行なわれる場合もあるかも知れません。

Target features include:

ターゲットとなる機能としては以下のものが挙げられます。

  • Comprehensive unit test coverage for all core features
  • Enhanced support for using Struts in large team environments.
  • Transparent support for a portlet environment (JSR 168), with minimal-to-no changes in your business logic and pages.
  • Direct support for JSTL/JSF taglibs and the JSF API
  • Enhanced support for other presentation layers, such as XLST
  • Enhanced support for scriptable Actions, using technologies like BSF or Jelly
  • Refactoring for new technologies available on the Servlet 2.4/ JSP 2.0 platform
  • 全てのコア機能での包括的な単体テストカバレッジ
  • 大規模チームによる開発環境でのStruts利用のサポート強化
  • ビジネスロジックやページを最小限もしくは全く変えずに Portlet環境 (JSR 168) を透過的にサポート
  • JSTL/JSFタグライブラリとJSF API の直接的サポート
  • XLSTなどプレゼンテーションレイヤのサポート強化
  • BSFやJellyなどの技術を用いたスクリプト制御可能なアクションのサポート強化
  • Servlet 2.4/ JSP 2.0プラットフォームで利用可能な新技術に向けたリファクタリング

An early proposal for one possible implementation of Struts 2.x, "Struts Jericho", is available in the contrib folder.

Struts 2.xの実装候補の初期提案である「Struts Jericho」は contribフォルダで利用可能です。

There are three major issues with supporting JSR-168 (and I'm sure a bunch of smaller ones as well):

JSR-168をサポートするに当たって大きな問題が3つあります（小さな問題もきっとたくさんあるでしょう）。

  • Struts APIs assume servlet API objects (ServletContext, ServletRequest, ServletResponse), whereas JSR-168 talks aboutPortletContext, PortletRequest, and PortletResponse. We'd either need to change the calling sequence for Action.execute() -- problematic for backwards compatibility -- or fake it somehow in a portlet environment.
  • Struts APIではサーブレットAPIオブジェクト(ServletContext, ServletRequest, ServletResponse)を前提にしているのに対し、 JSR-168はPortletContext, PortletRequest, そして PortletResponseを扱います。 Action.execute()への呼び出しシーケンスを変えるか(この方法だと下位互換性に問題があります)、 Portlet環境でどうにかごまかす必要があります。
  • The lifecycle of a portlet request is actually divided into two chunks -- processing and then rendering. From a Struts perspective, that means making sure that the first part of the request processor pipeline need to happen in the "process" part, and the forwarding to the resulting page needs to happen in the "render" part.
  • Portletリクエストのライフサイクルは実際には２つのかたまり ― プロセシング（処理を行う部分）とレンダリング（結果を返す部分） ― に分けられます。Strutsの観点からすると、リクエストプロセッサパイプラインの最初の部分は「プロセシング」の部分で、 結果ページのフォワードは「レンダリング」の部分で行なうようにする必要があるということを意味します。
  • Today, Struts owns the process of calculating URLs for pages and actions. Because it's in a webapp, it knows exactly what to do for the developer. However, in a portlet container it's actually the portal server that manages URLs, so a Struts-based portlet would need to interact with the portlet APIs for this purpose.
  • 現在、Strutsはページやアクションに対応するURLを導き出すプロセスをもっています。 このプロセスはWEBアプリケーション内にあるので、開発者のために何をすべきか正確に把握しています。 しかしPortletコンテナでは、URLを管理するのはポータルサーバーなので、 StrutsベースのPortletはこの目的のためにPortlet APIにアクセスする必要があります。

A strong goal should be that a Struts application should be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, we should build whatever it takes to support this into the standard Struts distribution, which would then be used in both environments.

Strutsアプリケーションを小規模の変更で（理想的には変更なしで）、Webアプリとしても Portletとしても使用できることが重要な目標となります。 したがって、標準Strutsディストリビューションにこうしたサポートを何としても組みこみ、 WEBアプリケーション、Portlet両方の環境で使えるようにしなければなりません。

The JavaServer Faces specification has not been finalized. However, Struts is already providing support for JSF through the Struts Faces taglib. Once JSF is finalized and comes into broad use, it is expected that Struts developers will continue to offer enhancements to make it even easier to use Struts with JSF.

JavaServer Faceの仕様は確定しておりません。 しかし、StrutsはStruts Faces タグライブラリを通してJSFへのサポートを既に提供しております。JSF の仕様が確定し、広く利用されるようになれば、StrutsでJSFをさらに使いやすくするための機能拡張が Struts開発者から提供されると思われます。

Right now, there is only one open source project working on a JavaServer Faces implementation, MyFaces. This work is being done under the LGPL, which some developers find unacceptable. (If you are interested in this project, we suggest you lobby the developers to adopt a more liberal license, like the ASL.)

現在のところ、JavaServer Faces実装に取り組むオープンソースのプロジェクトは、 MyFacesしかありません。 成果物はLGPLで提供されていますが、 このライセンス形態を容認しない開発者もいます。（もしこのプロジェクトに興味がおありでしたら、 ASLのようにより寛大なライセンスを採用するよう、 開発者に働きかけることをお勧めします。

Thanks in large part to Apache's advocacy and influence, the Java Community Process, which is responsible for the JavaServer Faces specification, process has been modified so that Apache Software Foundation projects, like Jakarta, can qualify for the certification scholarship (for nonprofits) and access to the TCKs and certify that our application is compliant.

JavaServer Facesの仕様に責任を持つJava Community Process (JCP) に対するApacheの強い支持と影響力のおかげで、JakartaなどApache Software Foundation の各プロジェクトが（非営利団体向け）認定奨学金の資格を得たり、TCK(テクノロジー互換性キット) にアクセスしたり、アプリケーションが仕様に準拠していると認定を受けられるようにプロセスが変更されました。

http://www.idg.co.jp/headline/200311_03.html の「米ジェイボスが有償のJ2EE認定条件を受入れ、ASFは無償認定へ」という記事が参考になるかも知れません。

An certificated-complaint Apache implementation of JavaServer Faces would most definately be a Good Thing. It would not be the reference implementation, but we could treat it like one, and strictly follow the book, in the Apache Way. A strict, high-quality, open-source implementation would most likely become a popular option among containers.

JavaServer Faces準拠が認定されたApacheの実装があれば、間違いなくすばらしいことでしょう。 リファレンス実装ではないにせよ、それと同様に扱うことが出来るでしょうし、 Apache的なやり方で厳格に仕様に従っていることでしょう。 厳格で高品質なオープンソース実装は恐らくコンテナの中で人気のある選択肢となることでしょう。

Work on such an implementation could be undertaken by Struts, either here at Jakarta or after our applying for status as a top-level Apache project. Or, "Apache Faces" could also be undertaken as a separate project, with Struts simply using the technology as we now use technologies from the Commons today.

こうした実装作業はApacheのトップレベルプロジェクトであるStrutsが行なうかもしれません。 あるいは新しい別プロジェクト(「Apache Faces」？)がこの作業を行い、 Strutsは現在Commonsを使っているように技術を利用するだけという形になるかもしれません。

either here ... as a top-level Apache projectの部分は、 StrutsがTLPに昇格したという実情に合わせて意訳しています。(高橋) もちろん「Apache Faces」というプロジェクトは現在のところ実在しません。(高橋)

However, at this point, there is no "code on the table". Apache products leave decisions such as these to the people who create and maintain the codebase. So, lacking a codebase, no binding decision can be made. But, anyone wishing to pursue an "Apache Faces" implementation should be aware that the option certainly exists.

しかし現時点では「検討中のコード」はありません。Apache製品ではこうした決定はコードベースを作成・維持する人にゆだねられます。 したがってコードベースがない現状では、拘束力を持つ決定を行なうことはできません。 しかし「Apache Faces」の実装を進めたい人は、こうした選択肢が確固として存在することを覚えておいて下さい。

Aside from offering a strict implementation of JavaServer Faces, there are many, many other JSF related tools and technologies Apache Faces could provide. These include composite view and validation frameworks (like Tiles and the Validator), frameworks for multi-request transactions, non-HTML markup languages (building on top of Faces for things like XUL or XForms or SVG is easy), non-JSP rendering technologies (pretty much anything that has a way to mark where dynamically created output goes can be adapted), libraries of prebuilt components above and beyond the built-in standard ones (such components work equally well in JSP and non-JSP environments), and all the non-human-UI things based on XML technologies.

JavaServer Facesの厳密な実装の提供はさておき、それ以外にも「Apache Faces」が提供すると思われる JSF関連のツールや技術は非常ににたくさんあります。例えば、（TilesやValidatorのような）複合ビュー(composite view) やバリデーションのフレームワーク、複数リクエストのトランザクションのためのフレームワーク、 HTML以外のマークアップ言語（XULやXFormsやSVGのようなものをFacesをベースに構築するのは簡単です）、 JSP以外のレンダリング技術（動的に生成される出力先をマークする手段があるものなら何でも）、 ビルトインの標準コンポーネントなどあらかじめビルドされたコンポーネントのライブラリ （こうしたコンポーネントはJSP環境でもJSP以外の環境でも同じように動作します）、 XMLをベースにした人手を介さないあらゆるユーザインターフェースなどが挙げられます。

As always, the standard implementation is only the beginning.

いつものことですが、標準実装は始まりに過ぎないのです。

For more about Struts and JavaServer faces, see our FAQ. For more about JavaServer Faces generally, see also Java Server Faces Resources at JamesHomes.com.

StrutsやJavaServer facesの詳細はFAQを参照してください。 JavaServer Facesの概要についてはJamesHomes.comのJava Server Faces Resourcesもご参照ください。

Commons Chainはサンドボックスから昇格したためリンクを変更しました。(高橋) StrutsのリポジトリはCVSからSubversionに移行したため、リンク変更が必要ですが、 校正時点でSVNサーバが落ちているため確認できていません。(高橋)

Next: CVS Repository

次は: CVSリポジトリ

Website updated from CVS: 2004 AUG 24 by husted.

Javadocs updated from CVS: 2004 AUG 24 by husted.