diff --git a/.claude/skills/nabledge-1.2/docs/README.md b/.claude/skills/nabledge-1.2/docs/README.md index 78903ecf3..7ddf41cb4 100644 --- a/.claude/skills/nabledge-1.2/docs/README.md +++ b/.claude/skills/nabledge-1.2/docs/README.md @@ -1,14 +1,12 @@ # Nablarch 1.2 ドキュメント -321 ページ +188 ページ ## about ### about-nablarch - [Nablarch Application Framework 概要](about/about-nablarch/about-nablarch-01-NablarchOutline.md) -- [国際化対応](about/about-nablarch/about-nablarch-02-I18N.md) -- [RDBMS の使用ポリシー](about/about-nablarch/about-nablarch-04-RDBMS-Policy.md) - [SqlRow等のMap実装クラスからEntityやFormを生成する方法を教えてください](about/about-nablarch/about-nablarch-1.md) - [configファイルの設定値の取得方法を教えてください](about/about-nablarch/about-nablarch-2.md) - [コード名称やコード存在チェック時に指定するパターンには、何を指定したらいいのでしょうか？](about/about-nablarch/about-nablarch-3.md) @@ -16,148 +14,26 @@ - [メッセージIDと障害コードの違いは何でしょうか？](about/about-nablarch/about-nablarch-5.md) - [DB2やSQLServerでのバイナリ型のカラムへのアクセス方法を教えてください](about/about-nablarch/about-nablarch-6.md) - [Nablarch FAQ](about/about-nablarch/about-nablarch-FAQ.md) -- [about-nablarch-about-nablarch-concept](about/about-nablarch/about-nablarch-about-nablarch-concept.md) - [想定読者、位置付け、対象工程、注意事項](about/about-nablarch/about-nablarch-aboutThis.md) - [Nablarchの全般的なFAQ](about/about-nablarch/about-nablarch-all.md) -- [about-nablarch-architectural-pattern-concept](about/about-nablarch/about-nablarch-architectural-pattern-concept.md) -- [共通方針](about/about-nablarch/about-nablarch-basic-policy.md) -- [文字列からBigDecimal変換時に発生する可能性のあるヒープ不足について](about/about-nablarch/about-nablarch-bigdecimal.md) +- [about-nablarch-concept](about/about-nablarch/about-nablarch-concept.md) - [about-nablarch-contents](about/about-nablarch/about-nablarch-contents.md) -- [業務コンポーネントの責務配置](about/about-nablarch/about-nablarch-determining-stereotypes.md) - [about-nablarch-development-policy](about/about-nablarch/about-nablarch-development-policy.md) - [∇Nablarch ドキュメント](about/about-nablarch/about-nablarch-document.md) -- [∇Nablarch Application Framework 解説書](about/about-nablarch/about-nablarch-fw.md) - [Nablarch 用語集](about/about-nablarch/about-nablarch-glossary.md) - [about-nablarch-guide](about/about-nablarch/about-nablarch-guide.md) -- [序 : Nablarch Application Framework (NAF)とは ?](about/about-nablarch/about-nablarch-introduction.md) -- [about-nablarch-link](about/about-nablarch/about-nablarch-link.md) -- [NAF概要](about/about-nablarch/about-nablarch-overview-of-NAF.md) -- [動作を保証するプラットフォーム](about/about-nablarch/about-nablarch-platform.md) - [about-nablarch-support-service](about/about-nablarch/about-nablarch-support-service.md) - [about-nablarch-top-nablarch](about/about-nablarch/about-nablarch-top-nablarch.md) - [about-nablarch-top](about/about-nablarch/about-nablarch-top.md) - [about-nablarch-versionup-policy](about/about-nablarch/about-nablarch-versionup-policy.md) ## component -### handlers - -- [handlers-AsyncMessageReceiveAction](component/handlers/handlers-AsyncMessageReceiveAction.md) -- [handlers-AsyncMessageSendAction](component/handlers/handlers-AsyncMessageSendAction.md) -- [handlers-BatchAction](component/handlers/handlers-BatchAction.md) -- [handlers-DataReadHandler](component/handlers/handlers-DataReadHandler.md) -- [handlers-DbConnectionManagementHandler](component/handlers/handlers-DbConnectionManagementHandler.md) -- [handlers-DuplicateProcessCheckHandler](component/handlers/handlers-DuplicateProcessCheckHandler.md) -- [handlers-FileBatchAction](component/handlers/handlers-FileBatchAction.md) -- [handlers-FileRecordWriterDisposeHandler](component/handlers/handlers-FileRecordWriterDisposeHandler.md) -- [handlers-ForwardingHandler](component/handlers/handlers-ForwardingHandler.md) -- [handlers-GlobalErrorHandler](component/handlers/handlers-GlobalErrorHandler.md) -- [handlers-HttpAccessLogHandler](component/handlers/handlers-HttpAccessLogHandler.md) -- [handlers-HttpCharacterEncodingHandler](component/handlers/handlers-HttpCharacterEncodingHandler.md) -- [handlers-HttpErrorHandler](component/handlers/handlers-HttpErrorHandler.md) -- [handlers-HttpMethodBinding](component/handlers/handlers-HttpMethodBinding.md) -- [handlers-HttpRequestJavaPackageMapping](component/handlers/handlers-HttpRequestJavaPackageMapping.md) -- [handlers-HttpResponseHandler](component/handlers/handlers-HttpResponseHandler.md) -- [handlers-HttpRewriteHandler](component/handlers/handlers-HttpRewriteHandler.md) -- [handlers-KeitaiAccessHandler](component/handlers/handlers-KeitaiAccessHandler.md) -- [handlers-LoopHandler](component/handlers/handlers-LoopHandler.md) -- [handlers-Main](component/handlers/handlers-Main.md) -- [handlers-MessageReplyHandler](component/handlers/handlers-MessageReplyHandler.md) -- [handlers-MessageResendHandler](component/handlers/handlers-MessageResendHandler.md) -- [handlers-MessagingAction](component/handlers/handlers-MessagingAction.md) -- [handlers-MessagingContextHandler](component/handlers/handlers-MessagingContextHandler.md) -- [handlers-MultiThreadExecutionHandler](component/handlers/handlers-MultiThreadExecutionHandler.md) -- [handlers-MultipartHandler](component/handlers/handlers-MultipartHandler.md) -- [handlers-NablarchServletContextListener](component/handlers/handlers-NablarchServletContextListener.md) -- [handlers-NablarchTagHandler](component/handlers/handlers-NablarchTagHandler.md) -- [handlers-NoInputDataBatchAction](component/handlers/handlers-NoInputDataBatchAction.md) -- [handlers-PermissionCheckHandler](component/handlers/handlers-PermissionCheckHandler.md) -- [handlers-ProcessResidentHandler](component/handlers/handlers-ProcessResidentHandler.md) -- [handlers-ProcessStopHandler](component/handlers/handlers-ProcessStopHandler.md) -- [handlers-RequestHandlerEntry](component/handlers/handlers-RequestHandlerEntry.md) -- [handlers-RequestPathJavaPackageMapping](component/handlers/handlers-RequestPathJavaPackageMapping.md) -- [handlers-RequestThreadLoopHandler](component/handlers/handlers-RequestThreadLoopHandler.md) -- [handlers-ResourceMapping](component/handlers/handlers-ResourceMapping.md) -- [handlers-RetryHandler](component/handlers/handlers-RetryHandler.md) -- [handlers-ServiceAvailabilityCheckHandler](component/handlers/handlers-ServiceAvailabilityCheckHandler.md) -- [handlers-SessionConcurrentAccessHandler](component/handlers/handlers-SessionConcurrentAccessHandler.md) -- [handlers-StatusCodeConvertHandler](component/handlers/handlers-StatusCodeConvertHandler.md) -- [handlers-ThreadContextClearHandler](component/handlers/handlers-ThreadContextClearHandler.md) -- [handlers-ThreadContextHandler](component/handlers/handlers-ThreadContextHandler.md) -- [handlers-TransactionManagementHandler](component/handlers/handlers-TransactionManagementHandler.md) -- [handlers-WebFrontController](component/handlers/handlers-WebFrontController.md) -- [ハンドラリファレンス](component/handlers/handlers-handler.md) ### libraries -- [障害ログの出力](component/libraries/libraries-01-FailureLog.md) -- [ログ出力](component/libraries/libraries-01-Log.md) -- [libraries-02-01-Repository-config](component/libraries/libraries-02-01-Repository-config.md) -- [libraries-02-02-Repository-initialize](component/libraries/libraries-02-02-Repository-initialize.md) -- [libraries-02-03-Repository-factory](component/libraries/libraries-02-03-Repository-factory.md) -- [libraries-02-04-Repository-override](component/libraries/libraries-02-04-Repository-override.md) -- [コード管理](component/libraries/libraries-02-CodeManager.md) -- [リポジトリ](component/libraries/libraries-02-Repository.md) -- [SQLログの出力](component/libraries/libraries-02-SqlLog.md) -- [パフォーマンスログの出力](component/libraries/libraries-03-PerformanceLog.md) -- [トランザクション管理](component/libraries/libraries-03-TransactionManager.md) -- [データベース接続部品の構造](component/libraries/libraries-04-Connection.md) -- [データベースアクセス(検索、更新、登録、削除)機能](component/libraries/libraries-04-DbAccessSpec.md) -- [HTTPアクセスログの出力](component/libraries/libraries-04-HttpAccessLog.md) -- [オブジェクトのフィールドの値のデータベースへの登録機能(オブジェクトのフィールド値を使用した検索機能)](component/libraries/libraries-04-ObjectSave.md) -- [認可](component/libraries/libraries-04-Permission.md) -- [SQL文実行部品の構造とその使用方法](component/libraries/libraries-04-Statement.md) -- [データベースコネクション名とトランザクション名](component/libraries/libraries-04-TransactionConnectionName.md) -- [トランザクションタイムアウト機能](component/libraries/libraries-04-TransactionTimeout.md) -- [ファイルダウンロード](component/libraries/libraries-05-FileDownload.md) -- [開閉局](component/libraries/libraries-05-ServiceAvailability.md) -- [静的データのキャッシュ](component/libraries/libraries-05-StaticDataCache.md) -- [ファイルアップロード](component/libraries/libraries-06-FileUpload.md) -- [採番機能](component/libraries/libraries-06-IdGenerator.md) -- [日付の管理機能](component/libraries/libraries-06-SystemTimeProvider.md) -- [libraries-07-BasicRules](component/libraries/libraries-07-BasicRules.md) -- [JSPカスタムタグライブラリの使用方法](component/libraries/libraries-07-CustomTag.md) -- [libraries-07-DisplayTag](component/libraries/libraries-07-DisplayTag.md) -- [libraries-07-FacilitateTag](component/libraries/libraries-07-FacilitateTag.md) -- [libraries-07-FormTag](component/libraries/libraries-07-FormTag.md) -- [フォーム内の入力要素を出力するカスタムタグ](component/libraries/libraries-07-FormTagList.md) -- [カスタムタグライブラリに関する設定](component/libraries/libraries-07-HowToSettingCustomTag.md) -- [メッセージ管理](component/libraries/libraries-07-Message.md) -- [変数に値を設定するsetタグ](component/libraries/libraries-07-OtherTag.md) -- [libraries-07-SubmitTag](component/libraries/libraries-07-SubmitTag.md) -- [タグリファレンス — カスタムタグ一覧](component/libraries/libraries-07-TagReference.md) -- [JSPカスタムタグライブラリ](component/libraries/libraries-07-WebView.md) -- [バリデーション機能の構造](component/libraries/libraries-08-01-validation-architecture.md) -- [バリデーション機能の基本的な使用方法](component/libraries/libraries-08-02-validation-usage.md) -- [階層構造を持つFormのバリデーション](component/libraries/libraries-08-03-validation-recursive.md) -- [libraries-08-04-validation-form-inheritance](component/libraries/libraries-08-04-validation-form-inheritance.md) -- [バリデータの追加・変更](component/libraries/libraries-08-05-custom-validator.md) -- [バリデータの明示的な呼び出し](component/libraries/libraries-08-06-direct-call-of-validators.md) -- [排他制御機能](component/libraries/libraries-08-ExclusiveControl.md) -- [バリデーションとFormの生成](component/libraries/libraries-08-Validation.md) - [数値型項目の場合の桁数精査の方法を教えて下さい](component/libraries/libraries-1.md) - [精査エラーのメッセージを、任意の項目に対応させて画面表示させる方法を教えてください](component/libraries/libraries-2.md) - [カンマ編集された値を数値型として精査することは出来ますか?](component/libraries/libraries-3.md) -- [ユーティリティ](component/libraries/libraries-99-Utility.md) -- [入力値のバリデーション](component/libraries/libraries-core-library-validation.md) -- [libraries-enterprise-messaging](component/libraries/libraries-enterprise-messaging.md) -- [libraries-file-access](component/libraries/libraries-file-access.md) -- [ファイルアップロード業務処理用ユーティリティ](component/libraries/libraries-file-upload-utility.md) -- [メール送信](component/libraries/libraries-mail.md) -- [libraries-messaging-sender-util](component/libraries/libraries-messaging-sender-util.md) -- [libraries-messaging-sending-batch](component/libraries/libraries-messaging-sending-batch.md) -- [libraries-record-format](component/libraries/libraries-record-format.md) -- [同一スレッド内でのデータ共有(スレッドコンテキスト)](component/libraries/libraries-thread-context.md) -- [拡張バリデータ・コンバータ](component/libraries/libraries-validation-advanced-validators.md) -- [libraries-validation-basic-validators](component/libraries/libraries-validation-basic-validators.md) -- [バリデーションに関するFAQ](component/libraries/libraries-validation-index.md) -### readers - -- [データベースレコードリーダ](component/readers/readers-DatabaseRecordReader.md) -- [ファイルデータリーダ](component/readers/readers-FileDataReader.md) -- [要求電文(FWヘッダ)リーダ](component/readers/readers-FwHeaderReader.md) -- [受信電文リーダ](component/readers/readers-MessageReader.md) -- [readers-ResumeDataReader](component/readers/readers-ResumeDataReader.md) -- [readers-ValidatableFileDataReader](component/readers/readers-ValidatableFileDataReader.md) -- [データリーダリファレンス](component/readers/readers-reader.md) +- [バリデーションに関するFAQ](component/libraries/libraries-validation.md) ## development-tools ### java-static-analysis @@ -203,20 +79,14 @@ - [テストに関するFAQ](development-tools/testing-framework/testing-framework-test.md) ### toolbox -- [Form自動生成ツール](development-tools/toolbox/toolbox-01-EntityGenerator.md) -- [JSP自動生成ツール](development-tools/toolbox/toolbox-01-JspGenerator.md) - [マスタデータ投入ツール](development-tools/toolbox/toolbox-01-MasterDataSetupTool.md) - [リクエスト単体データ作成ツール](development-tools/toolbox/toolbox-01-httpdumptool-01-HttpDumpTool.md) - [リクエスト単体データ作成ツール](development-tools/toolbox/toolbox-01-httpdumptool-index.md) - [マスタデータ投入ツール インストールガイド](development-tools/toolbox/toolbox-02-ConfigMasterDataSetupTool.md) - [マスタデータ投入ツール](development-tools/toolbox/toolbox-02-MasterDataSetup.md) - [リクエスト単体データ作成ツール インストールガイド](development-tools/toolbox/toolbox-02-SetUpHttpDumpTool.md) -- [JSP自動生成ツール インストールガイド](development-tools/toolbox/toolbox-02-SetUpJspGeneratorTool.md) - [HTMLチェックツール](development-tools/toolbox/toolbox-03-HtmlCheckTool.md) - [プログラミング工程で使用するツール](development-tools/toolbox/toolbox-08-TestTools.md) -- [環境設定ファイル自動生成ツール](development-tools/toolbox/toolbox-ConfigGenerator.md) -- [Shell Script自動生成ツール](development-tools/toolbox/toolbox-ShellGenerator.md) -- [toolbox-tool](development-tools/toolbox/toolbox-tool.md) ## guide ### libraries @@ -293,11 +163,6 @@ - [web-application-screenTransition](guide/web-application/web-application-screenTransition.md) ## processing-pattern -### mom-messaging - -- [mom-messaging-messaging-receive](processing-pattern/mom-messaging/mom-messaging-messaging-receive.md) -- [mom-messaging-messaging-request-reply](processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) -- [メッセージング実行制御基盤](processing-pattern/mom-messaging/mom-messaging-messaging.md) ### nablarch-batch - [バッチの処理対象件数をログに出力する方法はありますか？](processing-pattern/nablarch-batch/nablarch-batch-1.md) @@ -309,10 +174,7 @@ - [バッチ処理を実行すると **DuplicateProcess** が発生し、処理が異常終了してしまいます。対処方法を教えてください](processing-pattern/nablarch-batch/nablarch-batch-7.md) - [バッチ処理を実行するとProcessStop(kill process.)が発生し、処理が異常終了してしまいます。対処方法を教えてください](processing-pattern/nablarch-batch/nablarch-batch-8.md) - [入力データが存在しないバッチ処理はどのように作成するのでしょうか？](processing-pattern/nablarch-batch/nablarch-batch-9.md) -- [バッチ実行制御基盤](processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) -- [バッチに関するFAQ](processing-pattern/nablarch-batch/nablarch-batch-batch-index.md) -- [nablarch-batch-batch-resident](processing-pattern/nablarch-batch/nablarch-batch-batch-resident.md) -- [nablarch-batch-batch-single-shot](processing-pattern/nablarch-batch/nablarch-batch-batch-single-shot.md) +- [バッチに関するFAQ](processing-pattern/nablarch-batch/nablarch-batch-batch.md) ### web-application - [入力値で精査エラーが発生した場合に戻り先画面の情報はどのように取得したらよいですか？](processing-pattern/web-application/web-application-1.md) @@ -331,7 +193,6 @@ - [コード値精査時に指定するパターンには何を指定するのでしょうか？](processing-pattern/web-application/web-application-7.md) - [画面にワーニングメッセージを表示する方法を教えてください](processing-pattern/web-application/web-application-8.md) - [ユーザに権限があるかを簡単に確認する方法はありますか？](processing-pattern/web-application/web-application-9.md) -- [web-application-web-gui](processing-pattern/web-application/web-application-web-gui.md) - [画面オンライン開発に関するFAQ](processing-pattern/web-application/web-application-web.md) ## releases diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-01-NablarchOutline.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-01-NablarchOutline.md index 4e1c907b5..eea7d5c24 100644 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-01-NablarchOutline.md +++ b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-01-NablarchOutline.md @@ -217,11 +217,11 @@ Actionは必要に応じて、Componentの戻り値を処理(リクエストス > ここでは、バッチ、オンラインといった処理の形態に依存しない、共通的な概念についてのみ述べた。 > より具体的なアプリケーションの実装方法については、以下の各ドキュメントを参照すること。 -> ../04_Explanation/index -> ../04_Explanation_batch/index -> ../04_Explanation_messaging/index -> ../04_Explanation_messaging/04_Explanation_real/index -> ../04_Explanation_messaging/04_Explanation_delayed_receive/index -> ../04_Explanation_messaging/04_Explanation_delayed_send/index -> ../04_Explanation_messaging/04_Explanation_send_sync/index -> ../04_Explanation_other/04_Explanation_mail/index +* [業務アプリケーションの実装方法 (画面オンライン処理編)](../../guide/web-application/web-application-04-Explanation.md) +* [業務アプリケーションの実装方法 (バッチ処理編)](../../guide/nablarch-batch/nablarch-batch-04-Explanation-batch.md) +* [業務アプリケーションの実装方法 (メッセージング処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-messaging.md) +* [業務アプリケーションの実装方法 (同期応答メッセージ受信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-real.md) +* [業務アプリケーションの実装方法 (応答不要メッセージ受信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-delayed-receive.md) +* [業務アプリケーションの実装方法 (応答不要メッセージ送信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-delayed-send.md) +* [業務アプリケーションの実装方法 (同期応答メッセージ送信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-send-sync.md) +* [業務アプリケーションの実装方法 (メール送信処理編)](../../guide/libraries/libraries-04-Explanation-mail.md) diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-02-I18N.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-02-I18N.md deleted file mode 100644 index b868c4596..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-02-I18N.md +++ /dev/null @@ -1,146 +0,0 @@ -# 国際化対応 - -本フレームワークが国際化対応で実装する要求と実装方針について以下に示す。 - -## 要求 - -本フレームワークでは、次の方針に基づき国際化対応で実装する要求を選定する。 - -* アプリケーションを多言語化する際に使用頻度が高い要求に対応する。 -* アプリケーション毎の差異がない一般化された要求(日付、数字など)に対応する。 - 一般化できない要求の一例を下記に示す。 - - * 名前(姓名順序、ミドルネーム) - * 住所 - * 通貨変換 - * 単位変換(長さ(メートル、マイルなど)、重さ(キロ、ポンドなど)) - -本フレームワークが国際化対応で実装する要求を下記に示す。 - -* ユーザが言語とタイムゾーンを選択できる。 - - * リクエストパラメータ(選択画面またはリンクなど) - * ブラウザの言語設定 -* ユーザが選択した言語とタイムゾーンを保持できる。(クッキーまたはHTTPセッション) -* 指定された言語で表示できる。 - - * 画面(メッセージ、項目名、画面名、メニュー名、ボタン名など) - * 帳票(タイトル、項目名など) - * 照会結果ファイル(CSVファイルのヘッダ部など) - * メール(件名、メール本文) - * コード(コード値としてあらかじめマスタ登録する項目(性別、単位、区分など)の名称) - * 日付(年月日順(YYMMDD、MMDDYY、DDMMYYなど)) - * 数字(区切り文字(123,456.789、123.456,789)) - * 障害メッセージ(障害発生時に出力される障害コードに対応するメッセージ) -* 指定されたタイムゾーン(サマータイム含む)に応じて日時を表示できる。(基準となるタイムゾーンからの時差を考慮し表示する) -* リソース(ファイルやデータなど)追加のみで対応言語を追加できる。 - -本フレームワークで対応していない要求については、多言語化を行うアプリケーション毎に対応する。 - -## 本フレームワークの全ての機能に共通する国際化対応の実装方針 - -### RDBMS上データの保持方法 - -本フレームワークでは、RDBMS上に各国語対応が必要なデータを配置する際、必ずデータベースに対応する言語を表すカラムを持つポリシーとする。 -例えばメッセージを保持するデータベースは下記例のようなカラム定義を行うことを前提としている。 - -| カラム名 | データ型 | 備考 | -|---|---|---| -| MESSAGE_ID | VARCHR2(10) | メッセージのキー | -| LANG | VARCHR2(10) | 対応する言語('EN','JA'等) | -| MESSAGE | VARCHR2(150) | メッセージ | - -なお、この方針は本フレームワークのみに影響する方針であり、本フレームワークを使用したアプリケーションではこの方針に従う必要はない。 - -### 言語を指定した取得方法 - -本フレームワークの各国語対応を行う機能は、基本的にスレッドローカルに保持した言語を使用するため、言語を明示的に渡す必要はない。 -ただし、複数言語を同時に1つの画面内に表示するなど、言語を明示的に指定するようなケースを想定して、 -言語によって処理内容が異なる機能では必ず言語を指定した呼び出しができるよう考慮する。 - -例えば言語に対応するメッセージを取得する機能を提供するクラスであれば、下記のように2通りの呼び出し方法を持つ。 - -スレッドに紐付けられた言語でメッセージを取得する場合 - -```java -String msg = MessageResource.get("MSG0001"); -``` - -英語のメッセージを取得する場合 - -```java -String msg = MessageResource.get("MSG0001", "EN"); -``` - -### フレームワーク内で作成するログ出力メッセージの使用言語 - -本フレームワーク内で作成するログ出力メッセージは、世界で広く普及している英語を使用することとし、国際化は行わない。 - -### ファイル入出力の文字コード - -本フレームワークでファイル入出力を伴う機能を提供する場合は、設定によりファイルの文字コードを指定できるよう考慮する。 -このため、本フレームワークのファイル入出力機能を使用することで、アプリケーションを国際化対応できる。 - -## Webアプリケーションに特化した国際化対応の実装方針 - -### 言語の選択と保持 - -Webアプリケーションでは、言語を選択する方法には、様々な方法が存在する。 -本フレームワークでは、言語を選択する方法のうち、頻繁に使用される下記の選択方法のみ提供する。 - -* ブラウザの言語設定で指定された言語を選択する。 - -アプリケーションで言語を選択する方法には、上記本フレームワークが提供する選択方法の他に、ユーザが言語を選択 -する方法が考えられる。 -しかし、下記のようなユーザの操作により言語を選択する方法は実現方法、選択方法が多岐に渡り、典型的な方法を特定できない。 - -* ユーザが画面上で言語を選択する。 -* ログインしたユーザに紐づく言語を選択する。 - -このため、本フレームワークではユーザの操作により言語を選択する方法自体は提供しない。 -ただし、本フレームワークの規定する拡張ポイントで、アプリケーション毎にユーザが選択した言語を取得する方法を実装 -した場合には、選択した言語による表示が可能となるよう考慮する。 - -本フレームワークでは、使用する言語をユーザからのリクエストごとに下記の優先順位で選択する。 - -1. クッキーまたはHTTPセッションに保持している言語を選択する。 -2. ブラウザの言語設定が取得できた場合、最も優先されている言語を選択する。 -3. アプリケーションで設定するデフォルト言語を選択する。 - -なお、上記で選択した言語は、スレッドローカルに保持することとし、リクエストの処理完了までいつでも取得できる。 - -言語の選択と保持方法の詳細は、共通ハンドラの [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) を参照。 - -### タイムゾーンの選択と保持 - -タイムゾーンの選択と保持は、 [言語の選択と保持](../../about/about-nablarch/about-nablarch-02-I18N.md#言語の選択と保持) と同じ方針とする。 -ただし、ブラウザの設定でタイムゾーンを指定することができないため、ブラウザの設定によるタイムゾーン選択は存在しない。 -ユーザにタイムゾーンを選択させる場合は、アプリケーション毎に選択方法を実装する必要がある。 - -タイムゾーンの選択と保持方法の詳細は、共通ハンドラの [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) を参照。 - -### JSPファイルおよび静的ファイルのパス - -一般的にJSPファイルと、JSPファイルから参照される画像ファイルやCSSファイルといった静的ファイルのパスは、 -言語ごとに異なる指定が必要となるため、国際化対応の検討が必要となる。 - -JSPファイルを国際化対応する方法には、次の2通りの方法が考えられる。 - -* JSPファイル中に記述する全ての文字列を国際化されたリソースから取得するように記述する方法 -* JSPファイル自体を言語ごとに用意する方法 - -本フレームワークでは、上記2通りの方法をサポートする。 -これは、多言語化対象の言語種類により、デザインが異ならないためJSPファイルを共通化することが可能な場合と、 -デザインが異なるためJSPファイルを共通化できない場合があり、どちらのケースにも対応できるようにするためである。 - -本フレームワークでは複数言語に対してJSPファイルを共通化することを可能とするため、 -JSPファイルに記述される静的ファイルのパスについてもファイル自体を言語ごとに用意する方法をサポートする。 - -ファイル自体を言語ごとに用意する場合、次の2通りの方法を提供する。 - -* 言語毎にディレクトリを分ける方法 -* 言語ごとにファイルを分ける方法 - -JSPファイル中で国際化されたリソースの取得方法の詳細は、カスタムタグの [メッセージの表示](../../component/libraries/libraries-07-DisplayTag.md#メッセージの表示) を参照。 -JSPファイルの言語ごとのパス切り替え方法の詳細は、Webフロントコントローラの [言語毎のコンテンツパスの切り替え](../../component/handlers/handlers-HttpResponseHandler.md#言語毎のコンテンツパスの切り替え) を参照。 -静的ファイルの言語ごとのパス切り替え方法の詳細は、カスタムタグの [言語毎のリソースパスの切り替え](../../component/libraries/libraries-07-BasicRules.md#言語毎のリソースパスの切り替え) を参照。 diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-04-RDBMS-Policy.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-04-RDBMS-Policy.md deleted file mode 100644 index 153aa910f..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-04-RDBMS-Policy.md +++ /dev/null @@ -1,77 +0,0 @@ -# RDBMS の使用ポリシー - -本フレームワークの一部の機能は、RDBMSの使用を前提としている。 - -ここではこれらの機能で RDBMS を使用する際に適用するポリシーについて記載する。 - -## RDBMS への依存の排除 - -Nablarch は、製品全体のポリシーとして、特定の製品への依存させないポリシーを取っている。 -RDBMS 製品への依存もこのポリシーを踏襲しており、 Nablarch の各機能は RDBMS 製品を問わず動作することを目指す。 - -RDBMS 製品への依存を排除するため、本フレームワークの機能で使用するテーブルは、RDBMS 非依存の形態として定義する。 - -### カラムの定義方法 - -RDBMS 製品への依存を排除するため、 RDBMS の使用を前提とする機能では、データの型を RDBMS 上の型ではなく Java の -データ型で定義する。 - -例えば Oracle で VARCHAR2 の値を使用する際は、 java.lang.String で取り扱うと記載する。 - -### テーブル定義に使用するデータ型 - -RDBMS への依存を排除することの2つの目的を果たすために、フレームワークではデータの持つ意味に合わせて Java のデータ型とデータの内容を規定する。 -実際のテーブル定義でどのようなデータ型を採用するかはフレームワークで規定せず、アプリケーションのテーブル設計にて決定する方針とする。 - -フレームワークで使用する RDBMS に保存するデータの用途と、データに対応する Java のデータ型、フレームワークが求めるデータ保持方法に関する規定について以下に示す。 -ここで示す以外のデータはフレームワークから使用しない。 - -| データの用途 | Javaのデータ型 | データベース上のデータ保持方法の規定 | -|---|---|---| -| 文字列 | java.lang.String | 文字列として取得、設定できる項目であることのみ規定する。 アプリケーションの設計時は、 Oracle の VARCHAR2 のような 可変長文字列型、あるいは CHAR のような固定長文字列型のいずれかを 選択する。 データ長については、アプリケーションの利用形態に合わせて 設計することとして、フレームワークでは規定しない。 | -| 数値 | int long java.math.BigDecimal | int , long といった 整数型の場合は小数点以下に値を持たないデータ型であることを規定する。 整数部、小数部の桁数については、アプリケーションの設計時に適切な 値を決定する。 | -| 日付 | java.lang.String | フレームワークでは、日付を yyyyMMdd 形式の8ケタの文字列で表現する。 このため、データベース上では8ケタの文字列を保持できるデータ型であること を規定する。 アプリケーションの設計時は、 Oracle の VARCHAR2 のような可変長文字列型、 あるいは CHAR のような固定長文字列型のいずれかを選択する。 | -| 日時 | java.sql.Timestamp | java.sql.Timestamp 型で取得できることのみ規定する。 データベース上のデータ型は Oracle の DATE あるいは TIMESTAMP といった日付と 時刻の情報を持つデータ型を選択する。 | - -## 共通項目の更新について - -アプリケーションでは、慣例的、あるいは機能的な要求により「最終更新日時」、「最終更新者」、「作成日時」、「作成者」、 -「削除フラグ」、「削除日」といったカラムをテーブル間で共通的に付与することがある。 -これら共通項目を付与する場合、「最終更新日時」、「最終更新者」、「作成日時」、「作成者」といった項目はレコードの作成、 -更新時に、画一的に更新するポリシーを設定することが一般的である。 - -本フレームワークのいくつかの機能では、テーブルに対する更新を行うが、基本的にテーブル更新時にこれら共通項目の更新ができる機能をサポートしない。 -これはフレームワークにより更新を行うことで、アプリケーションに下記問題が発生する可能性を考慮しての方針である。 - -* 仕様頻度が高い機能で共通項目を更新することで、テーブル更新にかかるコストが増大してパフォーマンス劣化につながる問題 -* アプリケーションに意味のない更新(例えばログイン失敗時にパスワード間違い回数を増加させる)によって共通項目が上書きされ、元にあった「最終更新者」等の情報が消失する問題 - -ただし、上記で示した問題が発生する可能性がなく、アプリケーションにとって有益であると判断した際は、例外的にテーブル更新時に共通項目を更新する機能を提供するものとする。 - -## フレームワークで規定するテーブルへのアクセスについて - -前述の通り、フレームワークでは、テーブルの設計のうち、基本的なカラムのみ規定している。 -フレームワークで規定したテーブルの詳細な設計は、アプリケーションのテーブル設計時に策定する方針としている。 - -フレームワークでは、業務ロジックから頻繁に使用され、アプリケーションの要求による影響が発生しづらいロジックについて -データの参照、更新を行う機能を提供する。 - -業務ロジックからは、必要に応じてフレームワークが規定するテーブルにアクセスする。 - -この方針は、データベースの情報を業務ロジックから参照・更新させないルールを設定した場合に発生する下記問題が、 -アプリケーションにとって致命的だと考えた結果策定したものである。 - -* フレームワークが規定するテーブルとアプリケーション独自のテーブルを結合できない問題。 -* フレームワークが規定するテーブルのレコードを追加、更新する際、一括登録APIやデータローダを使用できず、効率が悪化する問題。 - -ただし、フレームワークが規定するテーブルへのアクセスを許可した場合、フレームワークのバージョンアップにより、 下記問題が発生する恐れがある。 - -* バージョンアップ時に、フレームワークが規定するテーブルにカラムが追加された場合、テーブル構造の変更と - アプリケーションの再テストが必要となってしまう問題。 -* フレームワークが規定するテーブルのカラムに設定する値の意味が変更されることにより、 - このカラムを参照、更新する業務ロジックを値の意味が合うように修正しなければならなくなる問題。 - -これら問題を発生させないために、リリース済みのフレームワークでは下記を保証する。 - -* フレームワークが規定するテーブルについて、カラムの追加や、カラムの属性の変更なしにフレームワークをバージョンアップできること。 -* フレームワークが規定するテーブルのカラムについて、カラムに設定した値の意味を変更しないこと。 diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-FAQ.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-FAQ.md index 8f1f69a27..559ef016a 100644 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-FAQ.md +++ b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-FAQ.md @@ -7,8 +7,8 @@ Nablarch開発時に発生するよくある質問を纏めたものである。 ## FAQ一覧 -web/index -batch/index -validation/index -test/index -all/index +* [画面オンライン開発に関するFAQ](../../processing-pattern/web-application/web-application-web.md) +* [バッチに関するFAQ](../../processing-pattern/nablarch-batch/nablarch-batch-batch.md) +* [バリデーションに関するFAQ](../../component/libraries/libraries-validation.md) +* [テストに関するFAQ](../../development-tools/testing-framework/testing-framework-test.md) +* [Nablarchの全般的なFAQ](../../about/about-nablarch/about-nablarch-all.md) diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-all.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-all.md index d5bf82ddb..c29003758 100644 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-all.md +++ b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-all.md @@ -1,8 +1,8 @@ # Nablarchの全般的なFAQ -1 -2 -3 -4 -5 -6 +* [SqlRow等のMap実装クラスからEntityやFormを生成する方法を教えてください](../../about/about-nablarch/about-nablarch-1.md) +* [configファイルの設定値の取得方法を教えてください](../../about/about-nablarch/about-nablarch-2.md) +* [コード名称やコード存在チェック時に指定するパターンには、何を指定したらいいのでしょうか？](../../about/about-nablarch/about-nablarch-3.md) +* [データベースアクセスを伴う精査処理は、Actionでおこなうのでしょうか？](../../about/about-nablarch/about-nablarch-4.md) +* [メッセージIDと障害コードの違いは何でしょうか？](../../about/about-nablarch/about-nablarch-5.md) +* [DB2やSQLServerでのバイナリ型のカラムへのアクセス方法を教えてください](../../about/about-nablarch/about-nablarch-6.md) diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-architectural-pattern-concept.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-architectural-pattern-concept.md deleted file mode 100644 index 3cbfeb825..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-architectural-pattern-concept.md +++ /dev/null @@ -1,891 +0,0 @@ -## NAF基本アーキテクチャ - -NAFは、画面オンライン処理、バッチ処理、メッセージング処理 といった -基幹システムで必要とされる広範な実行形態をサポートしつつも、 -簡潔かつ単一の制御モデルに従って動作するという特徴を備える。 - -この節では、全ての処理において共通となるNAFアプリケーションの動作モデルについて解説する。 - ------ - ------ - ------ - ------ - ------ - ------ - -### NAFのアプリケーション動作モデル - -NAFにおけるアプリケーションの動作モデルは極めて単純である。 - -まず、アプリケーションに対して何らかの依頼がなされる。この依頼を **リクエスト** と呼ぶ。 -リクエストは依頼したい **「処理」** と **「データ」** から構成され、NAFにおける処理の最小単位となる。 - -例えば、画面オンライン処理では、ブラウザが送信するHTTPリクエストが処理の最小単位となり、 -バッチ処理ではファイルもしくはDB上のデータレコードが処理の最小単位となりうる。 - -次にアプリケーションは与えられたリクエストに対して処理を行い、その処理結果を返す。 -画面オンライン処理であれば、HTTPレスポンスの内容が返され、 -バッチ処理では入力レコードに対する処理結果ステータスが返される。 - -**NAFアプリケーションの基本構造** - -NAFにおけるアプリケーションの処理は、「トランザクション制御」や「応答電文の送信」といったステップごとに -細かく分割され、それぞれ **ハンドラ** と呼ばれるモジュールによって実装される。 - -これらのハンドラは、あらかじめ定められた順序に沿って並べられ、順次 **リクエスト** を処理していく。 -このとき、内部的には、各ハンドラを実行順に並べたキューが作成される。 -これを **ハンドラキュー** とよぶ。 - -ハンドラが呼び出される際、引数として **リクエスト** が渡される。 -各ハンドラはこれをもとに必要な処理を行った後、同じ **リクエスト** を引数としてハンドラキュー上の次のハンドラを呼び出す。 -こうして、ハンドラキュー上のハンドラを先頭から順次実行していき、最終的に業務ロジックを実装したハンドラを実行する。 -このハンドラを **業務アクションハンドラ** と呼ぶ。 -業務アクションハンドラは業務処理を実行し、その処理結果をリターンする。 -各ハンドラはリターンされた処理結果に対して(必要であれば)処理を行い、再びリターンしていく。 -これにより、処理結果はハンドラキューを **リクエスト** の時とは逆の方向に遡っていき、 -先頭のハンドラまで処理結果が戻された時点で処理が完了する。 - -次の図はこの内容を表した模式図である。 -(①～⑥の順) - -![handler_queue.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/handler_queue.png) - -**NAFにおけるアプリケーションの基本構造** - -### 標準ハンドラ構成 - -NAFには、以下に挙げるような様々な機能を実装したハンドラが存在している。 -NAFの機能は、基本的にこれらのハンドラの組み合わせによって実現されている。 - -**汎用的に使用できるハンドラ** - -* [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) -* [リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) -* [認可制御ハンドラ](../../component/handlers/handlers-PermissionCheckHandler.md) -* [開閉局制御ハンドラ](../../component/handlers/handlers-ServiceAvailabilityCheckHandler.md) ... など - -**画面オンライン処理に固有のハンドラ** - -* [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) -* [HTTPアクセスログハンドラ](../../component/handlers/handlers-HttpAccessLogHandler.md) -* [Nablarchカスタムタグ制御ハンドラ](../../component/handlers/handlers-NablarchTagHandler.md) ... など - -**バッチ処理に固有のハンドラ** - -* [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) -* [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) -* [プロセス多重起動防止ハンドラ](../../component/handlers/handlers-DuplicateProcessCheckHandler.md) ... など - -**メッセージング処理に固有のハンドラ** - -* [電文応答制御ハンドラ](../../component/handlers/handlers-MessageReplyHandler.md) -* [再送電文制御ハンドラ](../../component/handlers/handlers-MessageResendHandler.md) ... など - -NAFでは、標準的なハンドラキューの構成を用途ごとに定義しており、それらを **標準ハンドラ構成** と呼んでいる。 - -以下の図は、オンライン画面処理で使用される標準ハンドラ構成を表した概念図である。 - -![handler_structure_online_minify.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/handler_structure_online_minify.png) - -**画面オンライン処理ハンドラ構成(簡易版)** - -バッチ処理では以下のようになる。 - -リクエスト/処理結果の型や、ハンドラキューの構成が一部異なるものの、 -基本的な処理フローは同じだということがわかる。 - -![handler_structure_batch_minify.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/handler_structure_batch_minify.png) - -**バッチ処理ハンドラ構成(簡易版)** - -> **Note:** -> ここであげた標準ハンドラ構成は、主要なハンドラのみをピックアップした簡易版である。 -> 実際のハンドラ構成については、以下の各項を参照すること。 - -> * > [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) -> * > [都度起動バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-batch-single-shot.md) -> * > [常駐バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-batch-resident.md) -> * > [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) -> * > [応答不要メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-receive.md) - -### アプリケーションの実行と初期化処理 - -**リポジトリによるハンドラ構成の初期化** - -前節で述べた方式に従って処理を実行するためには、 -アプリケーションの起動時に標準ハンドラ構成に沿ったハンドラキューを構築する必要がある。 - -NAFでは、DI(Dependency Injection)ベースのオブジェクト管理機構([リポジトリ](../02_FunctionDemandSpecifications/01_Core/02_Repository.html))を実装しており、 -アプリケーションの動作に必要となる全てのオブジェクトの生成と初期化処理を行う。 -前節で述べたハンドラキューもリポジトリによって構築されるオブジェクトの一つである。 - -以下は、バッチ処理におけるリポジトリ初期化設定ファイルの中から、 -ハンドラ構成の定義部分を抜粋したものである。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -**NAFアプリケーションの実行方法** - -NAFアプリケーションの実行方法は2とおり存在する。一つはjavaコマンドから直接起動する方法、 -もう一つはTomcatなどのサーブレットコンテナにデプロイして実行する方法である。 - -[画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) では、サーブレットAPIの使用が前提となるため後者の方法をとる。 -一方、それ以外の処理( [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) など)では、javaコマンドから直接起動する方法をとる。 - -**サーブレットコンテナ上での実行** - -NAFアプリケーションをサーブレットコンテナ上で実行するには -[Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md) および、 [Webフロントコントローラ (サーブレットフィルタ)](../../component/handlers/handlers-WebFrontController.md) -をアプリケーションサーバにデプロイする。 - -[Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md) は、アプリケーションデプロイ時に web.xml に設定された -リポジトリの設定ファイルを読み込み、リポジトリの初期化を行なう。 -ハンドラキューの構築についても、この初期化の中で行なわれる。 - -[Webフロントコントローラ (サーブレットフィルタ)](../../component/handlers/handlers-WebFrontController.md) は、アプリケーションに対する全てのHTTPリクエストを -ハンドラキューに対する入力データとして処理する。 -業務処理の実行や、処理結果画面の送信といった処理はハンドラキュー上の各ハンドラによって実行される。 - -以下はデプロイメントディスクリプタの記述例である。 - -```xml - - - - di.config - web-component-configuration.xml - - - - nablarch.fw.web.servlet.NablarchServletContextListener - - - - controller - nablarch.fw.web.servlet.RepositoryBasedWebFrontController - - - - controller - /* - - - - -``` - -> **Note:** -> 詳細については以下の各項を参照すること。 - -> * > [Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md) -> * > [Webフロントコントローラ (サーブレットフィルタ)](../../component/handlers/handlers-WebFrontController.md) - -**Javaコマンドでの実行** - -NAFアプリケーションを通常のJavaコマンドから実行する場合は、 [共通起動ランチャ](../../component/handlers/handlers-Main.md) のメイン関数を実行する。 -この関数では、起動引数で指定された [リポジトリ](../02_FunctionDemandSpecifications/01_Core/02_Repository.html) の設定ファイルを読み込んでその初期化を行なう。 -ハンドラキューの構築もこの初期化の中で行なわれる。 - -アプリケーションの処理は、起動引数を格納したオブジェクトを入力としてハンドラキューを実行することによって行なわれる。 - -以下は、NAFバッチアプリケーションの起動コマンドの例である。 -(リポジトリ設定ファイルのパスは起動引数 **[-diConfig]** で与えられる。) - -```sh -java \ - -Xmx128m \ - -DcommitInterval=100 \ - -DmaxExecutionCount=100000 \ -nablarch.fw.launcher.Main \ - -diConfig file:./batch-config.xml \ - -requestPath admin.DataUnloadBatchAction/BC0012 \ - -userId batchUser012 -``` - -> **Note:** -> 詳細については [共通起動ランチャ](../../component/handlers/handlers-Main.md) の項を参照すること。 - -### ハンドラの構造と実装 - -**ハンドラインターフェースの定義** - -ハンドラクラスとは、以下のインターフェース **nablarch.fw.Handler** を実装したクラスのことを指す。 - -```java -package nablarch.fw; -/** - * NAFのパイプライン処理において、 - * 各ステップの処理を実装するモジュール(ハンドラ)が - * 実装するインターフェース。 - * - * @param リクエストデータ型 - * @param 処理結果データ型 - * - * @author Iwauo Tajima - * @since 1.0 - */ -public interface Handler { - /** - * リクエストに対する処理を実行する。 - * - * @param data リクエストデータ - * @param context 実行コンテキスト - * @return 処理結果 - */ - TResult handle(TData data, ExecutionContext context); -} -``` - -このインターフェースにはただ1つのメソッド `handle()` が定義されている。 -ハンドラの全ての責務は基本的にこのメソッドに対して実装される。 - -> **Note:** -> ただし、業務アクションハンドラを実装する場合は、Handlerインターフェース直接実装するのでは無く、 -> 典型的な処理がテンプレート化されたクラスが提供されているので、それらを利用して実装する。 - -> * > [業務アクションハンドラ](../../component/handlers/handlers-handler.md#業務アクションハンドラ) - -`handle()` メソッドの第一引数には、リクエストの内容を保持したオブジェクトが渡される。 -リクエスト型はハンドラごとに型変数として宣言され、そのハンドラがリクエストをどのように扱うかを表す。 -次の表は、 [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) で利用するハンドラを型変数で分類したものである。 - -| 型変数 | ハンドラの処理内容 | ハンドラの例 | -|---|---|---| -| Object | データベーストランザクション制御などの リクエストの内容に(直接には)関係しない処理を行う。 | [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) [開閉局制御ハンドラ](../../component/handlers/handlers-ServiceAvailabilityCheckHandler.md) | -| [Request](../../javadoc/nablarch/fw/Request.html) | 業務アクションハンドラのディスパッチなど リクエストの内容に沿った共通処理を行う。 (詳細は [リクエストの識別と業務処理の実行](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) を参照) | [リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) [リクエストハンドラエントリ](../../component/handlers/handlers-RequestHandlerEntry.md) | -| [HttpRequest](../../javadoc/nablarch/fw/web/HttpRequest.html) | HTTPアクセスログの記録など HTTPリクエストに直接依存した処理を行う。 | [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) [HTTPアクセスログハンドラ](../../component/handlers/handlers-HttpAccessLogHandler.md) | - -この型引数は、各ハンドラの適用範囲も表す。 -例えば、 `Object` や [Request](../../javadoc/nablarch/fw/Request.html) を型変数とするハンドラは、 [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) だけでなく、 -[バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) や [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) においても共用することができる。 -一方、 [HttpRequest](../../javadoc/nablarch/fw/web/HttpRequest.html) を型変数とするハンドラは、 [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) 以外で使用することはできない。 - -第二引数には、 **実行コンテキスト** と呼ばれる、アプリケーション実行中にサーバ側で使用する以下の制御情報を格納したオブジェクトが渡される。 -(各項目の詳細についてはリンク先の解説を参照) - -* [ハンドラキュー](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#nafのアプリケーション動作モデル) -* [リクエストスコープ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#変数スコープ) -* [セッションスコープ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#変数スコープ) -* [データリーダ/データリーダファクトリ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#データリーダ) - -`handle()` メソッドはその戻り値として、ハンドラの処理結果を表すオブジェクトを返す。 -処理結果オブジェクトの型もリクエストと同様、処理方式ごとに異なるため、ハンドラごとに型変数として -宣言する必要がある。 - -**ハンドラ処理フロー** - -1つのハンドラの処理内容は以下の3つのブロックに分けて考えることができる。 - -**1. 往路処理** - -`handle()` メソッド開始から、後続のハンドラに処理を移譲するまでの間に実行される処理。 - -主に、入力データの内容をもとにした事前処理を実行する。 -**(例: 権限チェック、トランザクションの開始、アクセスログ出力など)** - -**2. 復路処理** - -後続ハンドラでの処理が正常終了してから `handle()` メソッド終了までの間に実行される処理。 - -主に後続ハンドラの処理結果を用いた処理や、正常終了時の事後処理を実行する。 -**(例: クライアントに対する応答送信、トランザクションのコミット、リソースの開放など)** - -**3. 例外処理** - -当該のハンドラもしくは、後続ハンドラの処理中に例外が発生した場合に実行される処理。 - -主に後続ハンドラでエラー終了した場合の事後処理を実装する。 -**(例: クライアントに対するエラー応答送信、障害ログの出力、トランザクションのロールバック、リソースの開放など)** - -以下のソースコードは、後続のハンドラに対するトランザクション制御を行なうハンドラのサンプルコードである。 - -```java -public class TransactionHandler implements Handler { - - public Result handle(Request request, ExecutionContext context) { - try { - /* 1. (往路処理) トランザクションを開始する。*/ - beginTransaction(request, context); - - Result result = context.handleNext(request); // ExecutionContext#handleNext() を実行することで、 - // ハンドラキュー上の後続ハンドラに処理が移譲され、 - // その処理結果が返される。 - /* 2. (復路処理) トランザクションをコミットする。*/ - commitTransaction(result, request, context); - - //正常終了 - return result; // 後続のハンドラの処理結果をそのまま返却する。 - - /* 3. (例外処理) トランザクションをロールバックする。*/ - } catch (RuntimeException e) { // handle() メソッドはチェック例外を送出しないため、 - rollbackTransaction(e, request, context); // 実行時例外(java.lang.RuntimeException)もしくは、 - throw e; // エラー(java.lang.Error) のいずれかが送出される。 - - /* 3. (例外処理) トランザクションをロールバックする。*/ - } catch (Error e) { // 通常の用途ではjava.lang.Errorを捕捉する必要はない。 - rollbackTransaction(e, request, context); - throw e; - - /* (終端処理) トランザクションの終了*/ - } finally { // 2. 復路処理、3. 例外処理の双方で実行される。 - endTransaction(request, context); - } - } - - private void beginTransaction(Request request, ExecutionContext context) { - // (後略) - } -} -``` - ------ - -### リクエストの識別と業務処理の実行 - -この項では、外部から送信される各リクエストに対し、必要な業務処理を実装する業務アクションハンドラを実行する -共通的な仕組みについて解説する。 - -#### リクエストIDと実行時ID - -**リクエストID** - -リクエストは依頼したい **処理** と **データ** から構成されるが、この **処理** を一意に識別する情報が **リクエストID** である。 -リクエストIDは実装レベルにおいて後述の **リクエストパス** の一部に含まれる。 - -**実行時ID** - -**実行時ID** は、各リクエストを実行するごとに割り振られる一意文字列であり、各種のログやデータベース上で個別の -業務処理を識別し、トレースする目的で使用する。 - -#### リクエストに対する業務処理のディスパッチ - -**リクエストパス** - -**リクエストパス** は、NAFが各リクエストを実行する業務アクションハンドラを特定するためのものである。 -**リクエストID** を部分文字列に含み、 リクエストID と1対1の関係を持つ。依頼したい処理を リクエストパス -または リクエストID の形で指定することで、リクエスト毎に実行する業務処理を切り替えることができる。 - -なお、一般的なバッチ処理のように全リクエスト(この場合は全ての入力レコード)に -同一の業務アクションハンドラを割り当てる場合、リクエスト内に リクエストパス や リクエストID を含める必要はなく、 -プロセスの起動引数などにリクエストパスを指定すれば、全てのリクエストに対してそれが適用される。 - -**リクエストパス** の内容は、実行制御基盤ごとに以下のように定められる。 - -| リクエストの種類 | 実行制御基盤 | リクエストパス | 備考 | -|---|---|---|---| -| HTTPリクエスト | [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) | リクエストURI | リクエストURIをリクエストパスとして使用する。 URIのパス階層を業務アクションハンドラのパッケージとクラスにマッピングする。 | -| 処理要求電文 | [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) | FWヘッダ領域の 特定のフィールド | 受信電文中の特定のフィールドをリクエストIDとして読み込む。 リクエストパスとは異なり、リクエストIDには階層構造が含まれないので、 外部設定により業務アクションハンドラのパッケージを指定し、リクエストIDに 対応するクラスにディスパッチする。 ただし、受信電文中にリクエストIDに相当するフィールドが存在しない場合は、 後述する **コマンドラインオブジェクト** のリクエストパスを使用する。 この場合、ディスパッチは行われず、全ての電文は単一の業務アクションハンドラ によって処理される。 | -| データレコード | [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) | ファイル/DBテーブル の特定のカラム値 | バッチ処理では、入力ファイルやDBテーブルの特定のカラム値をリクエストID として読み込むことで、レコード毎に個別の業務アクションハンドラを 実行することができる。 ただし、一般的なバッチ処理では、リクエスト(=処理対象レコード)内に リクエストIDに相当するデータが存在するとは限らないため、その場合は 後述する **コマンドラインオブジェクト** に指定された値を使用して、 単一の業務アクションハンドラで処理を行う。 | -| コマンドライン | [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) | 起動コマンドの 特定のパラメータ値 | リクエストにリクエストID もしくは リクエストパスに相当するデータが 含まれない場合は、リクエスト毎のディスパッチは行なず、 全てのリクエストに対して、プロセスの起動パラメータに指定したリクエストパス に対応する業務アクションハンドラを実行する。 | - -**リクエストパスとリクエストIDのマッピング** - -アプリケーションが実装する業務処理を実行するためには、その **リクエストID** を指定する必要がある。 -リクエスト中の **リクエストパス** と **リクエストID** は、標準設定において以下の例のように紐付けられる。 - -| リクエストパスの形態 | リクエストパス | リクエストID | -|---|---|---| -| リクエストURI | **http ://www.example.com/app/admin/UserAction/WAA0010.do** | WAA0010 | -| プロセス起動引数 | **-requestPath admin.DataUnloadBatchAction/BC0012** | BC0012 | - -※ [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) では、通常、リクエストIDが直接リクエストに含まれるため、マッピングは不要である。j - -リクエストパスとリクエストIDとの紐付けは [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) が行い、以降のハンドラではリクエストIDをスレッドコンテキスト上の -変数として参照することができる。 - -**リクエストパス/リクエストID と業務アクションハンドラのマッピング** - -リクエスト中の **リクエストパス** ないし **リクエストID** に対して、業務アクションハンドラをマッピングする処理は、 -[リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) で行なわれる。 -マッピングされた業務アクションハンドラはハンドラキュー上に追加され、後続の処理の中で呼ばれる。 - -#### 特殊なリクエスト処理 - -**内部フォーワード処理と内部リクエストID** - -**内部フォーワード処理** とは、リクエスト処理を実行中に、それまでのリクエストパスとは異なるリクエストパスを用いてハンドラキューの内容を -再実行する処理である。(詳細は [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) を参照) - -この際、 **リクエストパス** の値は変更されるものの、 **リクエストID** および **実行時ID** は、同一リクエストを処理している間は不変である。 -これは、 **リクエストパス** がリクエストとそれに対して実行する業務処理をマッピングするため文字表現であるのに対し、 -**リクエストID** および **実行時ID** は、それぞれ、リクエストおよびその実行を識別するIDであるためである。 - -なお、変更後のリクエストパスに対するリクエストIDは、スレッドコンテキスト上の別変数として格納される。 -これを **内部リクエストID** とよぶ。 - -例えば、開閉局制御と認可制御に内部リクエストIDを使用することで、フォワード先のリクエストIDで -開閉局制御と認可制御が実施できる。 -開閉局制御と認可制御にリクエストIDを使用した場合と内部リクエストIDを使用した場合の動作の違いを下記に示す。 - -![internal_req_usecase.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/internal_req_usecase.png) - -開閉局制御と認可制御に内部リクエストIDを使用する場合は、各ハンドラの設定が必要である。 -設定方法は、 [開閉局制御ハンドラ](../../component/handlers/handlers-ServiceAvailabilityCheckHandler.md) 、 [認可制御ハンドラ](../../component/handlers/handlers-PermissionCheckHandler.md) を参照。 - ------ - -**メソッドレベルバインディング** - -[リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) によってハンドラキュー上に配置された業務アクションハンドラは、 -通常のハンドラと同様、 `handle()` メソッドが呼ばれるので、そこに業務処理を実装する必要がある。 -しかし、以下に述べる **メソッドレベルバインディング** と呼ばれるしくみを用いることで、 -`handle()` メソッド以外の任意のメソッドに業務処理ディスパッチさせることができる。 - -**メソッドレベルバインディング** は、ハンドラインターフェースを実装して **いない** オブジェクトを -ハンドラキューに追加(もしくはディスパッチ)することで有効化される。 - -フレームワークは、ハンドラキュー上のハンドラがハンドラインターフェースを実装していない場合に、 -実行コンテキスト上に設定された **MethodBinding** と呼ばれるモジュールを用いて `handle()` メソッドにかわる -メソッドを決定し、これを実行する。 - -フレームワーク標準の **MethodBinder** として、以下の実装が提供される。 - -| クラス名 | 概要 | 参照 | -|---|---|---| -| nablarch.fw.web.HttpMethodBinding | HTTPリクエストメソッド名(GET/POST/DELETE/PUT等) およびリソース名に応じてメソッドよび分ける。 | [画面オンライン処理用業務アクションハンドラ](../../component/handlers/handlers-HttpMethodBinding.md) | -| nablarch.fw.handler.RecordTypeBinding | 入力ファイルや、電文データ上のレコード種別 (ヘッダ、データ、トレーラ等) に応じて メソッドを呼び分ける。 | [ファイル入力のバッチ業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-FileBatchAction.md) | - -なお、実行コンテキスト上に **MethodBinding** が設定されてない状態でハンドラインターフェースを実装していない -オブジェクトをハンドラキュー上に追加した場合は実行時エラーが送出される。 - -#### リクエストインターフェース - -リクエストインターフェースとは、リクエストに対してリクエストパスを定義する際に実装するインターフェースである。 -リクエストパスおよびリクエスト内に保持している各種パラメータに対するアクセサが定義されている。 -リクエストがこのインターフェースを実装することにより、リクエスト毎に実行する業務処理を切り替えることが可能となる。 - -```java -/** - * 処理要求を表すインターフェース。 - * - * @param リクエストパラメータの型 - * @author Iwauo Tajima - * @since 1.0 - */ -public interface Request { - /** - * リクエストの種別を識別する文字列。 - * @return リクエストパス - */ - String getRequestPath(); - - /** - * リクエストパスを設定する。 - * @param requestPath リクエストパス - * @return このオブジェクト自体 - */ - Request setRequestPath(String requestPath); - - /** - * リクエストパラメータを取得する。 - * @param name パラメータ名 - * @see #getParamMap() - */ - TParam getParam(String name); - - /** - * リクエストパラメータのMapを返す。 - * @return リクエストパラメータのMap - */ - Map getParamMap(); -} -``` - -### 処理結果の識別 - -**処理結果オブジェクト** - -処理結果オブジェクトとは、ハンドラの処理結果を表すオブジェクトであり、次のインターフェースで定義される。 - -```java -/** - * ハンドラでの処理結果を表すインターフェース。 - * - * @author Iwauo Tajima - * @since 1.0 - */ -public interface Result { - /** - * ステータスコードを返す。 - * @return ステータスコード - */ - int getStatusCode(); - - /** - * 処理結果に関する詳細情報を返す。 - * @return 詳細情報 - */ - String getMessage(); - - /** - * 処理が正常終了したかどうかを返す。 - * @return 正常終了した場合はtrue - */ - @Published - boolean isSuccess(); -} -``` - -**ハンドラの処理結果** - -ハンドラでの処理が終了した場合、その処理結果を上位のハンドラに返す方法は以下の4つのいずれかとなる。 - -1. **後続のハンドラの結果をそのままリターンする。** - -多くのハンドラでは、後続のハンドラに処理を委譲し、その結果をそのままリターンする。 - -1. **処理結果オブジェクトを作成してリターンする。** - -[リクエスト](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) に対する処理が正常終了し、処理結果が確定した場合、 -その内容を表す以下のオブジェクトを作成してリターンする。 -実行中のトランザクションは、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) によりコミットされる。 - -| 実行制御基盤 | 正常終了時に返却する型 | 内容 | -|---|---|---| -| [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) | [HttpResponse](../../javadoc/nablarch/fw/web/HttpResponse.html) | 遷移先画面のパス等の内容を設定したオブジェクトをリターンする。 | -| [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) | [ResponseMessage](../../javadoc/nablarch/fw/messaging/ResponseMessage.html) | 応答電文のフォーマットや内容を設定したオブジェクト をリターンする。 | -| [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) [応答不要メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-receive.md) | [Result.Success](../../javadoc/nablarch/fw/Result.Success.html) | 正常終了を表すマーカオブジェクトをリターンする。 (これらの処理ではレスポンス処理が無いので、内容の設定は不要) | - -1. **処理結果オブジェクトを実行時例外として送出する。** - -[リクエスト](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) に対する処理が異常終了することが確定した場合、下記の例外を作成して送出する。 -実行中のトランザクションは、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) によりロールバックされる。 - -| 実行制御基盤 | 異常終了時に送出する型 | 内容 | -|---|---|---| -| [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) | [HttpErrorResponse](../../javadoc/nablarch/fw/web/HttpErrorResponse.html) | エラー時遷移先画面のパス等の内容を設定したオブジェクトを 送出する。 | -| [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) | [ErrorResponseMessage](../../javadoc/nablarch/fw/messaging/ErrorResponseMessage.html) | エラー応答電文のフォーマットや内容を設定したオブジェクトを 送出する。 | -| [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) [応答不要メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-receive.md) | [Result.Error](../../javadoc/nablarch/fw/Result.Error.html) のサブクラス | 異常終了を表すマーカオブジェクトを送出する。 (これらの処理ではレスポンス処理が無いので、内容の設定は不要) | - -1. **処理結果オブジェクトではない実行時例外を送出する。** - -その他、一般の実行時例外が送出された場合は、トランザクションがロールバックされ、 -[画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) 、 [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) ではレスポンス処理が行われる。 -この場合はレスポンス内容を指定することができないため、既定のレスポンス処理が行われる。 - -**レスポンス処理** - -上で述べたように、 [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) や [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) では、クライアントに対する応答の内容を -指定するオブジェクトを処理結果として返却もしくは送出する。 - -これらのオブジェクトは、ハンドラキュー上の特定のハンドラによって処理され、クライアントに対するレスポンスとして送信される。 (下図) - -![response_handler.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/response_handler.png) - -詳細は以下を参照すること。 - -* [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) -* [電文応答制御ハンドラ](../../component/handlers/handlers-MessageReplyHandler.md) - ------ - -### 変数スコープ - -**変数スコープ** とは、ハンドラキュー上のハンドラ間でデータを共有する際に使用する領域のことである。 -変数スコープには共有範囲や存続期間が異なる以下の4つのスコープが存在し、それぞれ使用目的が異なる。 - -**リクエストスコープ** - -各リクエストの開始から終了までの間、スレッド毎に固有の変数を保持する変数スコープである。 -リクエストスコープは実行コンテキスト上に保持されており、 -Mapインターフェースでアクセスすることができる。 - -**セッションスコープ** - -セッションスコープは複数のリクエストを跨って存続し、各リクエストスレッド間で共有される変数を保持する変数スコープである -(共有範囲、存続期間は各処理形態ごとに異なる)。 -リクエストスコープと同様、実行コンテキストからMapインターフェースでアクセスすることができる。 - -なお、セッションスコープの内容をリクエストスレッドから変更する場合は、 -[セッション並行アクセスハンドラ](../../component/handlers/handlers-SessionConcurrentAccessHandler.md) を使用するなど、何らかの同期化を行なう必要がある。 - -**スレッドローカル** - -リクエストスコープやセッションスコープは、ハンドラ間の引数である実行コンテキストを経由して引き渡されるため、 -DB接続のように、どこで使用するか予期できないデータの受け渡しをしようとすると、 -ハンドラとは直接関係の無いクラスのメソッドにまで実行コンテキストを引数として渡さなければならず、あまり現実的では無い。 - -そのため、 [データベース接続管理ハンドラ](../../component/handlers/handlers-DbConnectionManagementHandler.md) など一部のハンドラでは、 -変数スコープではなく、スレッドローカル変数(java.lang.ThreadLocal)を経由してデータやオブジェクトの引き回しを行なっている。 - -**スレッドコンテキスト** - -スレッドコンテキストは、スレッドローカル変数上に保持された変数スコープ(Map)である。 -ユーザIDや、リクエストIDのように、ログ出力やDB共通項目への設定などの用途において、実行コンテキストを経由した -引き回しが難しいパラメータ類を格納する。 - -その内容の多くは、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) によって設定されるが、 -それ以外ハンドラでも、スレッドコンテキストに変数を設定するものが存在するほか、 -業務アクションハンドラから任意の変数を設定することも可能である。 - -以下の図は、これらのスコープの特性をあらわしたものである。 - -![handler_scope.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/handler_scope.png) - -また、画面オンライン実行制御基盤では、上記のスコープに加えて **ウィンドウスコープ** と呼ばれる変数スコープを使用する。 - -#### ウィンドウスコープ - -ウィンドウスコープとは、セッションスコープと同様、複数のリクエストを跨るデータを格納する変数スコープである。 -セッションスコープがアプリケーションサーバ上でデータを格納するのに対して、 -ウィンドウスコープは、複数画面間をhiddenタグで持ちまわることにより実現される。 -ウィンドウスコープを使用することで、ブラウザで複数のウィンドウを立ち上げても -並列に動作させることができる。また、ブラウザのヒストリバックによる遷移が可能となる。 - -下図は、複数の入力画面で構成されるアンケートアプリケーションにおける動作イメージである。 -ユーザからの入力項目をhiddenタグで持ちまわることで、 -セッションスコープを使用せずに複数画面にまたがった情報の保持を可能としている。 - -![window_scope_sequence.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/window_scope_sequence.png) - -上記のように、hiddenで引き継がれる情報は特定のウィンドウ内のHTMLに記載されている。 -このようにして、他のウィンドウやタブに影響を与えずに、複数のリクエストをまたがったデータ共有を実現している。 - -> **Note:** -> ウィンドウスコープに格納された変数は、カスタムタグを使用することで自動的にhiddenタグに変換されるので、 -> **アプリケーションプログラマがJSPにhiddenタグを書く必要はない。** - -画面オンライン制御基盤の画面間のデータ連携では、基本的にセッションスコープではなくこのウィンドウスコープを使用することになる。 -詳細については、以下の文書を参照すること。 - -* 画面オンライン制御基盤における各種スコープの使い分けについて - - [画面オンライン用業務アクションハンドラ:変数スコープの利用](../handler/HttpMethodBinding.html#web-scope) -* カスタムタグを使用したウィンドウスコープの使用方法について - - [カスタムタグ実装例集](../../../../guide/development_guide/04_Explanation/CustomTag/basic.html#howto-window-scope) - -### ハンドライベントコールバック - -一部のハンドラでは、特定のインタフェースを実装した後続ハンドラに対してコールバックを行う。 - -コールバックを行うハンドラの代表例は [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) である。 -このハンドラでは、以下のインタフェースを実装しているハンドラに対して、 -コミットもしくはロールバックのタイミングでコールバックを行う。 - -```java -/** - * トランザクション(コミット or ロールバック)毎に呼び出される - * コールバックメソッドを定義するインタフェース。 - * - * @param ハンドラへの入力データ - * @author hisaaki sioiri - * @since 1.1 - */ -public interface TransactionEventCallback { - - /** - * 入力データに対する処理が正常に処理された場合に呼ばれる。 - */ - void transactionNormalEnd(TData data, ExecutionContext ctx); - - /** - * 入力データに対する処理で異常が発生した場合に呼ばれる。 - */ - void transactionAbnormalEnd(Throwable e, TData data, ExecutionContext ctx); -} -``` - -例えば、業務アクションハンドラがこのインターフェースを実装することによって、 -業務トランザクションがロールバックされた場合の例外制御を行なうことができる。 -次の図は、この動作を表した模式図である。 - -![handler_callback.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/handler_callback.png) - -このようなコールバック制御を行うハンドラには以下のものがある。 - -* [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) -* [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) -* [トランザクションループ制御ハンドラ](../../component/handlers/handlers-LoopHandler.md) - ------ - -### データリーダ - -データリーダとは、外部のリソース (ファイル、DB、メッセージキューなど) から、 -1業務トランザクションの実行に必要な情報を読み込むコンポーネントである。 -データリーダで読み込まれたデータは、後続のハンドラの入力として渡され、 -最終的に業務アクションハンドラによって処理される。 - -> **Note:** -> [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) では、HTTPリクエスト内に1業務トランザクションの実行に必要な情報が含まれているので、 -> 別途データリーダを使用する必要はない。 - -データリーダのインターフェースは以下で定義される。 - -```java -/** - * ハンドラが処理する入力データを外部から読み込むインタフェース。 - * - * データリーダは複数のリクエストスレッドから並行アクセスされ得るので、 - * 各メソッドはスレッドセーフに実装されなければならない。 - * - * @param このクラスが読み込んだデータの型 - * - * @author Iwauo Tajima - * @since 1.1 - */ -public interface DataReader { - /** - * ハンドラが処理する入力データを読み込んで返却する。 - * - * 入力データがこれ以上存在しない状態、すなわち、hasNext()の結果がfalseとなる - * 状態でこのメソッドを呼んだ場合の結果は不定である。 - * - * @param ctx 実行コンテキスト - * @return 入力データオブジェクト - */ - TData read(ExecutionContext ctx); - - /** - * 次に読み込むデータが存在するかどうかを返却する。 - * - * @param ctx 実行コンテキスト - * @return 次に読み込むデータがまだ残っている場合はtrue - */ - boolean hasNext(ExecutionContext ctx); - - /** - * このリーダの使用を停止し、内部的に保持している各種リソースを開放する。 - * - * @param ctx 実行コンテキスト - */ - void close(ExecutionContext ctx); -} -``` - -**データリーダの作成** - -データリーダを作成する責務とタイミングは実行制御基盤ごとに以下のように異なる。 -いずれの場合でも、作成されたデータリーダは実行コンテキストに設定され、後続のハンドラによって使用される。 - -| 実行制御基盤 | 作成するコンポーネント | 作成するタイミング | -|---|---|---| -| [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) | (データリーダを使用しない。) | N/A | -| [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) | 業務アクションハンドラ | [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) の初期処理内。 (業務アクションハンドラが実装する [DataReaderFactory](../../javadoc/nablarch/fw/DataReaderFactory.html) をコールバックする。) | -| [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) | [リポジトリ](../02_FunctionDemandSpecifications/01_Core/02_Repository.html) | [リポジトリ](../02_FunctionDemandSpecifications/01_Core/02_Repository.html) での初期化処理内で作成する。 (オブジェクトキー名: **dataReader**) | - -**データリードハンドラ** - -データリーダを使用して読込み処理を行うのは、 [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) である。 -このハンドラは、実行コンテキスト上のデータリーダから1件分の業務処理データを読み込み、 -それを引数として後続ハンドラに処理を委譲する。 - -次の図は、データリードハンドラの挙動を表したものである。 - -![handler_datareader.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/handler_datareader.png) - ------ - -### 業務アクションハンドラの実装 - -業務アクションハンドラは、業務処理を実装するハンドラであり、業務アプリケーションの開発担当者が実装する。 -このハンドラで行う業務処理のおおまかな流れは下図のようになる。 - -![action_handler.png](../../../knowledge/assets/about-nablarch-architectural-pattern-concept/action_handler.png) - -図中の番号は処理の順番を示している。以下は上図の説明である。 - -1. **入力データの取得** - -入力データの内容は、基本的にMap形式で取得できるようになっている。(図中①) - -(以降で使用する入力精査やDBアクセスといったライブラリも、基本的にMapを引数や戻り値として使用する。) - -1. **入力精査** - -前段で取得した入力データのMapに対して精査処理を行う。(図中②) -精査ロジックはフォーム定義に沿って行なう。 - -**フォーム定義に沿った入力精査** - -フォームとは「システムへの入力項目」の精査と値の保持を行うクラスであり、画面項目定義や -電文フォーマット定義などに沿って作成される。 -フォームクラスの各項目には宣言的に精査仕様を設定できるようになっており、 -精査ロジックを簡便に実装できる。 - -なお、DB内容との比較などの処理を含む精査については、ビジネスロジックの一部として実装する。 - -> **Note:** -> フォームのうち、下記の特徴を持つクラスを特にエンティティと呼称する。 -> エンティティはテーブル定義に沿って作成される。 - -> * > フォームクラスがRDBMS上のテーブルと1対1にひもづく。 -> * > フォームクラスのプロパティとテーブルのカラムが1対1にひもづく。 - -1. **ビジネスロジックの実行** - -精査が完了した入力データはフォームもしくはエンティティオブジェクトとして取得できる。 -この内容をもとに、ビジネスロジックを実行する。 -また、フレームワークが提供するライブラリを使用することで、 -DB、データファイル、メッセージキューを通じた入出力を行うことができる。 (図中③) -これらのライブラリについても、Mapインターフェースを通じて使用できるようになっている。 - -**共通コンポーネントの使用** - -複数の業務アクションから共用しうるロジックについては、業務アクションハンドラに直接実装するのではなく -個別のクラス(共通コンポーネント)として実装することを推奨する。(図中④) -また、既存の共通コンポーネントが適用可能であれば、積極的に使用すること。 - -1. **処理結果の返却** - -ビジネスロジックの処理結果を表すオブジェクトを返却する。(図中⑤) -業務処理が正常終了した場合は、処理結果の内容を表すオブジェクトを生成して返す。 -業務処理を異常終了させる場合には、実行時例外を送出する。 -実行時例外を送出することで、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) により -業務トランザクションがロールバックされる。 diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-basic-policy.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-basic-policy.md deleted file mode 100644 index 52e4af800..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-basic-policy.md +++ /dev/null @@ -1,15 +0,0 @@ -# 共通方針 - -本稿では、NAF全体に共通した以下の実装方針について述べる。 - -* [動作を保証するプラットフォーム](../../about/about-nablarch/about-nablarch-platform.md) -* [国際化対応](../../about/about-nablarch/about-nablarch-02-I18N.md) -* [RDBMS の使用ポリシー](../../about/about-nablarch/about-nablarch-04-RDBMS-Policy.md) -* [業務コンポーネントの責務配置](../../about/about-nablarch/about-nablarch-determining-stereotypes.md) -* [文字列からBigDecimal変換時に発生する可能性のあるヒープ不足について](../../about/about-nablarch/about-nablarch-bigdecimal.md) - -platform -01_SystemConstitution/02_I18N -01_SystemConstitution/04_RDBMS_Policy -determining_stereotypes -basic_policy/bigdecimal diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-bigdecimal.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-bigdecimal.md deleted file mode 100644 index bcc68418c..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-bigdecimal.md +++ /dev/null @@ -1,20 +0,0 @@ -# 文字列からBigDecimal変換時に発生する可能性のあるヒープ不足について - -文字列からBigDecimalに変換する際に指数表現(例えば、 `9e100000` のような値)を指定した場合に、以下の問題が発生する場合がある。 - -* BigDecimal#toPlainString()の呼び出しで、非常に大きい文字列が生成されヒープが圧迫される -* java.text.DecimalFormatを使用してフォーマットする際に非常に大きい文字列が生成されヒープが圧迫される - -このため、Nablarchでは文字列からBigDecimalに変換する際に、 BigDecimal#scale -を使用して桁数チェックを行い、ヒープを圧迫するような大きな値を取り込むことを防止している。 -この機能では、許容するscaleの範囲を `-9999` から `9999` の範囲とし、この範囲を超える指数表現の値を変換しようとした場合、例外を送出しヒープが圧迫されないようにしている。 - -なお、許容するscaleの範囲は設定で変更可能となっている。 -設定はシステムリポジトリ機能の環境設定ファイルに指定する。 -設定方法は、 [環境設定ファイルからの読み込み](../../component/libraries/libraries-02-01-Repository-config.md#環境設定ファイルからの読み込み) を参照。 - -例えば、許容する範囲を `-10` から `10` としたい場合には、下のように設定を追加する。 - -```properties -nablarch.max_scale=10 -``` diff --git a/.claude/skills/nabledge-1.4/docs/about/about-nablarch/about-nablarch-about-nablarch-concept.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-concept.md similarity index 96% rename from .claude/skills/nabledge-1.4/docs/about/about-nablarch/about-nablarch-about-nablarch-concept.md rename to .claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-concept.md index d5199b717..2d6ebaadc 100644 --- a/.claude/skills/nabledge-1.4/docs/about/about-nablarch/about-nablarch-about-nablarch-concept.md +++ b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-concept.md @@ -1,4 +1,4 @@ -![Nablarch.jpg](../../../knowledge/assets/about-nablarch-about-nablarch-concept/Nablarch.jpg) +![Nablarch.jpg](../../../knowledge/assets/about-nablarch-concept/Nablarch.jpg) ## Nablarchのコンセプト diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-determining-stereotypes.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-determining-stereotypes.md deleted file mode 100644 index 4a759ac3f..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-determining-stereotypes.md +++ /dev/null @@ -1,31 +0,0 @@ -# 業務コンポーネントの責務配置 - -[業務アクションハンドラの実装](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#業務アクションハンドラの実装) で述べるように、本フレームワークにおける業務機能は、 -業務アクションハンドラ、フォーム/エンティティ、業務共通コンポーネントと呼ばれるクラスにそれぞれ実装される。 -しかしながら、業務処理の複雑な責務をこれらのクラスに対してどのように配置するかについては様々な考え方があり、特定の方法に絞ることはできない。 -以下では、典型的なプロジェクトで採用することができる責務配置の1例を示す。 - -なお、本書に記載される業務アプリケーションの実装例は、ここで述べる責務配置を前提として記述されている。 - -| 名称 (クラス接尾辞) | 責務 | -|---|---| -| 業務アクションハンドラ (Action) | フレームワークから直接コールバックされ、業務処理のエントリーポイントとなるモジュール。 Actionは、ユーザ一覧照会、ユーザ情報登録といった取引ごとに1つずつ作成する。 業務処理が比較的単純なものであれば、このクラスに直接実装してもよい。 複雑な業務処理や、複数の業務および処理形態(バッチと画面オンラインなど)から共用される 業務処理については、別途、業務共通コンポーネントを作成し、そこに実装する。 > **Note:** > 業務アクションハンドラは、HTTPリクエストオブジェクトや実行コンテキストなどの、 > フレームワークが作成するオブジェクトに依存するため、自動テストは後述するリクエスト単体テストによって行う必要がある。 > このため、複雑な内部条件をもつ業務ロジックを実装した場合、 > テストデータのセットアップ作業が煩雑となり、作業効率が低下する。 > このような場合は、業務処理部分を業務共通コンポーネントとして切り出した上で、 > クラス単体テストを行うこと。 | -| 業務共通コンポーネント (Component) | 業務ロジックを実装するクラス。 このクラスでは、HTTPリクエストオブジェクトや実行コンテキストなどの実行制御基盤に属するオブジェクトに 直接依存することは避けること。 | -| 業務フォーム (Form) | アプリケーションで使用するデータの保持と、外部入力値の精査を実行するモジュール。 業務処理のうち、単項目入力精査および、項目間入力精査を実装する。 ただし、データベース等へのアクセスが必要となる精査処理については、業務アクションハンドラにて実装する。 | -| 業務画面 (View) | 画面オンライン処理において、ユーザが使用するインタフェースを提供する。(通常はJSPを使用する。) 業務処理は実装せず、業務アクションハンドラから渡される処理結果を表示する。 | - -各構成要素間の処理の流れは以下のようになる。(図は画面オンライン処理での例) - -![fw_app_flow.png](../../../knowledge/assets/about-nablarch-determining-stereotypes/fw_app_flow.png) - -View(を表示している、Webクライアント)からリクエストが送られる。 - -アプリケーションフレームワークが、リクエストを受信し、Actionを呼び出す。 - -Actionはバリデーションを実行し、画面入力値が格納されたオブジェクト(Form)を生成して、Componentを呼び出す。 - -Componentはビジネスロジックを実行し、結果をActionに返す。 - -Actionは必要に応じて、Componentの戻り値を処理(リクエストスコープへの値の格納など)し、アプリケーションフレームワークに処理を返す。 - -アプリケーションフレームワークはViewを処理(JSPをHTMLに変換など)し、クライアントにレスポンスを返す。 diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-fw.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-fw.md deleted file mode 100644 index fb5f1c7ee..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-fw.md +++ /dev/null @@ -1,79 +0,0 @@ -# ∇Nablarch Application Framework 解説書 - -introduction -overview_of_NAF -basic_policy -architectural_pattern/concept -architectural_pattern/web_gui -architectural_pattern/batch -architectural_pattern/messaging -02_FunctionDemandSpecifications/01_Core/01_Log.rst -02_FunctionDemandSpecifications/01_Core/02_Repository.rst -core_library/thread_context -02_FunctionDemandSpecifications/01_Core/04_DbAccessSpec.rst -core_library/record_format -core_library/file_access -core_library/enterprise_messaging -core_library/mail -02_FunctionDemandSpecifications/01_Core/03_TransactionManager.rst -02_FunctionDemandSpecifications/01_Core/05_StaticDataCache.rst -core_library/validation -02_FunctionDemandSpecifications/01_Core/07_Message.rst -02_FunctionDemandSpecifications/03_Common/06_IdGenerator.rst -02_FunctionDemandSpecifications/03_Common/08_ExclusiveControl.rst -02_FunctionDemandSpecifications/03_Common/02_CodeManager.rst -02_FunctionDemandSpecifications/01_Core/06_SystemTimeProvider.rst -02_FunctionDemandSpecifications/03_Common/04_Permission.rst -02_FunctionDemandSpecifications/03_Common/05_ServiceAvailability.rst -02_FunctionDemandSpecifications/03_Common/07_WebView -common_library/file_upload_utility -02_FunctionDemandSpecifications/03_Common/99_Utility -handler/index.rst -reader/index.rst -api/link.rst - -## 目次 - -1. [序 : Nablarch Application Framework (NAF)とは ?](../../about/about-nablarch/about-nablarch-introduction.md) -2. [NAF概要](../../about/about-nablarch/about-nablarch-overview-of-NAF.md) -3. [共通方針](../../about/about-nablarch/about-nablarch-basic-policy.md) - -**I: NAF実行制御基盤** - -1. [NAF基本アーキテクチャ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md) -2. [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) -3. [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) -4. [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) - -**II: NAF基盤ライブラリ** - -1. [ログ出力](../../component/libraries/libraries-01-Log.md) -2. [リポジトリ](../../component/libraries/libraries-02-Repository.md) -3. [同一スレッド内でのデータ共有(スレッドコンテキスト)](../../component/libraries/libraries-thread-context.md) -4. [データベースアクセス(検索、更新、登録、削除)機能](../../component/libraries/libraries-04-DbAccessSpec.md) -5. [汎用データフォーマット機能](../../component/libraries/libraries-record-format.md) -6. [ファイルアクセス機能](../../component/libraries/libraries-file-access.md) -7. [システム間メッセージング機能](../../component/libraries/libraries-enterprise-messaging.md) -8. [メール送信](../../component/libraries/libraries-mail.md) -9. [トランザクション管理](../../component/libraries/libraries-03-TransactionManager.md) -10. [静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md) -11. [入力値のバリデーション](../../component/libraries/libraries-core-library-validation.md) -12. [メッセージ管理](../../component/libraries/libraries-07-Message.md) - -**III: NAF共通コンポーネント** - -1. [採番機能](../../component/libraries/libraries-06-IdGenerator.md) -2. [排他制御機能](../../component/libraries/libraries-08-ExclusiveControl.md) -3. [コード管理](../../component/libraries/libraries-02-CodeManager.md) -4. [日付の管理機能](../../component/libraries/libraries-06-SystemTimeProvider.md) -5. [認可](../../component/libraries/libraries-04-Permission.md) -6. [開閉局](../../component/libraries/libraries-05-ServiceAvailability.md) -7. [JSPカスタムタグライブラリ](../../component/libraries/libraries-07-WebView.md) -8. [ファイルアップロード業務処理用ユーティリティ](../../component/libraries/libraries-file-upload-utility.md) -9. [ユーティリティ](../../component/libraries/libraries-99-Utility.md) - -**IV: リファレンス** - -1. [ハンドラリファレンス](../../component/handlers/handlers-handler.md) -2. [データリーダリファレンス](../../component/readers/readers-reader.md) -3. [APIドキュメント(Javadoc)](../javadoc/index.html) diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-glossary.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-glossary.md index af6c2dc9e..7f7decd6e 100644 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-glossary.md +++ b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-glossary.md @@ -8,11 +8,11 @@ | 用語 | 意味 | |---|---| -| Action（業務アクションハンドラ ） | 業務コンポーネントのステレオタイプの一つ。フレームワークから直接コールバックされ、業務処理のエントリーポイントとなるクラス。詳細については、 [業務コンポーネントの責務配置](../../about/about-nablarch/about-nablarch-determining-stereotypes.md#業務コンポーネントの責務配置) を参照。 | -| Component（業務共通コンポーネント） | 業務コンポーネントのステレオタイプの一つ。業務ロジックを実装するクラス。詳細については、 [業務コンポーネントの責務配置](../../about/about-nablarch/about-nablarch-determining-stereotypes.md#業務コンポーネントの責務配置) を参照。 | +| Action（業務アクションハンドラ ） | 業務コンポーネントのステレオタイプの一つ。フレームワークから直接コールバックされ、業務処理のエントリーポイントとなるクラス。詳細については、 fw-bussiness-component-label を参照。 | +| Component（業務共通コンポーネント） | 業務コンポーネントのステレオタイプの一つ。業務ロジックを実装するクラス。詳細については、 fw-bussiness-component-label を参照。 | | DIコンテナ | コンポーネント（オブジェクト）のインスタンス、およびコンポーネント間の依存関係を管理するコンテナ。 | | Entity（エンティティ） | データベースから取得したデータ、およびデータベースを更新するためのデータを保持するクラス。 | -| Form（業務フォーム） | アプリケーションで使用するデータの保持と、外部入力値の精査を実行するクラス。詳細については、 [業務コンポーネントの責務配置](../../about/about-nablarch/about-nablarch-determining-stereotypes.md#業務コンポーネントの責務配置) を参照。 | +| Form（業務フォーム） | アプリケーションで使用するデータの保持と、外部入力値の精査を実行するクラス。詳細については、 fw-bussiness-component-label を参照。 | ### H～N @@ -26,8 +26,8 @@ | 用語 | 意味 | |---|---| -| View（業務画面） | 業務コンポーネントのステレオタイプの一つ。画面オンライン処理において、ユーザが使用するインタフェースを提供する。詳細については、 [業務コンポーネントの責務配置](../../about/about-nablarch/about-nablarch-determining-stereotypes.md#業務コンポーネントの責務配置) を参照。 | -| Webフロントコントローラ | 画面オンライン実行制御基盤において、リクエスト処理を担うコントローラ。詳細については、 [Webフロントコントローラ (サーブレットフィルタ)](../../component/handlers/handlers-WebFrontController.md#webフロントコントローラ-サーブレットフィルタ) を参照。 | +| View（業務画面） | 業務コンポーネントのステレオタイプの一つ。画面オンライン処理において、ユーザが使用するインタフェースを提供する。詳細については、 fw-bussiness-component-label を参照。 | +| Webフロントコントローラ | 画面オンライン実行制御基盤において、リクエスト処理を担うコントローラ。詳細については、 WebFrontController を参照。 | ## 五十音順 @@ -37,30 +37,30 @@ |---|---| | アプリケーションプログラマ | 設計書の内容に従い、業務アプリケーションのプログラミングおよびテストを担当する人。 | | アーキテクト | Nablarchのフレームワークや開発標準に精通し、プロジェクトへの導入を担当する人。フレームワークのカスタマイズ、方式設計、開発標準のテーラリング、プロジェクトメンバの教育などを行う。 | -| ウィンドウスコープ | ウィンドウやタブごとに個別の変数を保持するためのスコープ。詳細については、 [変数スコープ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#変数スコープ) を参照。 | +| ウィンドウスコープ | ウィンドウやタブごとに個別の変数を保持するためのスコープ。詳細については、 scope を参照。 | ### か行 | 用語 | 意味 | |---|---| -| 開閉局 | 任意の単位（リクエスト、機能など）のサービス提供可否のチェックと、切り替えを行う機能。詳細については、 [開閉局](../../component/libraries/libraries-05-ServiceAvailability.md#開閉局) を参照。 | -| 画面オンライン実行制御基盤 | HTMLをベースとしたUIを伴う標準的なWebアプリケーションを実装する場合に使用する実行制御基盤。Java EEアプリケーションサーバ上で動作することを前提とする。詳細については、 [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md#画面オンライン実行制御基盤) を参照。 | -| 環境設定ファイル | 環境によって変化する設定値をプロパティファイルに似た形式で記述するファイル。詳細については、 [環境設定ファイルからの読み込み](../../component/libraries/libraries-02-01-Repository-config.md#環境設定ファイルからの読み込み) を参照。 | +| 開閉局 | 任意の単位（リクエスト、機能など）のサービス提供可否のチェックと、切り替えを行う機能。詳細については、 serviceAvailable を参照。 | +| 画面オンライン実行制御基盤 | HTMLをベースとしたUIを伴う標準的なWebアプリケーションを実装する場合に使用する実行制御基盤。Java EEアプリケーションサーバ上で動作することを前提とする。詳細については、 web_gui を参照。 | +| 環境設定ファイル | 環境によって変化する設定値をプロパティファイルに似た形式で記述するファイル。詳細については、 repository_config_load を参照。 | | 業務コンポーネント | Nablarch Application Frameworkをベースに開発者が作成する業務アプリケーション。４つのステレオタイプ（Action/Component/Entity/View）より構成される。 | | クラス単体テスト | 業務アプリケーションの個々のプログラム（Entityクラス/Componentクラス）が正しく動作するかを確認するテスト。詳細については、 [クラス単体テスト概要](../../development-tools/testing-framework/testing-framework-01-UnitTestOutline.md#クラス単体テスト概要) を参照。 | -| コード管理 | アプリケーションで使用するコードに関する操作を容易にするための機能。この機能が扱うコードとは、性別区分(1:男性、2:女性)や年代区分(01:10歳未満、02:10代、03:20代、04:30代、05:40代以上)のようなコードの値(コード値)とその意味を表わす文字列(コード名称)のことを表す。詳細については、 [コード管理](../../component/libraries/libraries-02-CodeManager.md#コード管理) を参照。 | +| コード管理 | アプリケーションで使用するコードに関する操作を容易にするための機能。この機能が扱うコードとは、性別区分(1:男性、2:女性)や年代区分(01:10歳未満、02:10代、03:20代、04:30代、05:40代以上)のようなコードの値(コード値)とその意味を表わす文字列(コード名称)のことを表す。詳細については、 code_manager を参照。 | | コンポーネント | DIコンテナで管理されるオブジェクト。通常、オブジェクト一つ一つのことをコンポーネントと称するが、共通コンポーネント、業務コンポーネントのように、概念や機能のまとまりをコンポーネントと称する場合もある。 | -| コンポーネント設定ファイル | DIコンテナで管理されるコンポーネントの設定を記述するファイル。XML形式でクラス名やプロパティの設定値、クラス間の依存関係を記述する。詳細については、 [設定ファイルの種類とフレームワークが行うリポジトリの初期化](../../component/libraries/libraries-02-01-Repository-config.md#設定ファイルの種類とフレームワークが行うリポジトリの初期化) を参照。 | +| コンポーネント設定ファイル | DIコンテナで管理されるコンポーネントの設定を記述するファイル。XML形式でクラス名やプロパティの設定値、クラス間の依存関係を記述する。詳細については、 repository_config を参照。 | ### さ行 | 用語 | 意味 | |---|---| -| 実行コンテキスト | 各リクエストを処理する際に必要な情報を保持するオブジェクト。リクエストスコープ/セッションスコープへの参照や、ハンドラキューを管理している。詳細については、 [NAF基本アーキテクチャ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#naf基本アーキテクチャ) を参照。 | +| 実行コンテキスト | 各リクエストを処理する際に必要な情報を保持するオブジェクト。リクエストスコープ/セッションスコープへの参照や、ハンドラキューを管理している。詳細については、 basic_architecture を参照。 | | 自動テストフレームワーク | クラス単体テスト、リクエスト単体テストについて、テスト実行を自動化する機能を提供するフレームワーク。詳細については、 [自動テストフレームワーク](../../development-tools/testing-framework/testing-framework-01-Abstract.md#自動テストフレームワーク) を参照。 | | ステレオタイプ | 典型的な型（インタフェース）。本書内では、アーキテクチャの代表的な構成要素を表す意味として使用している。 | -| スレッドコンテキスト | 一連の処理を実行するときに、スレッド毎に共通的に使用するデータ（ユーザID、リクエストIDなど）を保持するクラス。詳細については、 [同一スレッド内でのデータ共有(スレッドコンテキスト)](../../component/libraries/libraries-thread-context.md#同一スレッド内でのデータ共有スレッドコンテキスト) を参照。 | -| 静的データ | コードやメッセージといったRDBMSやXMLファイル等の媒体に保存される、基本的に変更の入らないデータ。詳細については、 [静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md#静的データのキャッシュ) を参照。 | +| スレッドコンテキスト | 一連の処理を実行するときに、スレッド毎に共通的に使用するデータ（ユーザID、リクエストIDなど）を保持するクラス。詳細については、 thread-context-label を参照。 | +| 静的データ | コードやメッセージといったRDBMSやXMLファイル等の媒体に保存される、基本的に変更の入らないデータ。詳細については、 static_data_cache を参照。 | ### た行 @@ -80,7 +80,7 @@ | 用語 | 意味 | |---|---| | バッチ実行制御基盤 | DBやファイルなどに格納されたデータを入力とするバッチアプリケーションを実装する際に使用する実行制御基盤。 | -| ハンドラ | 入力データに対して処理を行う全てのモジュールが実装するインターフェースおよびそれを実装したクラス。ハンドラには、リクエストハンドラ（リクエストプロセッサ）、エラーハンドラ、認証・認可ハンドラ、開閉局ハンドラなどの種類がある。詳細については、 [NAF基本アーキテクチャ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#naf基本アーキテクチャ) を参照。 | +| ハンドラ | 入力データに対して処理を行う全てのモジュールが実装するインターフェースおよびそれを実装したクラス。ハンドラには、リクエストハンドラ（リクエストプロセッサ）、エラーハンドラ、認証・認可ハンドラ、開閉局ハンドラなどの種類がある。詳細については、 basic_architecture を参照。 | | ハンドラキュー | 入力データを処理するハンドラを実行順に保持するキュー。 | | ビジネスロジック | アプリケーションの構成要素のうち、業務に特化したロジックの実装。本書内では、例えば利率計算といったロジックだけでなく、画面入力値の精査等、業務コンポーネントに実装するロジックを全てビジネスロジックと称する。 | @@ -99,7 +99,7 @@ | リクエスト | 業務処理依頼のイベント及びその依頼内容を表す入力データ。画面オンライン処理方式では基本的に 入力データ=リクエストであるが、バッチ処理方式などでは、1リクエストに対して複数の入力データ(複数件のレコード)を処理することになる。 | | リクエストID | 処理依頼（イベント）の種類につけるID。Webアプリケーションの場合はボタンやリンクの押下の種類、バッチアプリケーションの場合はバッチ処理の種類を表す。 | | リクエスト単体テスト | 一つの処理リクエストを受け取って正しく動作するかを確認するテスト。画面オンライン処理方式では、HTTPリクエスト送信から、ビジネスロジックの実行、画面表示までの一連の処理を確認することをリクエスト単体テストと定義する。詳細については、 [リクエスト単体テスト概要](../../development-tools/testing-framework/testing-framework-01-UnitTestOutline.md#リクエスト単体テスト概要) を参照。 | -| リポジトリ | Nablarch Application Frameworkが提供するDIコンテナ。コンポーネント設定ファイルの内容に従い、コンポーネントのインスタンス化、およびコンポーネント間の関連づけを行う。詳細については、 [リポジトリ](../../component/libraries/libraries-02-Repository.md#リポジトリ) を参照。 | +| リポジトリ | Nablarch Application Frameworkが提供するDIコンテナ。コンポーネント設定ファイルの内容に従い、コンポーネントのインスタンス化、およびコンポーネント間の関連づけを行う。詳細については、 repository を参照。 | ### わ行 diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-guide.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-guide.md index 480b8dd85..12f278f50 100644 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-guide.md +++ b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-guide.md @@ -1,19 +1,19 @@ -aboutThis -01_NablarchOutline/01_NablarchOutline -02_UnitTestOutline/01_UnitTestOutline -03_DevelopmentStep/index -04_Explanation/index -04_Explanation_batch/index -04_Explanation_messaging/index -04_Explanation_other/index -04_Explanation/09_examples -04_Explanation/08_utilities -04_Explanation/Log/Web_Log -04_Explanation/12_keitai -05_UnitTestGuide/index -06_TestFWGuide/index -08_TestTools/index -20_Appendix/02_WindowScope +* [想定読者、位置付け、対象工程、注意事項](../../about/about-nablarch/about-nablarch-aboutThis.md) +* [Nablarch Application Framework 概要](../../about/about-nablarch/about-nablarch-01-NablarchOutline.md) +* [単体テスト概要](../../development-tools/testing-framework/testing-framework-01-UnitTestOutline.md) +* [業務アプリケーション開発手順](../../guide/web-application/web-application-03-DevelopmentStep.md) +* [業務アプリケーションの実装方法 (画面オンライン処理編)](../../guide/web-application/web-application-04-Explanation.md) +* [業務アプリケーションの実装方法 (バッチ処理編)](../../guide/nablarch-batch/nablarch-batch-04-Explanation-batch.md) +* [業務アプリケーションの実装方法 (メッセージング処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-messaging.md) +* [業務アプリケーションの実装方法 (その他の処理)](../../guide/libraries/libraries-04-Explanation-other.md) +* [フレームワークAPIの使用例集](../../guide/web-application/web-application-09-examples.md) +* [開発を容易にするためのユーティリティ](../../guide/web-application/web-application-08-utilities.md) +* [ログ出力の設定方法とログの見方(画面オンライン処理編)](../../guide/web-application/web-application-Web-Log.md) +* [携帯端末(フィーチャーフォン)向け画面を実装する際の留意点](../../guide/web-application/web-application-12-keitai.md) +* [単体テスト実施方法](../../development-tools/testing-framework/testing-framework-05-UnitTestGuide.md) +* [自動テストフレームワークの使用方法](../../development-tools/testing-framework/testing-framework-06-TestFWGuide.md) +* [プログラミング工程で使用するツール](../../development-tools/toolbox/toolbox-08-TestTools.md) +* [Appendix A: ウィンドウスコープ概要](../../guide/web-application/web-application-02-WindowScope.md) ## プログラミング・単体テストガイド @@ -29,7 +29,7 @@ aboutThis 本書の想定読者、位置づけ、対象とする工程、注意事項について以下に示す。 -aboutThis +* [想定読者、位置付け、対象工程、注意事項](../../about/about-nablarch/about-nablarch-aboutThis.md) ### Nablarchアプリケーション開発概要 @@ -43,13 +43,13 @@ aboutThis 本節を読むと、アプリケーションプログラマが何を作成すればよいかを理解することができる。 -01_NablarchOutline/01_NablarchOutline +* [Nablarch Application Framework 概要](../../about/about-nablarch/about-nablarch-01-NablarchOutline.md) #### 単体テスト概要 以下では、作成したアプリケーションについて、どのような単体テストを実施すればよいかを説明する。 -02_UnitTestOutline/01_UnitTestOutline +* [単体テスト概要](../../development-tools/testing-framework/testing-framework-01-UnitTestOutline.md) ### Nablarchアプリケーション開発手順 @@ -57,7 +57,7 @@ aboutThis 初めてNablarchを使用して開発を行うアプリケーションプログラマは、本章を読んで下さい。 -03_DevelopmentStep/index +* [業務アプリケーション開発手順](../../guide/web-application/web-application-03-DevelopmentStep.md) ### Nablarchアプリケーション開発リファレンス @@ -71,56 +71,56 @@ aboutThis 以下のサンプルアプリケーションの中から、開発対象のアプリケーションに近いものを選んで参照して下さい。 -04_Explanation/index -04_Explanation_batch/index -04_Explanation_messaging/04_Explanation_real/index -04_Explanation_messaging/04_Explanation_delayed_receive/index -04_Explanation_messaging/04_Explanation_delayed_send/index -04_Explanation_messaging/04_Explanation_send_sync/index -04_Explanation_other/04_Explanation_mail/index +* [業務アプリケーションの実装方法 (画面オンライン処理編)](../../guide/web-application/web-application-04-Explanation.md) +* [業務アプリケーションの実装方法 (バッチ処理編)](../../guide/nablarch-batch/nablarch-batch-04-Explanation-batch.md) +* [業務アプリケーションの実装方法 (同期応答メッセージ受信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-real.md) +* [業務アプリケーションの実装方法 (応答不要メッセージ受信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-delayed-receive.md) +* [業務アプリケーションの実装方法 (応答不要メッセージ送信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-delayed-send.md) +* [業務アプリケーションの実装方法 (同期応答メッセージ送信処理編)](../../guide/mom-messaging/mom-messaging-04-Explanation-send-sync.md) +* [業務アプリケーションの実装方法 (メール送信処理編)](../../guide/libraries/libraries-04-Explanation-mail.md) ##### アプリケーション実装例集 アプリケーション開発で頻繁に実装する処理の実装方法について説明する。 -04_Explanation/DB/index -04_Explanation/CustomTag/index -04_Explanation/Other/index +* [web-application-DB](../../guide/web-application/web-application-DB.md) +* [画面オンライン処理の実装例集](../../guide/web-application/web-application-CustomTag.md) +* [その他実装例集](../../guide/web-application/web-application-Other.md) ##### 開発を容易にするためのユーティリティ アプリケーションでの開発を容易にするためのユーティリティについて説明をする。 -04_Explanation/08_utilities +* [開発を容易にするためのユーティリティ](../../guide/web-application/web-application-08-utilities.md) ##### 開発時のログ出力の設定方法とログの見方 アプリケーションの開発時にデバッグ作業に必要な情報を収集するために、 ログ出力の設定方法と出力されたログの見方を説明する。 -04_Explanation/Log/index +* [web-application-Log](../../guide/web-application/web-application-Log.md) ##### 携帯端末(フィーチャーフォン)向け画面を実装する場合の留意点 携帯端末(フィーチャーフォン)向け画面を実装する場合の留意点について、 以下に説明する。 -04_Explanation/12_keitai +* [携帯端末(フィーチャーフォン)向け画面を実装する際の留意点](../../guide/web-application/web-application-12-keitai.md) #### 単体テスト実施方法 単体テストの実施方法について説明する。 -05_UnitTestGuide/index +* [単体テスト実施方法](../../development-tools/testing-framework/testing-framework-05-UnitTestGuide.md) #### 自動テストフレームワーク使用方法 自動テストフレームワークの使用方法を説明する。 -06_TestFWGuide/index +* [自動テストフレームワークの使用方法](../../development-tools/testing-framework/testing-framework-06-TestFWGuide.md) #### プログラミング工程で使用するツールの使用方法 プログラミング工程で使用するツールの使用方法を説明する。 -08_TestTools/index +* [プログラミング工程で使用するツール](../../development-tools/toolbox/toolbox-08-TestTools.md) diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-introduction.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-introduction.md deleted file mode 100644 index b7422a48e..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-introduction.md +++ /dev/null @@ -1,140 +0,0 @@ -# 序 : Nablarch Application Framework (NAF)とは ? - -Nablarch Application Framework (以下NAFと呼称する) は、Nablarchプロジェクトにおける、 -Javaベースの基幹システム向けアプリケーションフレームワークです。 - -本節では、NAFの開発にあたり特に重視してきた設計思想と、そこから導かれるNAFの特色について説明することで、 -世に溢れるフレームワークの中から、どのような場合にNAFを選択すべきなのかということを -読者の方に理解していただくことを目的としています。 - ------ - -## NAFの設計思想 - -NAFの設計において、特に重視されている設計思想は以下の3つです。 - -**1. エンタープライズシステムに必要な機能要素を包括的に提供** - -一般に、多くのフレームワークは、「コンテナ」と呼ばれる一種の箱のような状態で提供されます。 -この「コンテナ」に対して、画面オンライン処理で利用するテンプレートエンジンや、リッチクライアントフレームワーク、 -バッチ系処理を行うフレームワーク、メッセージング処理を行うフレームワーク、データベースアクセスを抽象化するフレームワーク… -といった個別の機能を必要に応じて追加していくことによって一つのフレームワークとして機能します。 -このように一通りの機能を備えた状態のフレームワークを一般に「フルスタック」フレームワークと呼びます。 - -しかし、実際の基幹システム開発を行う上で、「フルスタック」フレームワークだけでは、機能的に十分とは言えません。 - -開閉局制御、業務日付管理、帳票出力といった業務系共通機能の実装や、 -運用ログや障害ログのフォーマットやローテーションのように、実際の運用を前提とした諸々の考慮が必要であり、 -それらはこれまで、各開発プロジェクト毎に個別に設計・実装されてきました。 - -NAFでは、TISがこれまで培った、ミッションクリティカル・大規模開発での経験をもとに、 -実際のシステム開発で必要な全ての機能を備えた、真の意味での「フルスタック」フレームワークを実現しています。 - -それには、以下の内容が含まれます。 - -* 画面オンライン入力、バッチ入力、他システムからの要求電文といった基本的な外部入力に対するアプリケーション実行機能 -* 電文送信、メール送信、帳票出力、ファイル出力、DB接続といった外部出力機能 -* ログ出力、入力精査、認証認可、開閉局制御、業務日付管理、採番処理、コード値管理といった共通機能 - -**2. 単体テストからシステムテスト、リグレッションテストを含めた工程全体でのテスト工数の極小化** - -JUnitのローンチ以降、テスト駆動開発の概念はエンタープライズシステム開発でも一般のものになりつつあります。 -しかし、実際のプロジェクトでJUnit等を導入し、テスト駆動開発を行っても、思うような効果を挙げることはなかなか難しいようです。 -それどころか、開発側から「かえって手間が増えて逆効果だ」との声が上がることさえあります。 - -なぜでしょうか。 - -テスト駆動開発の最大のメリットは、開発の初期段階からソースコードを頻繁に動作させ、その挙動を随時確認しながら開発することにより、 -高速にフィードバックが得られ、問題が深刻化する前に修正できるという点にあります。 -このメリットを開発者が実感できなければテスト駆動開発を行う意味はほとんど無いと言えます。 - -しかし、実際の開発現場では、以下のような要因により「高速なフィードバック」というテスト駆動開発のメリットを十分に -享受できていないことが多いのです。 - -**要因1.** GUIをともなう機能では、そもそも画面打鍵をしなければフィードバックが得られない。 - -GUIを伴う業務機能では、打鍵作業を行わなければ挙動を確認できません。 -JUnit等を用いてロジック部分のみをテスト駆動で開発し、その後画面部分の作り込みを行った場合、 -テスト駆動で開発者が得られるのはあくまで部分的なフィードバックのみであり、 -画面を作成して打鍵確認を実施するまで、全体の挙動に対するフィードバックを得ることはできなくなります。 - -結果として、テスト駆動を行うことでフィードバックの受け取りが遅れることになります。 -これは、テスト駆動の目的から考えるとまさに本末転倒であり、開発者からしても非常にストレスを感じる開発手法といえます。 -結局のところ、ロジック側が複雑な一部のケースを除けば、先に画面を作成し、そこに業務機能を埋め込みながら動作を -確認していくという従来の手法が、テスト駆動の観点から見てもより効率的であると言えます。 - -**要因2.** 事前条件のセットアップがテストケース内で完結しないため、本番環境で打鍵しないとフィードバックが得られない。 - -業務機能のテストを実施するためには、 そのテストケースの事前条件をセットアップする必要があります。 -これには、業務機能が参照する他サブシステム主管のマスタテーブルの内容や、HTTPセッションスコープの内容、 -外部システムから送信される要求電文など、様々な情報が含まれます。 -これらの内容をテストケース内でセットアップできなければ、その部分は自動テストの対象から除外し、モック化した状態で -テストすることになります。 - -その結果、自動テストの対象となるのは純粋なビジネスロジックを中心とした部分となります。 -しかし、一般的な業務機能をにおいて、純粋なビジネスロジックは機能全体のせいぜい2～3割程度でしかありません。 -そのため、テストケースから得られるフィードバックも非常に限定されたものとなり、 -テストケースを整備することによるメリットが失われることになります。 - -このように、開発者がテスト駆動開発メリットを享受できていない状況では、自動テストの整備が自発的に行われることもなく、 -早晩に形骸化することになります。 - -また、上述のような状況では、自動テストによって検証可能な範囲が限られているので、修正後のリグレッションテストにおいても -打鍵テストの再実施とエビデンスの再提出を求められることが一般的です。 -このため、自動テストを整備していても再帰テストの工数が落ちることはほとんどありません。 - -端的にいえば、 - -**「どうせ毎回打鍵テストしてエビデンスもとっているのに、わざわざ工数を使って自動テストをメンテナンスする必要があるのか？」** - -ということになります。 - -これに対し、Nablarchでは、TISが過去の大規模プロジェクトにおいて実際にテスト駆動開発を適用することで得られた知見を、 -NAFと並行開発されたテスティングフレームワークである NTF(Nablarch Testing Framework) として集約し提供しています。 - -NTFおよびNAFでは、自動テスト内で、DBのテーブル、HTTPセッションの内容、バッチの入力ファイルの内容、メッセージングキュー上の電文など、 -業務機能の実行に必要なあらゆる事前条件をテストケースの中でセットアップできるようにしています。 -また、打鍵テスト作業中の状態をテストの事前条件としてエクスポートするなど、 -事前条件のセットアップが簡便に行える機能を整備しています。 - -その上で、単体テスト工程だけでなく、結合テスト、システムテストも含めた開発工程全体の中で、テストに要する工数を極小化するためには、 -どこまでを自動テストで担保し、どの部分を打鍵で確認すべきかを再考してベストプラクティスとして体系化しています。 -これにより、開発者の観点から見て本当に効果が実感できるテスト駆動開発を実現しています。 - -**3. 自前主義** - -近年のシステム開発では、オープンソースを中心とした既存のプログラムを組み合わせることによって、 -より手早く、より低コストに開発するという考え方が主流になってきています。 -また、上で述べたように、近年の「コンテナ」型のフレームワークは、必要に応じて複数のフレームワークを組み合わせて利用することを -前提とした構造となっており、そのような開発形態を容易に行うことができるようになっています。 - -しかし、このような開発形態には以下に挙げるようなデメリットも存在します。 - -* アーキテクチャ一貫性の喪失 -* 構成管理の複雑化 -* ソースコードガバナンスに関するOSS特有の問題 - -まず1点目は、複数のプロダクトが混在することにより、様々な規約やアーキテクチャを基に開発されたコンポーネントが乱立し、 -全体的な一貫性が失われる点です。 -また、プロダクト間で重複する機能が実装されていた場合は、そのどちらか一方のみを使用することになるのですが、 -この場合、フレームワーク内に決して利用されない機能が発生することになります。 - -2点目は、長期的にみた管理のむずかしさです。各プロジェクトにはそれぞれ独立した運営方針があり、機能追加や不具合の改修について、 -こちらで制御することはできません。もし、独自に対応を行ったとしても、その内容が開発側でマージしてもらえるという保証はありません。 -マージされるまでの間は、バージョンアップ毎に修正点をマージしなおす必要があり、場合によってはデグレーションを誘発する危険性もあります。 - -3点目は、ソースコードのガバナンスの問題です。 -オープンソースは、その「クリーン」なイメージにとは裏腹に、その黎明期から常に訴訟の対象となってきました。 - -実際に、企業が主体で推進するオープンソースプロジェクトのコードの中に、競合する商用ソフトウェアから流用したとみられる -コードが混在していたという過去の事例もあります。 -特に高いガバナンスが求められる金融系基幹システム開発において、このような問題は喫緊の課題といえます。 - -しかし、オープンソースプロジェクトでは、様々な開発者が参加することが可能であり、 -そこにコミットされるコードの出所を管理することは実質的に不可能です。 - -NAFでは、OSやJDK、データベース、アプリケーションサーバ等の基盤ソフト/ミドルウェア製品を除けば、 -全ての部品をスクラッチ開発しています。 -これは、全ての機能を一貫した指針のもとに実装し、上に挙げた問題点を回避するために不可欠と判断したためです。 - ------ diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-link.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-link.md deleted file mode 100644 index e69de29bb..000000000 diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-overview-of-NAF.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-overview-of-NAF.md deleted file mode 100644 index 4affbca8f..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-overview-of-NAF.md +++ /dev/null @@ -1,101 +0,0 @@ -# NAF概要 - -## NAFの構成 - -本フレームワークは大きく分けて、以下の3つのモジュール群によって構成されている。 - -1. **NAF実行制御基盤** - -NAF実行制御基盤は、外部からの処理要求に対して適切な業務処理を選択し実行するフレームワークである。 -NAFでは、エンタープライズシステムで利用される処理形態に対応した以下の実行制御基盤を提供している。 - -* [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) -* [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) -* [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) - -1. **NAF基盤ライブラリ** - -NAF基盤ライブラリとは、 [ログ出力](../../component/libraries/libraries-01-Log.md#ログ出力) 、 [データベースアクセス](../../component/libraries/libraries-04-DbAccessSpec.md#概要) 、 [システム間メッセージング機能](../../component/libraries/libraries-enterprise-messaging.md) など、 -独立した共通機能を実装したモジュール群である。 - -1. **NAF共通コンポーネント** - -NAF共通コンポーネントとは、業務機能の実装において共通的に必要となる機能を -NAF実行制御基盤および、NAF基盤ライブラリを用いて実装したモジュール群である。 - -これには、 [認可](../../component/libraries/libraries-04-Permission.md#認可) 、 [開閉局](../../component/libraries/libraries-05-ServiceAvailability.md#開閉局) などの -業務機能やアプリケーションの運用に関連したモジュールが含まれる。 - -以下の図は、これらのモジュール群および、業務ロジックを実装する業務コンポーネントの依存関係を表した図である。 - -![nablarch_structure.png](../../../knowledge/assets/about-nablarch-overview-of-NAF/nablarch_structure.png) - -**NAF構成図** - -## Nablarchアプリケーション処理方式 - -Nablarchアプリケーション処理方式とは、Nablarch標準の方式設計書(アプリケーション処理方式)内で定義されている -標準のアプリケーションアーキテクチャである。 -当然ながら、NAFはこの処理方式で述べられている内容を実現するように設計・実装されている。 - -Nablarchアプリケーション処理方式は、あくまでアプリケーションアーキテクチャであり、厳密にいえば、 -NAFとは直接関係しない。(例えば、Nablarchアプリケーション処理方式に対して、他のOSS製品群をベースとした実装系を実現することも可能である。) - -しかし、実際には互いに相補的関係にあるので、ここで、Nablarchアプリケーション処理方式とNAFによる実装の概略について述べる。 - -### Nablarchアプリケーション処理方式の概要 - -Nablarchアプリケーション・アーキテクチャは **入力処理方式** 、 **出力ライブラリ** 、 **処理方式共通** の３要素から構成される。 - -**1. 入力処理方式** - -本システムへの処理要求を受け付け、処理を実行する基本形態であり、以下の8つの処理方式に分類される。 - -| No. | 大分類 | 入力インターフェース | 入力処理方式名称 | 概要 | -|---|---|---|---|---| -| 1 | オンライン | 画面 | 画面同期処理方式 | Webブラウザからのリクエストをもとにデータ照会・更新等の処理を行い、 処理結果をWebブラウザへ返却する処理方式。 | -| 2 | | | 画面非同期処理方式 | Webブラウザからのリクエストをもとにデータ照会・更新等の処理を行い、 その処理結果をWebブラウザへ返却するとともに、大量データ処理や 複雑で長時間かかる処理、外部へ非同期でデータ連携する処理を 遅延実行する処理方式。 | -| 3 | | メッセージ | メッセージ同期応答 処理方式 | 他システムからの要求電文をもとにデータ照会・更新等の処理を行い、 処理結果を送信元システムへ返却する処理方式。 | -| 4 | | | メッセージ非同期 応答処理方式 | 他システムからの要求電文をもとにデータ照会・更新等の処理を行い、 処理結果を送信元システムへ返却するとともに、大量データ処理や 複雑で長時間かかる処理、外部へ非同期でデータ連携する処理を 遅延実行する処理方式。 | -| 5 | | | メッセージ無応答 処理方式 | 他システムからの要求電文をもとにデータ更新等の処理を行う処理方式 送信元システムへの応答は行わないため、全て遅延実行で処理を行う。 | -| 6 | | ファイル | ファイル転送処理方式 | 他システムからの転送ファイルをもとにデータ更新等の処理を行う処理方式。 | -| 7 | オフライン | －（オフライン） | 都度起動バッチ 処理方式 | ジョブスケジューラーからの定刻起動等により、大量データを一括実行する 処理方式。（いわゆる一般的なバッチ処理） | -| 8 | | | 常駐バッチ処理方式 | 起動後にプロセスを常駐させ、データベースを常駐監視し、 インプットデータが登録されたタイミングで即時実行を行う処理方式。 | - -**2. 出力ライブラリ** - -本システムの外部にファイルやメッセージを出力する際に業務アプリケーションから実行される処理の方式であり、 -以下の4つに分類される。 - -| No. | 出力媒体 | 処理方式名 | 概要 | -|---|---|---|---| -| 1 | メッセージ | 同期応答メッセージ送信 | 他システムへ要求電文を送信し、他システムからの処理結果を受信する。 | -| 2 | | 無応答メッセージ送信 | 他システムへ要求電文を送信する。 他システムからの処理結果は受信しない。 | -| 3 | ファイル | ファイル転送 | 他システムへファイルを転送する。 | -| 4 | メール | メール送信 | 電子メールを送信する。 なお、本システムでは、外部のメールASPサービスを利用し、SMTPリレーを行う。 | - -**3. 処理方式共通** - -適用する入力処理方式・出力処理方式を問わずに共通的に実行される処理の方式である。 - -* ログ出力処理方式 -* データベースアクセス処理方式 -* ファイルアクセス処理方式 -* 文字コード処理方式 -* メッセージ管理処理方式 -* 認証・認可処理方式 -* コード管理処理方式 -* 採番処理方式 -* 日付・日時処理方式 -* 国際化処理方式 -* **... etc** - -### NAFによるNablarchアプリケーション処理方式の実装 - -以下の図は、上述したNablarchの各処理方式に対するNAFの実装範囲を示したものである。 - -一部の例外 (ファイル転送入力処理方式など) はあるものの、Nablarchアプリケーション処理方式の大部分がNAFによって実現されていることがわかる。 - -![nablarch_structure2.png](../../../knowledge/assets/about-nablarch-overview-of-NAF/nablarch_structure2.png) - -**NAF構成図** diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-platform.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-platform.md deleted file mode 100644 index c451c6c8d..000000000 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-platform.md +++ /dev/null @@ -1,29 +0,0 @@ -# 動作を保証するプラットフォーム - -本フレームワークは、下記のプラットフォームにおいてテストを実施し、 -正常に動作することを確認している。 - -## Java - -* J2SE 5.0 -* Java SE 6 - -## アプリケーションサーバ - -* Oracle Weblogic Server 11g -* WebSphere Application Server 7.0 -* Apache Tomcat 6.0 - -## データベースサーバ - -* Oracle Database 11g -* DB2 9 -* SQLServer 2008 - -## ブラウザ - -* Windows Internet Explorer 6 -* Windows Internet Explorer 7 -* Windows Internet Explorer 8 -* Mozilla Firefox 3.6 -* Google Chrome 10 diff --git a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-top.md b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-top.md index f4d1c1ca3..cef0fdf18 100644 --- a/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-top.md +++ b/.claude/skills/nabledge-1.2/docs/about/about-nablarch/about-nablarch-top.md @@ -6,11 +6,11 @@ Nablarch(ナブラーク)は、TISの豊富な基幹システム構築経験から得られたナレッジを集約したJavaアプリケーション開発/実行基盤です。 -about_nablarch/concept -about_nablarch/development_policy -about_nablarch/contents -about_nablarch/support_service -about_nablarch/versionup_policy +* [Nablarchのコンセプト](../../about/about-nablarch/about-nablarch-concept.md) +* [Nablarchの目指す姿](../../about/about-nablarch/about-nablarch-development-policy.md) +* [Nablarch の製品構成](../../about/about-nablarch/about-nablarch-contents.md) +* [Nablarchのサポートサービスについて](../../about/about-nablarch/about-nablarch-support-service.md) +* [Nablarch のバージョンアップ方針](../../about/about-nablarch/about-nablarch-versionup-policy.md) ### Nablarchのコンテンツ @@ -18,7 +18,7 @@ Nablarchのコンテンツは nablarchフォルダに格納されています。 * [Nablarchのコンテンツ](./nablarch/index.html) -nablarch/index +* [Nablarch フォルダのコンテンツについて](../../about/about-nablarch/about-nablarch-top-nablarch.md) また、Nablarchを使用したアプリケーション開発に関する質問については、FAQを参照してください。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-AsyncMessageReceiveAction.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-AsyncMessageReceiveAction.md deleted file mode 100644 index c33f37739..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-AsyncMessageReceiveAction.md +++ /dev/null @@ -1,101 +0,0 @@ -## 応答不要電文受信処理用アクションハンドラ - -**クラス名:** `nablarch.fw.messaging.action.AsyncMessageReceiveAction` - ------ - ------ - -### 概要 - -本クラスは、 [応答不要メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-receive.md) における典型的な業務アクションハンドラの実装であり、 -受信電文内のデータレコードを指定されたテーブルに保存する。 - -保存されたデータは後続のバッチによって処理されることを想定している。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| 応答不要電文受信処理用アクションハンドラ | nablarch.fw.messaging.action.AsyncMessageReceiveAction | RequestMessage | Result | 要求電文内のデータレコードを指定されたテーブルに保存する。 | 正常終了(Result.Success)をリターンする。 | - | - -**受信電文保存テーブルの構造** - -受信電文の内容を保存するテーブルは、以下の内容に従って定義されている必要がある。 - -| 項目 | 内容 | -|---|---| -| 受信電文連番 | 主キー 受信した電文を一意に識別するためのIDを格納するカラム。 本カラムに設定する値は、[{@link](mailto:{@link) #generateReceivedSequence()}にて採番を行う。 カラムの桁数は、任意の桁数を設定可能となっている。 | -| 業務電文部 | 業務電文を格納するカラムを定義する。 電文の種類に応じて、業務電文の各項目に対するカラムを定義すれば良い。 | -| 共通項目部 | 各プロジェクトの方式に応じて必要なカラムを定義する。 たとえば、下記のカラムを定義することが想定される。 ・登録情報(ユーザID、タイムスタンプ、リクエストID、実行時ID) ・更新情報(ユーザID、タイムスタンプ) | - -本クラスは1電文を1レコードとして受信テーブルに保存することを前提としている。 -1電文を複数レコードとして登録する場合や、複数テーブルに保存する場合は -本クラスを継承した業務アクションハンドラクラスを別途作成する必要がある。 - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (業務データ領域の解析)** - -要求電文の業務データ領域全体をデフォルトのフォーマッタを用いて解析し、データレコードを取得する。 - -**2. (電文データ登録用のフォームクラスのロード)** - -以下で定義されるクラスをロードする。 - -```bash -[フォームクラス配置パッケージ設定値] + "." + [受信電文のリクエストIDヘッダ値] + "Form" -``` - -**3. (受信電文連番の採番)** - -本ハンドラに設定された採番モジュールを使用して、受信電文に対する登録用の通番を取得する。 - -**3. (フォームインスタンスの生成)** - -**2.** で取得したクラスのインスタンスを、以下のコンストラクタを使用して生成する。 -コンストラクタの引数として、本ハンドラの引数である受信電文オブジェクト、および、 -**3.** で採番した受信電文通番を使用する。 - -```java -public フォームクラス名(String 受信電文通番, RequestMessage 受信電文オブジェクト) -``` - -**4. (電文データ登録処理)** - -以下のリソースファイルに記載されたSQL定義からプリペアードステートメントを作成し、 -**3.** で作成したフォームインスタンスを埋め込みパラメータとして実行する。 - -```bash -[SQLファイル配置パッケージ設定値] + "." + [受信電文のリクエストIDヘッダ値] + "#INSERD_MESSAGE" -``` - -**[往路処理]** - -**5. (正常終了)** - -正常終了のマーカオブジェクト([Result.Success](../../javadoc/nablarch/fw/Result.Success.html))をリターンして終了する。 -(このハンドラでは後続ハンドラに対する処理移譲は行わない。) - -**[例外処理]** - -**2a. (フォームクラスロードエラー)** - -当該のフォームクラスがクラスパス上に存在しなかった場合は、実行時例外を送出する。 - -**3a. (フォームインスタンス生成エラー)** - -**3.** で呼び出したコンストラクタが存在しなかった場合、もしくは、コンストラクタ実行中に何らかのエラーが発生した場合は、 -実行時例外を送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定値は、 [AsyncMessageReceiveActionSettings](../../javadoc/nablarch/fw/messaging/action/AsyncMessageReceiveActionSettings.html) に集約されている。 -以下はその設定項目の一覧である。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| フォームクラス配置パッケージ | formClassPackage | String | 必須指定 電文データ登録の際に使用するフォームクラスの パッケージ名を設定する。 | -| 受信電文連番発番用オブジェクト | receivedSequenceGenerator | IdGenerator | 任意指定。デバッグや障害解析用に無効化する。 デフォルトはtrue(自動削除を実施) | diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-AsyncMessageSendAction.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-AsyncMessageSendAction.md deleted file mode 100644 index bdcdeae3f..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-AsyncMessageSendAction.md +++ /dev/null @@ -1,141 +0,0 @@ -## 応答不要電文送信処理用アクションハンドラ - -**クラス名:** `nablarch.fw.messaging.action.AsyncMessageSendAction` - ------ - ------ - -### 概要 - -本クラスは、 [応答不要メッセージ送信常駐バッチ](../../component/libraries/libraries-messaging-sending-batch.md) において、 -電文送信処理を実行するアクションハンドラである。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| 共通起動ランチャ | nablarch.fw.handler.Main | CommandLine | Integer | Javaコマンドから直接実行することで、DIリポジトリを初期化し、ハンドラキューを構築・実行する。 | 後続ハンドラの処理結果(整数値)を終了コードに指定し、プロセスを停止する。 | Fatalログを出力しプロセスを異常終了させる。 | - | -| マルチスレッド実行制御ハンドラ | nablarch.fw.handler.MultiThreadExecutionHandler | Object | MultiStatus | サブスレッドを作成し、後続ハンドラの処理を並行実行する。 実行コンテキスト上にデータリーダが存在しない場合は、コールバックを行う。 | 全スレッドの正常終了まで待機する。 | 処理中のスレッドが完了するまで待機し起因例外を再送出する。 | 1. 処理開始前 / 2. データリーダ作成 / 3. スレッド異常終了時 / 4. 処理完了時 | -| メッセージングコンテキスト管理ハンドラ | nablarch.fw.messaging.handler.MessagingContextHandler | Object | Object | メッセージングコンテキスト(MQ接続)を取得し、スレッドローカルに保持する。 | メッセージングコンテキストを開放する。（プールに戻す） | メッセージングコンテキストを開放する。（プールに戻す） | - | -| トランザクション制御ハンドラ | nablarch.fw.common.handler.TransactionManagementHandler | Object | Object | 業務トランザクションの開始 | トランザクションをコミットする。 | トランザクションをロールバックする。 | 1.コミット完了後 / 2.ロールバック後 | -| データリードハンドラ | nablarch.fw.handler.DataReadHandler | Object | Result | 業務アクションハンドラが決定したデータリーダを使用してレコードを1件読み込み、後続ハンドラの引数として渡す。また実行時IDを採番する。 | - | 読み込んだレコードをログ出力した後、元例外を再送出する。 | - | -| 応答不要電文送信処理用アクションハンドラ | nablarch.fw.messaging.action.AsyncMessageSendAction | SqlRow | Result | テーブル上の各レコードの内容から送信電文オブジェクトを生成し送信する。 | 正常終了(Result.Success)をリターンする。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [共通起動ランチャ](../../component/handlers/handlers-Main.md) | 送信対象電文のリクエストIDを起動時の引数 **-messageRequestId** に指定する。 | -| [メッセージングコンテキスト管理ハンドラ](../../component/handlers/handlers-MessagingContextHandler.md) | 本ハンドラでは、スレッドローカル上の [メッセージングコンテキスト](../../component/libraries/libraries-enterprise-messaging.md#メッセージング基盤api) を用いて送信処理を行う。 | -| [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) | トランザクションコミット完了後、およびロールバック時のコールバック内で、 送信ステータスの更新処理を行う。 | -| [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) | 本ハンドラが作成したデータリーダ ( [データベースレコードリーダ](../../component/readers/readers-DatabaseRecordReader.md) ) を 使用して処理対象レコードの読込みを行う。 | - -### ハンドラ処理フロー - -**[コールバック]** - -**1. (送信メッセージのメッセージIDを取得)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) の処理開始前にコールバックされ、 -起動引数 **-messageRequestId** の値を [CommandLine](../../javadoc/nablarch/fw/launcher/CommandLine.html) オブジェクトより取得する。 - -**2. (データリーダの作成)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) からコールバックされ、送信メッセージの内容が格納されたテーブルに対する -データリーダを作成してリターンする。 - -具体的には以下のSQLリソースを取得し、そのクエリに対するプリペアードステートメントを使用する -[データベースレコードリーダ](../../component/readers/readers-DatabaseRecordReader.md) を作成して返す。 - -```bash -(SQL定義配置パッケージ設定値) + "." + ( 1. で取得したメッセージリクエストID ) + "#" + "SELECT_SEND_DATA" -``` - -**[往路処理]** - -**3. (送信電文オブジェクトの作成)** - -送信電文オブジェクト( [SendingMessage](../../javadoc/nablarch/fw/messaging/SendingMessage.html) ) を生成する。 - -**4. (フレームワーク制御ヘッダ部フォーマット定義を取得)** - -設定値に指定されたフレームワーク制御ヘッダ定義ファイルを取得する。 - -**5. (フレームワーク制御ヘッダを作成)** - -**4.** で取得したフォーマット定義に従って、フレームワーク制御ヘッダを以下の手順で作成し、 -送信電文オブジェクトに設定する。 - -* **1.** で取得したメッセージリクエストIDを、 **requestId** フレームワーク制御ヘッダに設定。 -* フレームワーク制御ヘッダ項目名リストに設定された項目名と同じフィールドが処理対象レコードに定義されていれば - その値をヘッダ値として設定する。当該のフィールドが存在しない場合は、nullを設定する。 - -**6. (メッセージデータ部フォーマット定義を取得)** - -設定値に指定されたフォーマット定義ファイルの論理パスから、下記ファイル名のフォーマット定義を取得する。 - -```bash -( 1.で取得したメッセージリクエストID ) + "_SEND" -``` - -**7. (メッセージデータ部を作成)** - -**6.** で取得したフォーマット定義に従って、処理対象レコードからメッセージデータ部を作成し、 -送信電文オブジェクトに設定する。 -(処理対象レコードの各フィールドが、フォーマット定義上の各フィールドの値として設定される。) - -**8. (メッセージ送信)** - -設定値に指定された送信宛先キュー論理名を送信電文オブジェクトに設定し、 -カレントスレッド上のメッセージングコンテキストを使用して送信する。 - -**[往路処理]** - -**5. (正常終了)** - -正常終了のマーカオブジェクト([Result.Success](../../javadoc/nablarch/fw/Result.Success.html))をリターンして終了する。 -(このハンドラでは後続ハンドラに対する処理移譲は行わない。) - -**[例外処理]** - -(本ハンドラでは明示的な例外制御は行わない。処理中に発生した実行時例外はそのまま送出される。) - -**[コールバック]** - -**6. (処理対象レコードステータス変更1)** - -[トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) でのコミットが完了した場合にコールバックされ、 -以下のSQLリソースを実行し、処理対象レコードのステータスを処理済みに更新する。 - -```bash -(SQL定義配置パッケージ設定値) + "." + ( 1. で取得したメッセージリクエストID ) + "#" + "UPDATE_NORMAL_END" -``` - -**6a. (処理対象レコードステータス変更2)** - -[トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) において、業務トランザクションがロールバックした場合に場合にコールバックされ、 -以下のSQLリソースを実行し、処理対象レコードのステータスをエラーに更新する。 - -```bash -(SQL定義配置パッケージ設定値) + "." + ( 1. で取得したメッセージリクエストID ) + "#" + "UPDATE_ABNORMAL_END" -``` - -**7. (ステータス変更エラー)** - -**6.** もしくは **6a.** でのステータス変更の対象となったレコード数が1でなかった場合は、実行時例外を送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定値は、 [AsyncMessageSendActionSettings](../../javadoc/nablarch/fw/messaging/action/AsyncMessageSendActionSettings.html) に集約されている。 -以下はその設定項目の一覧である。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| SQL定義配置パッケージ | sqlFilePackage | String | (必須指定) このハンドラで使用するSQL定義ファイルを格納する パッケージ名を設定する。 | -| 送信宛先キュー論理名 | queueName | String | (必須設定) メッセージの送信宛先キューの論理名を設定する。 | -| フォーマット定義格納ディレクトリ | formatDir | String | (任意指定: デフォルト="format") 送信電文のフォーマット定義を格納するディレクトリ の論理パスを指定する。 | -| ヘッダフォーマット定義名 | headerFormatName | String | (必須指定) 送信電文のフレームワーク制御ヘッダのフォーマット 定義ファイル名を指定する。 | -| フォームクラス名 | formClassName | String | (必須指定) 送信要求テーブル上の送信ステータス項目更新処理で 使用するフォームクラスの名称を指定する。 | -| フレームワーク制御ヘッダ項目リスト | headerItemList | List | (任意指定: デフォルト=ヘッダ項目には何も指定しない) レコードのフィールドのうち、 送信電文のフレームワーク制御ヘッダとして設定する 項目のリストを設定する。 | -| トランザクション名 | transactionName | String | (任意指定: デフォルト="transaction") 送信要求のステータス変更処理で使用する トランザクションの識別名 | diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-BatchAction.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-BatchAction.md deleted file mode 100644 index c4778ffc0..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-BatchAction.md +++ /dev/null @@ -1,147 +0,0 @@ -## バッチ処理用業務アクションハンドラのテンプレートクラス - -**クラス名:** `nablarch.fw.action.BatchAction` - ------ - ------ - -### バッチ処理用アクションハンドラのバリエーション - -本ハンドラは、バッチ処理の実装において汎用的に利用できることを目的として設計されているが、 -その他にも、特定の用途に特化した以下の実装が用意されているので、要件と照らし合わせて適切なものを選択すること。 - -| テンプレートクラス | 内容 | -|---|---| -| [バッチ処理用業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-BatchAction.md) | (本ハンドラ) バッチ処理の実装において汎用的に利用できる標準実装。 | -| [ファイル入力のバッチ業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-FileBatchAction.md) | ファイルを入力とし、レコード種別(ヘッダー、データ、トレーラ ...etc) ごとに、 実行する業務処理を呼び分けたい場合に使用する。 | -| [入力データを使用しないバッチ処理用業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-NoInputDataBatchAction.md) | レコード1件ごとに業務処理を行うのではなく、一回だけ特定の処理を実行したい場合に使用する。 (アンロード処理のような単発処理を実行するバッチを作成する場合に用いる。) | - -### 概要 - -本クラスは、 [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) における -業務アクションハンドラを実装する際に使用するテンプレートクラスである。 - -[バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) では、 -1トランザクション分の業務処理に必要なレコードを読み込む機能を実装したデータリーダの **read()** メソッドと、 -業務トランザクション内で実行する業務処理を実装した本クラスの **handler()** メソッドを交互に呼び出し、 -データリーダからレコードが読み込めなくなった時点で終了する。 - -データリーダは、本クラスに実装された **createReader()** メソッドの戻り値が使用される。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| バッチ処理用業務アクションハンドラ | nablarch.fw.action.BatchAction | SqlRow | Result | データリーダが読み込んだ1件分のデータレコードを入力として業務処理を実行する。 | 処理結果オブジェクトを返す。(通常はResult.Successを返す) | - | - ------ - -本クラスを継承してアクションハンドラを実装するには、以下のテンプレートメソッドを必要に応じて実装する。 - -| メソッド名 | 内容 | -|---|---| -| createReader() | (必須実装) フレームワークがバッチの処理対象レコードの読込みに使用する [データリーダ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#データリーダ) を作成する際に コールバックされるので、 バッチ処理で使用するデータリーダを生成してリターンする。 | -| handle() | (必須実装) バッチの処理対象レコード1件ごとに呼び出される。 [データリーダ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#データリーダ) によって読み込まれた1件分のレコードが渡されるので、それをもとに 業務処理を実行する。 正常に終了した場合は、ハンドラの処理が正常終了したことを表す マーカーオブジェクト([Result.Success](../../javadoc/nablarch/fw/Result.Success.html))をリターンすればよい。 | -| transactionSuccess() | (任意実装) 業務トランザクションのコミットが完了した後でコールバックされる。 デフォルトでは何もしない。 | -| transactionFailure() | (任意実装) 業務トランザクションのロールバック後にコールバックされる。 デフォルトでは何もしない。 | -| initialize() | (任意実装) バッチ処理の開始前に一度だけ呼ばれる。 デフォルトでは何もしない。 | -| error() | (任意実装) 実行時例外/エラーの発生によってバッチがエラー終了した場合に 一度だけコールバックされる。 デフォルトでは何もしない。 | -| terminate() | (任意実装) バッチ処理が全件終了もしくはエラーにより終了した後で 一度だけコールバックされる。 デフォルトでは何もしない。 | - -以下のソースコードは、フレームワークが本クラスの各テンプレートメソッドを -どのタイミングで呼び出すかを表したものである。 - -```java -CommandLine command; // バッチ起動時のコマンドライン -ExecutionContext ctx; // 実行コンテキスト - -initialize(command, ctx); // バッチ処理開始前に一度だけ呼ばれる。 -DataReader reader = createReader(ctx); // バッチ処理開始前に一度だけ呼ばれる。 - -Result result = null; - -try { - while(reader.hasNext()) { // データリーダ上のレコードが終端に達するまで繰り返す。 - - TData data = reader.read(ctx); // 業務トランザクション1件分の入力データを読み込む。 - - try { - result = handle(data, ctx); // 入力データ1件毎に繰り返し呼ばれる。 - commit(); // 業務トランザクションをコミット - transactionSuccess(data, ctx); // 業務トランザクションがコミットされた後で呼ばれる。 - - } catch(e) { - rollback(); // 業務トランザクションをロールバック - transactionFailure(data, ctx); // 業務トランザクションがロールバックされた後で呼ばれる。 - throw e; - } - } - -} catch(e) { - error(e, ctx); // バッチがエラー終了した場合に、一度だけ呼ばれる。 - -} finally { - terminate(result, ctx) // バッチが終了した後、一度だけ呼ばれる。 -} -``` - -> **Note:** -> このコードはあくまで説明用に単純化したものであり、実際の処理フローはこのようなロジックでは無く、 -> ハンドラ構成によって制御されており、全く別物である。 - -### ハンドラ処理フロー - -**[コールバック]** - -**1. (バッチ処理開始前初期処理)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) での処理開始時に **initialize()** を実行する。 - -**2. (データリーダ生成)** - -続いて、 [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) での処理開始時に、 **createReader()** を実行する。 -リターンした [データリーダ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#データリーダ) は、実行コンテキストに設定され、以降の処理で使用する。 - -**[往路処理]** - -**3. (入力レコード1件に対する業務処理を実行)** - -引数として渡された入力レコードに対する業務処理を実行する。 - -**[復路処理]** - -**4. (正常終了)** - -正常終了を表すマーカオブジェクト( [Result.Success](../../javadoc/nablarch/fw/Result.Success.html) ) をリターンする。 - -**[例外処理]** - -**4a. (エラー終了)** - -業務処理に失敗した場合は、実行時例外を送出する。 - -**[コールバック]** - -**5. (業務トランザクション正常終了時の処理)** - -本ハンドラでの処理終了後、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) で業務トランザクションが正常にコミットされた場合、 -本ハンドラの **transactionSuccess()** を実行する。 - -**5a. (業務トランザクションロールバック時の処理)** - -本ハンドラでの処理終了後、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) で業務トランザクションがロールバックされた場合、 -本ハンドラの **transactionFailure()** を実行する。 - -**6. (バッチエラー終了時)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) でバッチ処理実行用のサブスレッドがエラーにより停止した場合、 -本ハンドラの **error()** を実行する。 - -**7. (バッチ終了時)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) でバッチ処理実行用のサブスレッドが終了した場合、 -本ハンドラの **terminate()** を実行する。 -(このコールバックは、バッチがエラー終了した場合でも、 **6.** の処理の後で呼ばれる。) diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DataReadHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DataReadHandler.md deleted file mode 100644 index ed0ff7678..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DataReadHandler.md +++ /dev/null @@ -1,122 +0,0 @@ -## データリードハンドラ - -**クラス名:** `nablarch.fw.handler.DataReadHandler` - ------ - ------ - -### 概要 - -データリーダを使用して、入力データの順次読み込みを行なうハンドラ。 - -このハンドラは、実行コンテキスト上のデータリーダを使用し、 -業務処理に対する入力データを1件ずつ読み込み、それを引数として後続ハンドラに処理を委譲する。 -データリーダの終端に達した場合は、後続のハンドラを実行せずに、マーカーオブジェクトとして -[DataReader.NoMoreRecord](../../javadoc/nablarch/fw/DataReader.NoMoreRecord.html) を返却する。 - -また、読み込み件数の上限を設定することが可能である。 - -> **Note:** -> データを読み出す媒体や一回の読み込みで取得するデータの型、その内容 -> については、このハンドラに設定されたデータリーダの仕様に依存する。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| データリードハンドラ | nablarch.fw.handler.DataReadHandler | Object | Result | 業務アクションハンドラが決定したデータリーダを使用してレコードを1件読み込み、後続ハンドラの引数として渡す。また実行時IDを採番する。 | - | 読み込んだレコードをログ出力した後、元例外を再送出する。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (読み込み回数のカウントアップ)** - -本ハンドラに読み込み回数上限値が設定されている場合は、現在の読み込み回数に1を加える。 -(カウントアップは同期ブロック内で行なう。) -上限値が未設定、もしくは0以下の値が設定されている場合、このカウントアップは行なわない。 - -**1a. (読み込み回数超過)** - -カウントアップの結果、現在の読み込み回数が上限値を超過した場合は、実行コンテキスト上の -データリーダおよびデータリーダファクトリを除去する。 -これにより、次回のループ開始判定のところで処理が停止する。 -(現在実行中の処理についてはそのまま継続する。) - -**2. (データ読み込み)** - -実行コンテキスト上のデータリーダから、データを1件読み込む。 -読み込まれたデータはリクエストスコープにも設定される。 (キー名 **"nablarch_request-data"** ) - -**2a. (データ終端)** - -データリーダの戻り値がnullであった場合、データリーダの終端に達したと判断し -[DataReader.NoMoreRecord](../../javadoc/nablarch/fw/DataReader.NoMoreRecord.html) を返却する。 -この際、後続ハンドラの処理は実行されない。 - -**3. (実行時IDの採番)** - -**2.** で読み込まれたデータに対する [実行時ID](../../component/libraries/libraries-01-Log.md#実行時id) を採番し -スレッドコンテキストに保存する。 -実行時IDの採番は、本ハンドラに設定された採番用モジュールによって行う。 - -**4. (後続ハンドラへの処理委譲)** - -**2.** で読み込んだ入力データを引数として、後続ハンドラに処理を委譲しその結果を取得する。 - -**[復路処理]** - -**5. (正常終了)** - -**4.** で取得した結果をそのままリターンし終了する。 - -**[例外処理]** - -**4a. (入力データをログ出力)** - -後続ハンドラの処理中に例外が発生した場合は、入力データの内容と -例外の内容をワーニングレベルでログ出力した後、再送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| データ読み込み件数上限 | maxCount | int | 任意指定(デフォルト = 0:無制限) | -| 実行時ID採番モジュール | executionIdAttribute | ThreadContextAttribute | 任意指定(デフォルト = ExecutionIdAttribute) | - -**基本設定** - -```xml - -``` - -**読み込み回数上限を設定する場合** - -読み込み件数の上限値は運用時に変更される可能性があるため、外部パラメータ化しておくことを推奨する。 - -```xml - - - - -``` - -**実行時IDの採番体系をカスタマイズする場合** - -実行時IDをPJ固有の形式で採番している場合は [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) に設定したものと同じモジュールをこのハンドラにも設定すること。 - -```xml - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DbConnectionManagementHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DbConnectionManagementHandler.md deleted file mode 100644 index 632f84250..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DbConnectionManagementHandler.md +++ /dev/null @@ -1,111 +0,0 @@ -## データベース接続管理ハンドラ - -**クラス名:** `nablarch.common.handler.DbConnectionManagementHandler` - ------ - ------ - -### 概要 - -後続ハンドラの処理で必要となるデータベース接続オブジェクトを、スレッドローカル上で管理するハンドラ。 - -本ハンドラを複数ハンドラキューに配置することで、1スレッドに複数のDB接続を割り当てることができる。 -これは、1スレッド内で複数のトランザクションを制御する場合などに使用する。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| データベース接続管理ハンドラ | nablarch.common.handler.DbConnectionManagementHandler | Object | Object | 業務処理用ＤＢ接続を取得し、スレッドローカル上に保持する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | - | -| トランザクション制御ハンドラ | nablarch.fw.common.handler.TransactionManagementHandler | Object | Object | 業務トランザクションの開始 | トランザクションをコミットする。 | トランザクションをロールバックする。 | 1.コミット完了後 / 2.ロールバック後 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) | このハンドラの後続に配置することで、このハンドラが管理するDB接続を トランザクションに参加させることができる。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (DB接続の獲得)** - -このハンドラに設定されている **DBコネクションファクトリ** を用いて、DB接続を取得する。 - -**2. (スレッドローカルへの登録)** - -**1.** で取得したDB接続を、スレッドローカル変数上のMapに登録する。 -キー名は、本ハンドラに設定された **スレッドローカル登録名** の値を使用する。 - -**2a. (DB接続重複登録エラー)** - -スレッドローカル上に同一の登録名で他のDB接続が既に設定されていた場合は、実行時例外を送出して終了する。 - -**3. (後続ハンドラに対する処理委譲)** - -ハンドラキュー上の後続ハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**4. (終端処理)** - -**2.** で取得したDB接続を開放する。(コネクションプールに返却する。) -また、スレッドローカル上にあるDB接続への参照も除去する。 - -**5. (正常終了)** - -**3.** で取得した処理結果をリターンし終了する。 - -**[例外処理]** - -**3a. (後続ハンドラの処理でエラー)** - -本ハンドラおよび後続ハンドラ内の処理において例外が発生した場合は、 -**4.** の終端処理を行った上で例外を再送出する。 - -**4a. (終端処理中のエラー)** - -終端処理中にエラーが発生した場合、その内容をそのまま再送出し終了する。 -ただし、 **3.** で後続ハンドラの処理中に例外が発生していた場合は、再送出の前にその内容をWARNINGレベルのログで出力しておく。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| DBコネクションファクトリ | connectionFactory | nablarch.core.db.connection .ConnectionFactory | (必須指定) | -| スレッドローカル登録名 | connectionName | String | (任意指定) カレントスレッドが使用するDBコネクションを識別する文字列。 複数のコネクションを利用する場合に指定する。 省略した場合は既定の接続名("transaction")使用する。 | - -**DBコネクションファクトリ** の設定方法については、 -[SQL文実行部品の構造とその使用方法](../../component/libraries/libraries-04-Statement.md) を参照すること。 - -**基本設定** - -デフォルトの設定では、トランザクションが暗黙的に使用する接続名に対して接続オブジェクトを登録する。 -接続名を明示的に指定する場合は、属性dbConnectionNameにその値を設定する。 - -```xml - - - - -``` - -**複数のDB接続を利用する場合** - -本ハンドラを複数使用することでDB接続を複数使用することが可能となる。 -この場合、それぞれの接続は、本ハンドラに設定された **スレッドローカル登録名** によって識別される。 - -```xml - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DuplicateProcessCheckHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DuplicateProcessCheckHandler.md deleted file mode 100644 index 29d7095b9..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-DuplicateProcessCheckHandler.md +++ /dev/null @@ -1,135 +0,0 @@ -## プロセス多重起動防止ハンドラ - -**クラス名:** `nablarch.fw.handler.DuplicateProcessCheckHandler` - ------ - ------ - -### 概要 - -このハンドラでは、DB上のテーブル(プロセス管理テーブル)を参照し、 -同一のリクエストIDを持ったプロセスが実行されていないことを確認する。 -もし、そのようなプロセスが存在していれば、起動処理をエラー終了させる。 - -これにより、運用時の手違いなどによって同一のバッチが複数起動してしまう事態を防止することができる。 - -**プロセス管理テーブルの構造** - -各プロセスの実行状態は、データベース上の **プロセス管理テーブル** 上に格納する。 -このハンドラでは **プロセス管理テーブル** 内の以下のカラムを使用する。 - -| 論理名 | データ型 | 備考 | -|---|---|---| -| リクエストID | VARCHAR PK | プロセスを特定するためのID | -| アクティブフラグ | CHAR(1) | "0": 未実行、"1": 実行中 | - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| スレッドコンテキスト変数設定ハンドラ(メインスレッド) | nablarch.common.handler.ThreadContextHandler_main | Object | Object | 起動引数の内容からリクエストID、ユーザID等のスレッドコンテキスト変数を初期化する。 | - | - | -| プロセス多重起動防止ハンドラ | nablarch.fw.handler.DuplicateProcessCheckHandler | Object | Object | スレッドコンテキスト上のリクエストIDを用いて、リクエスト管理テーブル上の一致するレコードの実行ステータスを参照し、実行中であった場合は例外を送出する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | 本ハンドラではスレッドコンテキスト上に保持されたリクエストIDを使用して 同一プロセスの判定を行う。そのため、必ず [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) を本ハンドラの上位に 設置する必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (リクエストIDの取得)** - -スレッドコンテキストからリクエストIDを取得する。 - -**1a. (多重起動チェック対象外プロセス)** - -取得したリクエストIDが、本ハンドラに設定されたチェック対象外のIDリストに含まれていた場合、 -このハンドラでは何もせず、後続ハンドラに処理を委譲した結果をリターンする。 - -**2. (多重起動チェック)** - -後述の **プロセス管理テーブル** に対して更新処理を行なう。(FW用DB接続を使用) - -リクエストID = (1.で取得したリクエストID) AND 実行中フラグ = "0" (未実行) - -実行中フラグ = "1" (実行中) - -**2a. (多重起動エラー)** - -1. での更新対象が0件であった場合、多重起動と判断し `Result.InternalError` を送出する。(終了コード20) - -**3. (後続ハンドラの実行)** - -ハンドラキュー上の後続のハンドラに処理を委譲する。 - -**[復路処理]** - -**4. (実行中フラグの更新)** - -**プロセス管理テーブル** に対して更新処理を行なう。 - -リクエストID = (1.で取得したリクエストID) AND 実行中フラグ = "1" (実行中) - -実行中フラグ = "0" (未実行) - -**[例外処理]** - -**3a. (実行中フラグの更新)** - -後続ハンドラの処理中に例外が送出された場合でも、必ず実行中フラグを"0"(未実行)に更新する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| プロセス管理テーブル名 | tableName | String | 必須指定 | -| リクエストIDカラム名 | requestIdColumnName | String | 必須指定 | -| アクティブフラグカラム名 | processActiveFlgColumnName | String | 必須指定 | -| DBトランザクションマネージャ | dbTransactionManager | SimpleDbTransactionManager | 必須指定 | -| 多重起動エラー時の終了コード | exitCode | Integer | 任意指定(デフォルト = 127) | -| チェック対象外リクエストID | permitRequestIds | List | 任意指定 | - -**基本設定** - -```xml - - - - - - - - - - -``` - -**任意の設定項目も含めた例** - -```xml - - - - - - - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-FileBatchAction.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-FileBatchAction.md deleted file mode 100644 index ee5dc47bf..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-FileBatchAction.md +++ /dev/null @@ -1,121 +0,0 @@ -## ファイル入力のバッチ業務アクションハンドラのテンプレートクラス - -**クラス名:** `nablarch.fw.action.FileBatchAction` - ------ - -### 概要 - -本クラスは、ファイルを入力とした [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) における -業務アクションハンドラを実装する際に使用できるテンプレートクラスである。 - -基本的な構造は、 [バッチ処理用業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-BatchAction.md) と同じであるが、業務処理は **handler()** メソッドに実装するのでは無く、 -ヘッダー、データ、トレーラーなどのレコード種別ごとに、以下のシグニチャをもつ個別のメソッドに実装することができる。 - -```java -public Result do[レコード種別名](DataRecord record, ExecutionContext context); -``` - -また、本クラスでは、ファイル入力のバッチ実装に特化した以下の機能を簡便に実装することができる。 - -* ファイル内容の事前検証の実行 -* バッチ処理がエラー等の理由で中断した場合の再開機能 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| ファイル入力バッチ処理用業務アクションハンドラ | nablarch.fw.action.FileBatchAction | DataRecord | Result | 設定されたファイル内のデータレコードを入力として業務処理を実行する。 | 処理結果オブジェクトを返す。(通常はResult.Successを返す) | - | - ------ - -本クラスを継承してアクションハンドラを実装するには、以下のテンプレートメソッドを必要に応じて実装する。 - -| メソッド名 | 内容 | -|---|---| -| do[レコード種別名]() | (必須実装) 各レコード種別ごとの業務処理を実行する。 正常に終了した場合は、ハンドラの処理が正常終了したことを表す マーカーオブジェクト([Result.Success](../../javadoc/nablarch/fw/Result.Success.html))をリターンすればよい。 | -| getFormatFileName() | (必須実装) 入力ファイルのファイル名を返す。 | -| getFormatFileName() | (必須実装) レコードフォーマット定義ファイルのファイル名を返す。 | -| getDataFileDirName() | (任意実装) 入力ファイルが格納されたディレクトリの論理パス名を指定する。 デフォルトでは、論理パス名 **"input"** を使用する。 | -| getFormatFileDirName() | (任意実装) フォーマット定義ファイルが格納されたディレクトリの論理パス名を指定する。 デフォルトでは、論理パス名 **"format"** を使用する。 | -| getValidatorAction() | (任意実装) 入力ファイルの事前検証処理を実装したオブジェクト ( [ValidatableFileDataReader.FileValidatorAction](../../javadoc/nablarch/fw/reader/ValidatableFileDataReader.FileValidatorAction.html) )を返す。 デフォルトでは事前検証処理は行われない。 事前検証が必要な場合にオーバーライドすること。 | -| transactionSuccess() | (任意実装) 業務トランザクションのコミットが完了した後でコールバックされる。 デフォルトでは何もしない。 | -| transactionFailure() | (任意実装) 業務トランザクションのロールバック後にコールバックされる。 デフォルトでは何もしない。 | -| initialize() | (任意実装) バッチ処理の開始前に一度だけ呼ばれる。 デフォルトでは何もしない。 | -| error() | (任意実装) 実行時例外/エラーの発生によってバッチがエラー終了した場合に 一度だけコールバックされる。 デフォルトでは何もしない。 | -| terminate() | (任意実装) バッチ処理が全件終了もしくはエラーにより終了した後で 一度だけコールバックされる。 デフォルトでは何もしない。 | - -### ハンドラ処理フロー - -**[コールバック]** - -**1. (バッチ処理開始前初期処理)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) での処理開始時に本クラスの **initialize()** を実行する。 - -**2. (ファイルデータリーダ生成)** - -続いて、 [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) での処理開始時に、以下の手順に沿って作成されたデータリーダを返す。 - -1. 本クラスの **getFormatFileName()** 、 **getFormatFileDirName()** 、 **getDataFileName()** 、 **getDataFileDirName()** - をそれぞれ実行し、その結果をもとに [ファイルデータリーダ](../../component/readers/readers-FileDataReader.md) を作成する。 -2. 本クラスの **getValidatorAction()** を実行し、その結果がnullでなければ、 - [ValidatableFileDataReader](../../javadoc/nablarch/fw/reader/ValidatableFileDataReader.html) を作成し、 **getValidatorAction()** の結果と前段で作成したファイルリーダを設定する。 - -　　3. [ResumeDataReader](../../javadoc/nablarch/fw/reader/ResumeDataReader.html) を作成し、前段までで作成したデータリーダを設定する。 - -**[往路処理]** - -**3. (入力レコードのレコード種別を取得)** - -入力レコードの getRecordType() メソッドを実行し、レコード種別名を取得する。 - -**4. (業務処理の実行)** - -本クラスに実装された、以下のシグニチャのメソッドを呼び出し、その結果を取得する。 - -```java -public Result do[レコード種別名](DataRecord record, ExecutionContext context); -``` - -**[復路処理]** - -**5. (正常終了)** - -**4.** の結果をリターンし、終了する。 - -**[例外処理]** - -**4a. (ディスパッチエラー)** - -本クラスに、該当するメソッドが定義されていなかった場合は、実行時例外( [Result.NotFound](../../javadoc/nablarch/fw/Result.NotFound.html) :ステータスコード404) -を送出する。 - -**4b. (エラー終了)** - -業務処理実行中に例外が送出された場合は、そのまま再送出する。 - -**[コールバック]** - -**6. (業務トランザクション正常終了時の処理)** - -本ハンドラでの処理終了後、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) で業務トランザクションが正常にコミットされた場合、 -本ハンドラの **transactionSuccess()** を実行する。 - -**6a. (業務トランザクションロールバック時の処理)** - -本ハンドラでの処理終了後、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) で業務トランザクションがロールバックされた場合、 -本ハンドラの **transactionFailure()** を実行する。 - -**7. (バッチエラー終了時)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) でバッチ処理実行用のサブスレッドがエラーにより停止した場合、 -本ハンドラの **error()** を実行する。 - -**8. (バッチ終了時)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) でバッチ処理実行用のサブスレッドが終了した場合、 -本ハンドラの **terminate()** を実行する。 -(このコールバックは、バッチがエラー終了した場合でも、 **7.** の処理の後で呼ばれる。) diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-FileRecordWriterDisposeHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-FileRecordWriterDisposeHandler.md deleted file mode 100644 index 14e522e41..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-FileRecordWriterDisposeHandler.md +++ /dev/null @@ -1,69 +0,0 @@ -## 出力ファイル開放ハンドラ - -**クラス名:** `nablarch.common.handler.FileRecordWriterDisposeHandler` - ------ - ------ - ------ - -### 概要 - -業務アクションハンドラで書き込みを行うために開いた全ての出力ファイルを開放（クローズ）するハンドラ。 -後続のハンドラの処理結果に関わらず全ての出力ファイルを解放する。 -本ハンドラを使用する場合、業務アクションハンドラ内で出力ファイルを開放する必要はない。 - -> **Warning:** -> 本ハンドラは、 [FileRecordWriterHolder](../../javadoc/nablarch/common/io/FileRecordWriterHolder.html) クラス経由で書き込みが行われた出力ファイルのみ開放する。 - -> [FileRecordWriterHolder](../../javadoc/nablarch/common/io/FileRecordWriterHolder.html) 以外のクラスを使用して書き込んだ出力ファイルは、開放の対象外となるので注意すること。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| 出力ファイル開放ハンドラ | nablarch.common.handler.FileRecordWriterDisposeHandler | Object | Object | - | 業務アクションハンドラで書き込みを行うために開いた全ての出力ファイルを開放する | - | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (後続ハンドラに対する処理委譲)** - -後続のハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**2. (出力ファイルの開放)** - -[FileRecordWriterHolder](../../javadoc/nablarch/common/io/FileRecordWriterHolder.html) によって書き込みを行った全てのファイルの開放処理を行う。 - -**2a. (開放処理中のエラー)** - -なお、開放処理中にIOエラーが発生した場合は、ワーニングログのみ出力し、再送出は行なわない。 -それ以外のエラーが発生した場合は再送出して終了する。 - -**3. (正常終了)** - -**1.** で取得した処理結果を返却して終了する。 - -**[例外処理]** - -**1a. (後続ハンドラの処理でエラー)** - -後続ハンドラの処理中にエラーが発生した場合、 **2. (出力ファイルの開放)** を行った後、 -発生した元例外を再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの実装内容は基本的に変更不要なものであり、そのまま使用することができる。 -以下はDIリポジトリ設定ファイルへの記述例である。 - -```xml - -``` - -### 未実装機能・要望 - -(とくになし。) diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ForwardingHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ForwardingHandler.md deleted file mode 100644 index 6bebfbf37..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ForwardingHandler.md +++ /dev/null @@ -1,104 +0,0 @@ -## 内部フォーワードハンドラ - -**クラス名:** `nablarch.fw.handler.ForwardingHandler` - ------ - ------ - -### 概要 - -このハンドラでは、後続ハンドラでの処理結果のHTTPレスポンスオブジェクト中のコンテンツパスが、 -**forward://** で始まる書式であった場合に、指定されたリクエストパスで後続ハンドラの処理を再実行する。 - -これは、 **内部フォーワード** と呼ばれる処理で、遷移先の画面が単純な画面表示では無く、 -業務アクションでの処理を伴う場合などに用いられる。 - -なお、内部フォーワード後は [リクエストオブジェクト](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) 中のリクエストパスの値は -フォーワード先のパスに書き換えられる。 -一方、スレッドコンテキスト中のリクエストIDの値はフォーワード後も同じ値である。 - -フォーワード先のリクエストパスに対するリクエストIDは、同じスレッドコンテキスト中の -[内部リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#特殊なリクエスト処理) から参照できる。 - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [開閉局制御ハンドラ](../../component/handlers/handlers-ServiceAvailabilityCheckHandler.md) 、 [認可制御ハンドラ](../../component/handlers/handlers-PermissionCheckHandler.md) | これらのハンドラが行う開閉局チェック、認可チェック処理は フォーワード後のリクエストIDで実施する必要があるので、 本ハンドラはこれらのハンドラの上位に配置する必要がある。 | - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| 内部フォーワードハンドラ | nablarch.fw.web.handler.ForwardingHandler | HttpRequest | HttpResponse | - | 遷移先に内部フォーワードパスが指定されていた場合、HTTPリクエストオブジェクトのリクエストURIを内部フォーワードパスに書き換えた後、後続のハンドラを再実行する。 | - | -| 開閉局制御ハンドラ | nablarch.fw.common.handler.ServiceAvailabilityCheckHandler | Request | Result | リクエストＩＤ単位での開閉局制御を行う | - | - | -| 認可制御ハンドラ | nablarch.fw.common.handler.PermissionCheckHandler | Object | Object | スレッドコンテキスト上の userId/requestId をもとに認可判定を行う。認可判定に失敗した場合は例外を送出して終了する。成功した場合は、認可情報オブジェクトをスレッドローカルに設定する。 | - | - | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (ハンドラキュー構成のスナップショットを作成)** - -このハンドラの処理開始時点でのハンドラキュー構成のシャローコピーを作成する。 - -**2. (後続ハンドラの処理を実行)** - -ハンドラキュー上の後続ハンドラに処理を委譲し、その結果オブジェクトとなるHTTPレスポンスオブジェクトを取得する。 - -**[復路処理]** - -**3. (コンテンツパスの取得)** - -HTTPレスポンスオブジェクトに設定されたコンテンツパス文字列を取得する。 - -**3a. (正常終了)** - -コンテンツパス文字列が **forward://** で始まる文字列で無い場合、本ハンドラでは何もせずに、 -**2.** で取得した処理結果をリターンして終了する。 - -**3b. (内部フォーワード処理)** - -コンテンツパス文字列が **forward://** で始まる場合、パス部分をフォーワード先パスとして取得する。 - -**(書式)** - -**forward://(フォーワード先リクエストパス)** - -* 相対パス指定の場合: 現在のリクエストURIを起点とするパス。 -* 絶対パス指定の場合: サーブレットコンテキスト名を起点とするパス。 - -```bash -# 現在のリクエストURIが "/app/user/success.html" とすると、以下はどちらも等価な表現となる。 -forward://registerForm.html # 相対パス指定 -forward:///app/user/registerForm.html # 絶対パス指定 -``` - -以下の処理を行う。 - -1. フォーワード先リクエストパスを **HttpRequest** オブジェクトのリクエストパスに設定する。 -2. フォーワード先リクエストパスから取得したリクエストIDをスレッドコンテキスト上の [内部リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#特殊なリクエスト処理) - に設定する。 -3. 実行コンテキスト上のハンドラキューの内容を **1.** で作成したコピーに差し替えたうえで、 - 後続のハンドラに対して再度処理を委譲し、その処理結果となるHTTPレスポンスオブジェクトを取得する。 -4. 初回のレスポンスのステータスコードと、 **2.** で得られたレスポンスのステータスコードを比較し、 - 前者の方が大きい場合は、 **2.** で得られたレスポンスにその値を設定する。 -5. **2.** で得られたレスポンスをリターンするして終了する。 - -**[例外処理]** - -**2a. (後続ハンドラ処理中のエラー)** - -後続ハンドラ処理中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラに設定項目はなく、そのまま使用することができる。 - -```xml - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-GlobalErrorHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-GlobalErrorHandler.md deleted file mode 100644 index b423ce374..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-GlobalErrorHandler.md +++ /dev/null @@ -1,69 +0,0 @@ -## グローバルエラーハンドラ - -**クラス名:** `nablarch.fw.handler.GlobalErrorHandler` - ------ - ------ - -### 概要 - -[グローバルエラーハンドラ](../../component/handlers/handlers-GlobalErrorHandler.md) は、ハンドラキュー上のどのハンドラでも捕捉されなかった -全ての実行時例外・エラーを捕捉し、運用ログを含むログ出力を行なう。 - -このハンドラでは、致命的な一部の例外を除いて、捕捉した例外を -処理結果オブジェクト([Result](../../javadoc/nablarch/fw/Result.html) )に変換して返す。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| グローバルエラーハンドラ | nablarch.fw.handler.GlobalErrorHandler | Object | Result | - | - | 全ての実行時例外・エラーを捕捉し、ログ出力を行う | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (後続ハンドラへの処理委譲)** - -往路では何もせずに後続のハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**2. (正常終了)** - -**1.** で取得した結果をそのままリターンし終了する。 - -**[例外処理]** - -**2a. (例外制御)** - -後続ハンドラの処理中に実行時例外もしくはエラーが送出された場合は以下の表に従い例外処理を行う。 -基本的には発生したエラーをログに出力し、エラーの内容を格納した [Result](../../javadoc/nablarch/fw/Result.html) オブジェクトをリターンする。 -ただし、プロセスの継続に影響するような致命的なエラーが発生した場合のみ例外を再送出する。 - -| 捕捉した例外クラス | 障害ログ出力 [1] | ログレベル | 処理結果 | 備考 | -|---|---|---|---|---| -| java.lang.ThreadDeath | なし | Info | 捕捉した例外 を再送出 | 外部からスレッド停止APIが呼ばれた場合に発生する。 通常運用で発生しうるため、Infoレベルのログを出力し、 再送出する。 | -| java.lang.InternalError | なし | Fatal | 捕捉した例外 を再送出 | VMの内部動作に起因するエラーが発生した場合に送出される。 | -| java.lang.UnknownError | なし | Fatal | 捕捉した例外 を再送出 | | -| java.lang.StackOverflowError | なし | Fatal | Result. InternalError を返す。 | アプリケーションロジックの問題(無限ループ等)である 可能性が高いのでFatalログを出力し、再送出はしない。 | -| java.lang.OutOfMemoryError | なし | Fatal | Result. InternalError を返す。 | リソースを浪費しているリクエストスレッドが終了することで 復旧する可能性があるため、Fatalログを出力し再送出はしない。 なお、ログ出力の際には失敗する可能性があるので、 ログ出力前に標準エラー出力に最小限のメッセージを出力する。 | -| java.lang.VirtualMachineError (OutOfMemoryError /StackOverFlowErrorを除く) | なし | Fatal | 捕捉した例外 を再送出 | | -| nablarch.fw.launcher.ProcessAbnormalEnd | あり | Fatal | 捕捉した例外 を再送出 | 駐起動バッチ等で、アプリケーション側からプロセス停止を 要求する場合に送出される。 | -| nablarch.fw.Result.ServiceError | あり | Fatal/Warn | 捕捉した例外 を返す。 | アプリケーション側から障害ログの出力が要求された場合に 送出される。 | -| nablarch.fw.Result.Error | なし | Fatal | 捕捉した例外 を返す。 | | -| (上記以外の実行時例外/エラー) | なし | Fatal | Result. InternalError を返す。 | | - -運用ログに障害内容とメッセージを出力する。 - -### 設定項目・拡張ポイント - -本ハンドラの実装内容は基本的に変更不要なものであり、そのまま使用することができる。 -以下は設定ファイルの記述例である。 - -```xml - -``` - -プロジェクト固有の要件により、例外処理を変更したい場合は、本ハンドラ自体を別実装したものに差し替えること。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpAccessLogHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpAccessLogHandler.md deleted file mode 100644 index 4a83da012..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpAccessLogHandler.md +++ /dev/null @@ -1,82 +0,0 @@ -## HTTPアクセスログハンドラ - -**クラス名:** `nablarch.fw.web.handler.HttpAccessLogHandler` - ------ - ------ - -### 概要 - -このハンドラでは、往路と復路で、それぞれリクエストとレスポンスに関するHTTPアクセスログを出力する。 - -出力されるアクセスログの詳細や、出力形式の設定については、 [HTTPアクセスログの出力](../../component/libraries/libraries-04-HttpAccessLog.md) を参照すること。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| スレッドコンテキスト変数設定ハンドラ(リクエストスレッド) | nablarch.common.handler.ThreadContextHandler_request | Object | Object | 前のループで設定されたスレッドコンテキスト変数をクリアするためここで再初期化する。 | - | - | -| HTTPアクセスログハンドラ | nablarch.fw.web.handler.HttpAccessLogHandler | HttpRequest | HttpResponse | HTTPリクエストの内容についてログに出力する。 | 送信するHTTPレスポンスの内容についてログに出力する。 | 送信するHTTPレスポンスの内容についてログに出力する。 | -| HTTPエラー制御ハンドラ | nablarch.fw.web.handler.HttpErrorHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容が設定されていない場合は、ステータスコードに応じたデフォルトページを遷移先に設定する。 | 送出されたエラーに応じた遷移先のHTTPレスポンスオブジェクトを返却する。送出されたエラーはリクエストスコープに設定される。 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | 本ハンドラがログに出力する項目には、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) が設定する項目が含まれるため、 本ハンドラより上位に配置する必要がある。 | -| [HTTPエラー制御ハンドラ](../../component/handlers/handlers-HttpErrorHandler.md) | HTTPエラーレスポンス以外の例外は [HTTPエラー制御ハンドラ](../../component/handlers/handlers-HttpErrorHandler.md) によって HTTPレスポンスオブジェクトに変換されるので 本ハンドラの後続に配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路での処理]** - -**1. (HTTPリクエストログの出力)** - -引数となるHTTPリクエストオブジェクトおよび実行コンテキストの内容をもとに、HTTPアクセスログを出力する。 -**(ログレベル: INFO、 ログカテゴリ: HTTP_ACCESS)** - -**2. (後続ハンドラへの処理委譲)** - -後続ハンドラに処理を委譲し、その結果としてHTTPレスポンスオブジェクトを取得する。 - -**[復路での処理]** - -**3. (HTTPレスポンスログの出力)** - -HTTPリクエストオブジェクトおよび実行コンテキストに加え、後続ハンドラの処理結果であるHTTPレスポンスオブジェクトの内容をもとに、 -HTTPアクセスログを出力する。 -**(ログレベル: INFO、 ログカテゴリ: HTTP_ACCESS)** - -**4. (正常終了)** - -HTTPレスポンスオブジェクトをリターンして終了する。 - -**[例外処理]** - -**2a. (HTTPエラーレスポンスに対するログ出力)** - -後続ハンドラの処理中に、HTTPエラーレスポンスが送出された場合、そのエラーレスポンスの内容と、 -HTTPリクエスト、実行コンテキストの内容をもとにHTTPアクセスログを出力した上で、捕捉した例外を再送出する。 - -**2b. (HTTPエラーレスポンス以外のエラーに対するログ出力)** - -後続ハンドラの処理中に、HTTPエラーレスポンス以外の例外が送出された場合は -HTTPリクエスト、実行コンテキストの内容をもとにHTTPアクセスログを出力した上で、例外を再送出する。 - -### 設定項目・拡張ポイント - -本ハンドラ自体に設定項目は存在しない。 -ロガー側の設定については、 [HTTPアクセスログの出力](../../component/libraries/libraries-04-HttpAccessLog.md) を参照すること。 - -**標準設定** - -以下はDI設定の記述例である。 - -```xml - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpCharacterEncodingHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpCharacterEncodingHandler.md deleted file mode 100644 index d26c89b80..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpCharacterEncodingHandler.md +++ /dev/null @@ -1,122 +0,0 @@ -## HTTP文字エンコード制御ハンドラ - -**クラス名:** `nablarch.fw.web.handler.HttpCharacterEncodingHandler` - ------ - ------ - -### 概要 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTP文字エンコード制御ハンドラ | nablarch.fw.web.handler.HttpCharacterEncodingHandler | Object | Object | HttpServletRequestおよびHttpServletResponseに対し文字エンコーディングを設定する。 | - | - | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (既定の文字エンコーディングの設定)** - -`HttpServletRequest` および `HttpServletResponse` に対し既定の文字エンコーディングを設定する。 - -**2. (後続ハンドラに対する処理委譲)** - -ハンドラキュー上の後続ハンドラに対して処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**3. (正常終了)** - -**2.** の結果をリターンして終了する。 - -**[例外処理]** - -**2a. (エラー終了)** - -後続ハンドラの処理中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 既定の文字エンコーディング | defaultEncoding | String | 任意指定(デフォルト値="UTF-8") | - -**標準設定** - -以下は標準設定におけるDI設定の例である。 - -```xml - -``` - -**任意の設定項目も含めた例** - -```xml - - - - -``` - -**拡張例** - -リクエスト毎に動的に使用する文字エンコーディングが変わる場合は本ハンドラを継承したハンドラを作成し、本ハンドラの代わりに設定する。 -継承時に拡張可能なメソッドを以下に示す。 - -| 拡張可能なメソッド | 引数 | 戻り値 | 処理内容 | -|---|---|---|---| -| resolveRequestEncoding | HttpServletRequest | Charset | HTTP リクエストに設定する文字エンコードを返却する。 | -| resolveResponseEncoding | HttpServletRequest | Charset | HTTP レスポンスに設定する文字エンコードを返却する。 | - -以下はリクエスト URI 毎に文字エンコーディングを変更する例である。 - -*拡張ハンドラの実装例* - -```java -public class CustomHttpCharacterEncodingHandler extends - HttpCharacterEncodingHandler { - - @Override - protected Charset resolveRequestEncoding(HttpServletRequest req) { - return resolveCharacterEncoding(req); - } - - @Override - protected Charset resolveResponseEncoding(HttpServletRequest req) { - return resolveCharacterEncoding(req); - } - - /** - * 文字エンコードを解決する。
- * 
-     * URI に "/RW99ZZ06" が含まれていた場合は文字エンコーディングを "Windows-31J" とする。
-     * それ以外の場合はデフォルトの文字エンコードとする。
-     *
- * - * @param req リクエスト - * @return 文字エンコード - */ - private Charset resolveCharacterEncoding(HttpServletRequest req) { - if (req.getRequestURI().contains("/RW99ZZ06")) { - return Charset.forName("Windows-31J"); - } - return getDefaultEncoding(); - } - -} -``` - -*DIの設定例* - -```xml - -``` - -> **Warning:** -> `resolveRequestEncoding`, `resolveResponseEncoding` の引数として `HttpServletRequest` が渡されるが、 -> `HttpServletRequest` からリクエストパラメータを取得してはならない。 -> 文字エンコードを設定する前に``HttpServletRequest`` からリクエストパラメータを取得してしまった場合は -> 文字エンコードの設定ができないので文字化けの原因となる。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpErrorHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpErrorHandler.md deleted file mode 100644 index 0f4ef152d..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpErrorHandler.md +++ /dev/null @@ -1,137 +0,0 @@ -## HTTPエラー制御ハンドラ - -**クラス名:** `nablarch.fw.handler.HttpErrorHandler` - ------ - ------ - -### 概要 - -本ハンドラでは、後続ハンドラの処理中に送出された例外を捕捉し、 -障害ログを出力した後、HTTPエラーレスポンスオブジェクトを作成して返す。 - -また、後続ハンドラの処理が正常終了し、その処理結果に遷移先画面か応答内容のどちらもも設定されていない場合は、 -既定のエラー画面を遷移先として指定する。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTPレスポンスハンドラ | nablarch.fw.web.handler.HttpResponseHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容に沿ってレスポンス処理かサーブレットフォーワードのいずれかを行う。 | 既定のエラー画面をレスポンス後、例外を再送出する。ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 | -| HTTPエラー制御ハンドラ | nablarch.fw.web.handler.HttpErrorHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容が設定されていない場合は、ステータスコードに応じたデフォルトページを遷移先に設定する。 | 送出されたエラーに応じた遷移先のHTTPレスポンスオブジェクトを返却する。送出されたエラーはリクエストスコープに設定される。 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) | 本ハンドラでは捕捉した例外に対するHTTPレスポンスオブジェクトを作成するものの、 レスポンス処理自体は [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) 側で行われるため、 このハンドラを本ハンドラの上位に配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (後続ハンドラへの処理委譲)** - -往路では本ハンドラは特段の処理を行なわない。 -引数をそのまま後続ハンドラに渡して処理を委譲し、その結果としてHTTPレスポンスオブジェクトを取得する。 - -**[復路処理]** - -**2. (レスポンスボディ内容の確認)** - -HTTPレスポンスオブジェクトにレスポンスボディとして出力する内容が設定されているかどうかを確認する。 -以下の条件のいずれかが満たされていれば、 HTTPレスポンスオブジェクトを返却し、処理を終了する。 - -1. コンテンツパスが設定されている。 -2. `HttpResponse#setInputStream()` により、レスポンスボディとして出力する内容が `InputStream` で与えられている。 -3. `HttpResponse#write()` により、レスポンスボディとして出力する内容がHTTPレスポンスオブジェクト内にバッファリングされている。 - -**2a. (ステータスコード毎のデフォルトページを設定)** - -HTTPレスポンスオブジェクトにレスポンスボディとして出力する内容が設定されていなかった場合は、 -`HttpResponse#getStatusCode()` の値に合致するデフォルトページへのコンテンツパスを設定してリターンする。 -デフォルトページは本ハンドラの設定で任意のコンテンツパスを指定することができる。 -設定を行なっていない場合のデフォルトページは次のようになる。 - -| ステータスコード | コンテンツパス | -|---|---| -| 404 | servlet:///jsp/notFound.jsp | -| 401 | servlet:///jsp/unauthorized.jsp | -| 3.. (300～399のいずれか) | servlet:///jsp/redirecting.jsp | -| 4.. (400～499 ただし 401/404を除く) | servlet:///jsp/userError.jsp | -| 5.. (500～599のいずれか) | servlet:///jsp/systemError.jsp | - -**[例外処理]** - -**1.a (後続ハンドラ処理中のエラー)** - -後続ハンドラ実行中に例外が送出された場合、その型に従って以下のように処理する。 -なお、いずれの場合でも、送出された例外をリクエストコンテキストにキー名 **nablarch_error** で設定する。 - -| 捕捉した例外クラス | ログ出力 | 処理内容 | -|---|---|---| -| nablarch.fw.NoMoreHandlerException | Info | ハンドラキューが空の状態で、後続ハンドラに処理委譲を行なった場合に送出される。 ステータスコード404のデフォルトページを設定したHTTPレスポンスオブジェクトを返却する。 | -| nablarch.fw.web.HttpErrorResponse | なし | エラーレスポンス内容を指定し、エラー終了する際に送出するエラー。 この例外に指定されているHTTPレスポンスオブジェクトを返却する。 | -| nablarch.fw.Result.Error | なし | 例外オブジェクトのステータスコードに対応するデフォルトページを遷移先とする HTTPレスポンスオブジェクトを返却する。 > **Note:** > writeFailureLogPatternプロパティで指定された正規表現にマッチするステータスコードを > もつErrorオブジェクトの場合には、障害ログを出力する。 | -| java.lang.StackOverflowError | Fatal | ステータスコード500のデフォルトページを設定したHTTPレスポンスオブジェクトを返却する。 | -| java.lang.ThreadDeath | なし | 本ハンドラでは何もせずに捕捉した例外を再送出する。 (ログ出力は [グローバルエラーハンドラ](../../component/handlers/handlers-GlobalErrorHandler.md) で行われる。) | -| java.lang.VirtualMachineError (StackOverFlowErrorを除く) | なし | 本ハンドラでは何もせずに捕捉した例外を再送出する。 (ログ出力は [グローバルエラーハンドラ](../../component/handlers/handlers-GlobalErrorHandler.md) で行われる。) | -| (上記以外の実行時例外、エラー) | Fatal | ステータスコード500のデフォルトページを設定したHTTPレスポンスオブジェクトを返却する。 | - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| ステータスコード毎のデフォルト遷移先 | defaultPages | Map | 任意指定 (デフォルト設定はハンドラ処理フロー参照) | -| Result.Error発生時の障害通知ログ出力対象のステータスコード | writeFailureLogPattern | String | 任意指定 指定する場合は、正規表現で指定する。 例えば、全てのステータスコードで障害通知ログを 出力する場合には、 *「.*」* と指定する。 設定を省略した場合は、500～599(503(サービス閉塞中) を除く)が、障害通知ログの出力対象となる。 | - -**標準設定** - -以下は標準設定におけるDI設定の例である。 - -```xml - - -``` - -**ステータスコード毎のデフォルト遷移先を設定する場合** - -以下のように設定することで、デフォルトの遷移先を変更することができる。 -対象となるステータスコードに **"."** を含めることで、ワイルドカード指定することができる。 -ただし、1つのステータスコードに対して複数の遷移先がマッチする場合は、 -ワイルドカードの使用桁がより少ない遷移先を優先する。 - -たとえば、以下の例では、ステータスコード404に対応するデフォルト遷移先は、 -`"/USER_ERROR.jsp"` ではなく、 `"/NOT_FOUND.jsp"` となる。 - -```xml - - - - - - - - - - - - -``` - -**Result.Error発生時に障害通知ログを出力するステータスコード値を変更する場合** - -以下のように設定することで、障害通知ログを出力するステータスコード値を変更することができる。 - -```xml - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpMethodBinding.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpMethodBinding.md deleted file mode 100644 index e6232161b..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpMethodBinding.md +++ /dev/null @@ -1,448 +0,0 @@ -## 画面オンライン処理用業務アクションハンドラ - -**クラス名:** `nablarch.fw.web.HttpMethodBinding` - ------ - -### 概要 - -本稿では、 [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) における、標準的な業務アクションハンドラの実装方法について述べる。 - -また、必要に応じて、以下の各項を参照すること。 - -**レスポンス時にファイル等のダウンロードを行う場合** - -* [ファイルダウンロード](../../component/libraries/libraries-05-FileDownload.md) - -**ファイルアップロードを伴う業務処理を実装する場合** - -* [ファイルアップロード業務処理用ユーティリティ](../../component/libraries/libraries-file-upload-utility.md) - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| HTTPレスポンスハンドラ | nablarch.fw.web.handler.HttpResponseHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容に沿ってレスポンス処理かサーブレットフォーワードのいずれかを行う。 | 既定のエラー画面をレスポンス後、例外を再送出する。ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 | - | -| HTTPエラー制御ハンドラ | nablarch.fw.web.handler.HttpErrorHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容が設定されていない場合は、ステータスコードに応じたデフォルトページを遷移先に設定する。 | 送出されたエラーに応じた遷移先のHTTPレスポンスオブジェクトを返却する。送出されたエラーはリクエストスコープに設定される。 | - | -| トランザクション制御ハンドラ | nablarch.fw.common.handler.TransactionManagementHandler | Object | Object | 業務トランザクションの開始 | トランザクションをコミットする。 | トランザクションをロールバックする。 | 1.コミット完了後 / 2.ロールバック後 | -| 画面オンライン処理業務アクション | nablarch.fw.action.HttpMethodBinding | HttpRequest | HttpResponse | HTTPリクエストの内容をもとに業務処理を実行する | 遷移先画面に表示する内容をリクエストコンテキストに設定した上で、遷移先パスを設定したHTTPレスポンスオブジェクトを返却する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) | 業務アクションが返却もしくは送出したHTTPレスポンスオブジェクトをもとに レスポンス処理を行う。 | -| [HTTPエラー制御ハンドラ](../../component/handlers/handlers-HttpErrorHandler.md) | 業務アクションが送出した実行時例外は、ここで捕捉され、 対応するエラー遷移先を表すHTTPレスポンスオブジェクトに変換される。 | -| [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) | 業務アクションが実行時例外を送出することで、業務トランザクションをロールバックする。 | - -### 業務アクションハンドラの実装内容 - -次のコードは、ログイン処理を行う業務アクションハンドラの例である。 -以下では、このソースコードに沿って解説する。 - -```java -public class LoginAction { - - // ① ビジネスメソッドのディスパッチ - public HttpResponse getLoginHtml(HttpRequest request, ExecutionContext context) { - // ② ビジネスロジックの実行とHTTPレスポンスオブジェクトの返却 - context.invalidateSession(); - return new HttpResponse("./login.jsp"); - } - - public HttpResponse doLogin(HttpRequest request, ExecutionContext context) { - try { - authenticate(request, context); - return new HttpResponse("forward:///app/MainMenu"); - - // ③ 例外制御 - } catch(AuthenticationFailedException e) { - throw new HttpErrorResponse(403, "forward://login.html", e); - } - } -} -``` - -**① ビジネスメソッドのディスパッチ** - -[画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) の業務アクションハンドラでは -[Handler](../../javadoc/nablarch/fw/Handler.html) インターフェースを実装する必要は無く、HTTPリクエストの内容に従い、動的にメソッドが呼び分けられる。 - -1. メソッドの戻り値の型がHttpResponseかつ、引数を2つもち、 - それぞれの型がHttpRequest、ExecutionContextであること。 -2. メソッドの名前が次の文字列に一致する。: - - ``` - (リクエストのHTTPメソッド名 もしくは "do") + (リクエストURIのリソース名) - ``` - -ただし、一致判定は以下の条件のもとで行われる。 - -* メソッド名の大文字小文字は区別しない。 -* リクエストURIのリソース名に含まれる"."は無視される。 -* 委譲先クラスのメソッド名に含まれる"_"は無視される。 - -**例** - -| HTTPリクエスト | 委譲対象となるメソッドシグニチャの例 | -|---|---| -| GET /app/index.html | HttpResponse getIndexHtml (HttpRequest, ExecutionContext); HttpResponse getIndexhtml (HttpRequest, ExecutionContext); HttpResponse get_index_html(HttpRequest, ExecutionContext); HttpResponse do_index_html (HttpRequest, ExecutionContext); HttpResponse doIndexHtml (HttpRequest, ExecutionContext); | -| POST /app/message | HttpResponse postMessage(HttpRequest, ExecutionContext); HttpResponse doMessage (HttpRequest, ExecutionContext); HttpResponse do_message (HttpRequest, ExecutionContext); | - -これらの条件に該当するメソッドが存在しなかった場合は -ステータスコード404の [HttpErrorResponse](../../javadoc/nablarch/fw/web/HttpErrorResponse.html) が送出される。 - -**② ビジネスロジックの実行とHTTPレスポンスオブジェクトの返却** - -呼び出された各メソッドでは、おおまかに以下のような処理を行う。 - -1. ビジネスロジックを実行する。 -2. JSP側などの後続処理で参照する情報を、各種スコープに設定する。 -3. 遷移先を指定するコンテンツパスが設定された [HttpResponse](../../javadoc/nablarch/fw/web/HttpResponse.html) オブジェクトを返却。 - -クライアントに送信するレスポンスボディの内容を指定する方法は大きく2つある。 - -1つめは、 [HttpResponse](../../javadoc/nablarch/fw/web/HttpResponse.html) オブジェクトに直接レスポンスボディの内容を設定する方法であり、 -主に [ファイルダウンロード](../../component/libraries/libraries-05-FileDownload.md) 処理で使用する。 - -もう1つは、 [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) と呼ばれる文字列によってレスポンス内容を指定する方法であり、 -通常の業務機能の実装ではこちらを主に使用する。 - -**コンテンツパス** - -コンテンツパスとは、クライアントにレスポンスする内容を指定するために、 [HttpResponse](../../javadoc/nablarch/fw/web/HttpResponse.html) オブジェクトに設定する文字列であり、 -以下のリソースをレスポンスの対象とすることができる。 - -* サーブレットフォーワードパス -* 内部フォーワードパス -* HTTPリダイレクション -* ファイルシステム上のリソース -* Javaクラスパス上のリソース - -**コンテンツパスの書式** - -**1. サーブレットフォーワード** - -指定されたパスに対するサーブレットフォーワードを行う。 -クライアントに対するレスポンス処理はフォーワード先のサーブレットで行われる。 -主に、業務処理実行後のJSP画面の表示の際に使用する。 - -**(書式)** - -**servlet://(フォーワードパス)** - -* 相対パス指定の場合: 現在のリクエストURIを起点とするパス。 -* 絶対パス指定の場合: サーブレットコンテキストを起点とするパス。 - -```bash -servlet://index.jsp # 相対パス指定 -servlet:///appContext/jsp/index.jsp # 絶対パス指定 -``` - -> **Note:** -> サーブレットフォーワードでは、指定されたサーブレットを実行するのみであり、ハンドラキュー上の処理は再実行しない。 -> これは、 [Webフロントコントローラ (サーブレットフィルタ)](../../component/handlers/handlers-WebFrontController.md) が全リクエストを対象としたサーブレットフィルタとして実装されており、 -> サーブレットフォーワードで再度処理した場合、無限ループしてしまうためである。 - -> ハンドラキューの内容も含めたフォワード処理が必要な場合は、 [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) による -> 内部フォーワードを使用すること。 - -**2. 内部フォーワード** - -指定されたリクエストパスを使用して、ハンドラキューの処理を再実行する。 -遷移先の画面が単純な画面表示では無く、業務アクションでの処理を伴う場合などに用いられる。 - -**(書式)** - -**forward://(フォーワード先リクエストパス)** - -* 相対パス指定の場合: 現在のリクエストURIを起点とするパス。 -* 絶対パス指定の場合: サーブレットコンテキスト名を起点とするパス。 - -```bash -# 現在のリクエストURIが "/app/user/success.html" とすると、以下はどちらも等価な表現となる。 -forward://registerForm.html # 相対パス指定 -forward:///app/user/registerForm.html # 絶対パス指定 -``` - -> **Note:** -> 内部フォーワード処理の詳細は [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) を参照すること。 - -**3. HTTPリダイレクション** - -クライアントに対して指定されたパスへのリダイレクションを指示するレスポンスを行う。 - -スキーム名を **redirect://** とした場合はサーブレットコンテキスト配下に対するリダイレクションを行う。 -特に、絶対パス指定はサーブレットコンテキストルートからの相対パスとみなされる。 - -スキーム名を **http://** とした場合は、サーブレットコンテキスト外へのリダイレクションが可能であり、 -ホスト名を含めた完全なURLを指定することができる。 - -**(書式)** - -**redirect://(リダイレクト先パス)** - -**http(s)://(リダイレクト先URL)** - -```bash -redirect://login # 現在のページからの相対パス -redirect:///UserAction/login # サーブレットコンテキストを起点とする相対パス -http://www.example.com/login # 外部サイトのURL -``` - -**4. ファイルシステム上のリソース** - -ファイルシステム上の静的ファイルの内容を出力する。 - -**(書式)** - -**file://(ファイルシステムパス)** - -* 相対パス指定の場合: JVMプロセスのワーキングディレクトリが起点とするパス。 -* 絶対パス指定の場合: ファイルシステムのルートディレクトリが起点とするパス。 - -```bash -file://webapps/style/common.css #相対パス指定 -file:///www/docroot/style/common.css #絶対パス指定 -``` - -**5. Javaコンテキストクラスローダ上のリソース** - -コンテキストクラスローダ上のリソースの内容を出力する。 - -**(書式)** - -**classpath://(Javaリソース名)** - -Javaリソース名の完全修飾名を"/"区切りで指定する。 -相対パスと絶対パスの区別は無くどちらを使用しても同じ結果となる。 - -```bash -# 以下はどちらも等価な表現となる。 -classpath://nablarch/sample/webapp/common.css -classpath:///nablarch/sample/webapp/common.css -``` - -**③ 例外制御** - -先に述べたように、HttpErrorResponse 以外の実行時例外が送出された場合、 -デフォルトではHTTPステータス500のレスポンスが返る。 - -それ以外の応答を行うためには、リクエストハンドラ内で明示的に例外を捕捉したうえで -HttpResposeオブジェクトを生成して正常終了させるか、もしくは -HttpErrorResponseでラップして再送出する必要がある。 - -以下の例では、ユーザ入力値の不正による業務例外(ApplicationException)が発生した場合に -HttpErrorResponseを送出し入力画面へ内部フォーワードしている。 - -```java -public HttpResponse handle(HttpRequest req, ExecutionContext ctx) { - try { - UserForm form = validateUser(req); - registerUser(form); - return new HttpResponse(200, "servlet://registrationCompleted.jsp"); - - } catch(ApplicationException ae) { - throw new HttpErrorResponse(400, "forward://registerForm.html", ae); - } -} -``` - -この例外制御は本フレームワークが提供する [@OnError](../../javadoc/nablarch/fw/web/interceptor/OnError.html) アノテーション -を使用することで次のように簡略化することができる。 - -```java -@OnError( - type = ApplicationException.class - , path ="forward://registerForm.html" -) -public HttpResponse handle(HttpRequest req, ExecutionContext ctx) { - UserForm form = validateUser(req); - registerUser(form); - return new HttpResponse(200, "servlet://registrationCompleted.jsp"); -} -``` - -さらに、複数の [@OnError](../../javadoc/nablarch/fw/web/interceptor/OnError.html) アノテーションを指定したい場合は、本フレームワークが提供する -[@OnErrors](../../javadoc/nablarch/fw/web/interceptor/OnErrors.html) アノテーションを使用することで次のように簡略化することができる。 - -```java -// 複数のOnErrorは配列で指定するため、"{}"の記述が必要となる。 -@OnErrors({ - @OnError(type = OptimisticLockException.class, path ="forward://searchForm.html"), - @OnError(type = ApplicationException.class, path ="forward://updatingForm.html") -}) -public HttpResponse handle(HttpRequest req, ExecutionContext ctx) { - UserForm form = validateUser(req); - updateUser(form); - return new HttpResponse(200, "servlet://updatingCompleted.jsp"); -} -``` - -[@OnErrors](../../javadoc/nablarch/fw/web/interceptor/OnErrors.html) アノテーションは、 [@OnError](../../javadoc/nablarch/fw/web/interceptor/OnError.html) アノテーションの定義順(上から順)に例外を処理する。 -たとえば、上記の例では、OptimisticLockExceptionはApplicationExceptionのサブクラスなので、 -必ずApplicationExceptionの上に定義しなければ正常に処理が行われない。 - -```java -// 【誤った実装例】 -// 下記の定義順では、OptimisticLockExceptionが送出された場合にも -// ApplicationExceptionに対する例外処理が行われる。 -@OnErrors ({ - @OnError (type = ApplicationException.class, path ="servlet://updatingForm.jsp"), - @OnError (type = OptimisticLockException.class, path ="servlet://searchForm.jsp") -}) -``` - -**インターセプタの実行順** - -インターセプタの実行順は、設定ファイルに定義した順となる。 -設定ファイルには、 `list` コンポーネントとしてアノテーションのFQCNを実行順に定義する。 -`list` コンポーネントの名前は、 `interceptorsOrder` として定義する。 - -以下の例では、`OnDoubleSubmission` -> `OnErrors` -> `OnError` の順にインターセプタが実行される。 -ハンドラメソッドに `OnDoubleSubmission` と `OnError` が定義されている場合は、 `OnDoubleSubmission` -> `OnError` の順にインターセプタが実行される。 - -```xml - - nablarch.common.web.token.OnDoubleSubmission - nablarch.fw.web.interceptor.OnErrors - nablarch.fw.web.interceptor.OnError - -``` - -設定ファイルに未定義のインターセプタが利用された場合には、実行時例外を送出する。 - -設定ファイル上にインターセプタの実行順を示す `list` コンポーネントが定義されていない場合は、 -`Method#getDeclaredAnnotations` が返すリストの逆順でインターセプタを実行する。 -`Method#getDeclaredAnnotations` が返すアノテーションリストの順序は保証されていなため、 -実行環境(jvmのバージョンなど)によって、インターセプタの実行順が変わる可能性がある点に注意すること。 - ------ - -### 画面オンライン処理における変数スコープの利用 - -画面オンライン処理方式では、リクエストスコープ、セッションスコープに加えて、 -各画面内に自動的に出力されるhidden項目によって実装される *ウィンドウスコープ* が定義されている。 - -ウィンドウスコープにはウィンドウやタブごとに個別の変数を保持することができる。 -ここに業務データを保持することで、ウィンドウ毎に個別の状態を維持することができ、 -複数ウィンドウから並行操作を行っても、矛盾なく業務処理を遂行することが可能となる。 - -各変数スコープの用途と使用方法について解説する。 -次の表と模式図は、画面オンライン処理方式における各スコープの特徴と用途をまとめたものである。 - -| スコープ名称 | 用途 | 作成単位 | 維持期間 | -|---|---|---|---| -| リクエストスコープ | 単一のHTTPリクエスト内でのみ使用するデータ (=画面間で共有する必要の無いデータ)を保持する。 | HTTPリクエストごと | HTTPリクエストの開始から終了まで。 | -| ウィンドウスコープ | 画面間で共有するデータのうち、 ウィンドウ間で共有する必要の無いデータを保持する。 | ブラウザのウィンドウ、 タブ、フレームごと | ウィンドウを開いてから閉じるまで。 もしくはセッションスコープが終了するまで。 | -| セッションスコープ | 画面間で共有するデータのうち、 ウィンドウ間で共有する必要の有るデータを保持する。 | ユーザのログインごと | ユーザログインからログアウトまで。 もしくはセッションタイムアウトまで | - -![web_scope.png](../../../knowledge/assets/handlers-HttpMethodBinding/web_scope.png) - -以下では画面オンライン処理方式における各スコープの詳細について述べる。 - ------ - -**リクエストスコープ** - -3つの変数スコープのうちで最も維持期間が短い。 -各HTTPリクエストごとに作成され、レスポンス処理が完了するまで維持される。 -単一のリクエスト間で完結し、次画面以降に引き継ぐ必要の無いデータはここに保存する。 - -画面オンライン処理方式におけるリクエストスコープは基本的にServletAPIの -HTTPServletRequest#getAttribute()/setAttribute()メソッドのラッパーである。 - -**リクエストスコープに保持するデータ** - -* 画面に表示するデータオブジェクト（次画面以降に引き継がないもの） -* バリデーションエラー等のメッセージ -* JSP側で表示用に使用するフラグ - ------ - -**ウィンドウスコープ** - -ウィンドウスコープは、ブラウザのウィンドウ、タブ、フレームごとに作成される。 -(以降この節では、これらをまとめて単に"ウィンドウ"と表現する。) -ウィンドウスコープは、各ウィンドウが閉じられるか、セッションが終了するまで維持される。 - -例えば、ログインユーザIDや、ショッピングカート内の商品一覧などの -ウィンドウ間で同一の値を共有しなければならない一部のデータを除けば、 -画面遷移を跨って使用する必要があるデータは、全てウィンドウスコープ上に保持する。 - -これにより、アプリケーション側で特段の考慮をしなくとも -複数のウィンドウを用いた並行操作や、ブラウザのヒストリバックによる遷移が可能となる。 - -**ウィンドウスコープに保持するデータ** - -* 画面の入力項目(入力項目復帰が必要なもの) -* 他業務画面からの引き継ぎデータ -* 画面遷移履歴情報 -* 楽観ロック用バージョン番号 [1] - -**使用方法** - -ウィンドウスコープ変数は hidden属性のinputタグとして各ウィンドウの画面内に維持される。 -従って、ウィンドウスコープ上の変数は通常のリクエストパラメータと同等に扱われる。 -ウィンドウスコープ変数を含めたリクエストパラメータにアクセスするには -[入力値のバリデーション](../../component/libraries/libraries-core-library-validation.md#入力値のバリデーション) 機能のAPIを使用する。 - -リクエストパラメータはフレームワークによって自動的にhiddenタグとして画面に出力される。 -従って、ウィンドウスコープに変数を追加するには、HttpRequestクラスに定義されているsetParam()メソッドを使用する。 - -```java -public class HttpRequest extends Request { - /** - * リクエストパラメータを設定する。 - */ - @Published - public HttpRequest setParam(String name, String... params); -} -``` - -**セキュリティ上の考慮** - -フレームワークが出力したhiddenタグの値はフレームワークによって -リクエストURIおよびname属性のハッシュ値とともに暗号化される。 -暗号化処理に使用する共通鍵はユーザログイン時に作成しメモリ上に保持される。 -この鍵はログアウトもしくはセッションタイムアウトの時点で廃棄されるので、 -極めて安全性が高い。 - -あるデータに対する複数ユーザからの変更に対して、 -複数のリクエスト(画面)を跨いだトランザクションを実装する場合に使用する制御情報のこと。 - ------ - -**セッションスコープ** - -ログインユーザごとに作成されるスコープであり、 -本フレームワークでは複数のウィンドウで共有されるデータを保持する目的で使用する。 -ユーザがログインした時点で作成され、ログアウトもしくはセッションタイムアウトが発生するまで維持される。 - -セッションスコープ上のデータは複数のウィンドウから同時にアクセスされる可能性があり、 -適切に同期化しなければならない。 - -**セッションスコープに保持するデータ** - -* ログインユーザに紐づくデータ（ログインユーザID、認証・認可情報） -* ウィンドウ間で同一のデータを参照・更新する必要があるデータ（ショッピングカート内の商品情報など） - -**セッションスコープの実装方式** - -セッションスコープの実装方式には、HTTPSessionオブジェクトを使用するものと、 -データベースを使用した独自実装の2通りの方式が存在する。 -この選択は、アプリケーションサーバのスケーリング方式に大きく影響する。 - -HTTPSessionオブジェクトを使用する場合、同じログインユーザからのリクエストを -セッションスコープが存在するサーバインスタンスに必ず振り分けるようにするか、 -(セッションアフィニティ方式) -サーバクラスタ内の全てのサーバインスタンスでセッションスコープを同期する必要がある。 -(セッションパーシステント方式) - -データベースを使用した独自実装を使用した場合、アプリケーションサーバについては -ほぼ制約無くスケールアップさせることができるが、データベースへの負荷は増加する。 - -> **Note:** -> データベースを使用したHTTPセッション実装は現時点では提供されていない。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpRequestJavaPackageMapping.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpRequestJavaPackageMapping.md deleted file mode 100644 index 073612c84..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpRequestJavaPackageMapping.md +++ /dev/null @@ -1,56 +0,0 @@ -## HTTPリクエストディスパッチハンドラ - -**クラス名:** `nablarch.fw.handler.HttpRequestJavaPackageMapping` - ------ - -### 概要 - -このハンドラは、画面オンライン処理におけるリクエストパス中の部分文字列(ベースURI)をJavaパッケージ階層にマッピングすることで、 -動的に委譲先ハンドラを決定するディスパッチ処理を行う。 - -本ハンドラの実装は [リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) を直接継承しており、その機能は以下の2点を除けば全く同じものである。 - -1. ディスパッチ対象のクラスが確定した時点で、HTTPアクセスログにその内容を出力する。 -2. ベースパスを設定する際にURLの書式精査を行うアクセサ(**#setBaseUri()**)を追加。 - -機能の詳細については、 [リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) を参照すること。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTPリクエストパスによるディスパッチハンドラ | nablarch.fw.handler.HttpRequestJavaPackageMapping | HttpRequest | Object | HTTPリクエストパスをもとに業務アクションを決定しハンドラキューに追加する。HTTPメソッドによるメソッド単位のディスパッチを行う。(HttpMethodBinding) | - | - | - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| ベースURI | baseUri | String | 任意指定 (デフォルト = "") | -| ベースパッケージ | basePackage | String | 任意指定 (デフォルト = "") | -| ハンドラ追加位置 | immediate | boolean | 任意指定 (デフォルト = true) | -| リクエストパスのパターンとマッピング先 Javaパッケージの組み合わせ | optionalPackageMappingEntries | nablarch.fw.handler .JavaPackageMappingEntry | 任意指定 (デフォルト = null) | - -**設定例** - -以下の設定では、画面オンライン処理のリクエストパス中のベースURI（コンテキストルート） **/webapp/sample** を、 -Javaパッケージ **nablarch.sample.apps** に対応させている。 - -```xml - - - - - -``` - -上記設定を行った場合のディスパッチの例を以下に示す。 - -| リクエストパス | ディスパッチ対象クラス | -|---|---| -| /webapp/sample/AdminApp | nablarch.sample.apps.AdminApp | -| /webapp/sample/user/UserApp | nablarch.sample.apps.user.UserApp | diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpResponseHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpResponseHandler.md deleted file mode 100644 index 42eddb60e..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpResponseHandler.md +++ /dev/null @@ -1,216 +0,0 @@ -## HTTPレスポンスハンドラ - -**クラス名:** `nablarch.fw.handler.HttpResponseHandler` - ------ - ------ - -### 概要 - -このハンドラは、後続ハンドラの処理結果となるHTTPレスポンスオブジェクトの内容に沿って、 -サーブレットフォーワード処理や、サーバソケットへの出力といったレスポンス処理を行う。 - -HTTPレスポンスオブジェクトは、あくまで「レスポンス処理を行うために必要な情報を格納したクラス」であり、 -これを生成しただけではレスポンス処理は行われない。 -HTTPレスポンスオブジェクトの内容に沿って実際にレスポンス処理を行うのはこのハンドラである。 - -HTTPレスポンスオブジェクトがクライアントに送信するレスポンスボディの内容を指定する方法は大きく2つある。 - -1つめは、HTTPレスポンスオブジェクトに対して直接レスポンスボディの内容を設定する方法であり、 -主に [ファイルダウンロード](../../component/libraries/libraries-05-FileDownload.md) 処理などで使用する。 - -もう1つは、 [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) と呼ばれる文字列によってレスポンス内容を指定する方法であり、 -通常の業務機能の実装ではこちらを主に使用する。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTPレスポンスハンドラ | nablarch.fw.web.handler.HttpResponseHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容に沿ってレスポンス処理かサーブレットフォーワードのいずれかを行う。 | 既定のエラー画面をレスポンス後、例外を再送出する。ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 | -| リソースマッピングハンドラ | nablarch.fw.web.handler.ResourceMapping | HttpRequest | HttpResponse | リクエストURIを、クラスパス上のリソースパスもしくはサーブレットフォーワードパスにマッピングすることで、業務アクションを実行することなくHTTPレスポンスオブジェクトを作成して返却する。 | - | - | -| 画面オンライン処理業務アクション | nablarch.fw.action.HttpMethodBinding | HttpRequest | HttpResponse | HTTPリクエストの内容をもとに業務処理を実行する | 遷移先画面に表示する内容をリクエストコンテキストに設定した上で、遷移先パスを設定したHTTPレスポンスオブジェクトを返却する。 | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| * [リソースマッピングハンドラ](../../component/handlers/handlers-ResourceMapping.md) * [画面オンライン処理用業務アクションハンドラ](../../component/handlers/handlers-HttpMethodBinding.md) | 本ハンドラは、 [HttpResponse](../../javadoc/nablarch/fw/web/HttpResponse.html) をリターンもしくは送出するこれらのハンドラの上位に 配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (後続ハンドラへの処理委譲)** - -往路では本ハンドラは特段の処理を行なわない。 -引数をそのまま後続ハンドラに渡して処理を委譲し、その結果としてHTTPレスポンスオブジェクトを取得する。 - -**[復路での処理]** - -**2. (コンテンツパスの取得)** - -HTTPレスポンスオブジェクトに設定された [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) 文字列を取得する。 - -**2a. (サーブレットフォーワード処理)** - -[コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) が **"forward://"** で開始されていた場合は、 -フォーワード名に対するサーブレットフォーワードを実行する。 -この場合、クライアントに対するレスポンスの出力処理はフォーワード先のサーブレットで実行される。 - -フォーワード完了後、HTTPレスポンスオブジェクトをリターンして終了する。 - -**3. (HTTPレスポンスヘッダー送信)** - -HTTPレスポンスに設定されたHTTPヘッダーの内容をクライアントに送信する。 -(ボディの内容はChunkedエンコーディングによって送信される。) - -**3a. (HTTPリダイレクション)** - -[コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) が **"redirect://"** 、 **"http://"** 、 **"https://"** -のいずれかで開始されていた場合は、パス文字列を **Location** ヘッダに設定し、リダイレクトの -HTTPレスポンスを送信する。 - -なお、 **redirect://** スキームかつ絶対パス指定であった場合は、 **Location** ヘッダに設定するパスに -サーブレットコンテキストルートのパスを補完する。 - -**4a. (HTTPレスポンスボディ送信: ファイルシステム上のファイルの内容を送信)** - -[コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) が **"file://"** で開始されていた場合は、 -パスに指定されたファイルの内容をレスポンスボディとして送信する。 - -**4b. (HTTPレスポンスボディ送信: クラスパス上のリソースの内容を送信)** - -[コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) が **"classpath://"** で開始されていた場合は、 -コンテキストクラスローダからパスに指定されたリソースを取得し、その内容をレスポンスボディとして送信する。 - -**4c. (HTTPレスポンスボディ送信: InputStreamの内容を送信)** - -HTTPレスポンスオブジェクトに直接InputStreamが設定されている場合、 -もしくは、 `HttpResponse#write()` メソッドによってレスポンス内容を -HTTPレスポンスオブジェクト内にバッファリングしている場合は -その内容をレスポンスボディとして送信する。 - -**5. (終端処理)** - -レスポンス処理で使用した入出力ストリームを全てクローズする。 -また、HTTPレスポンスオブジェクト上にレスポンス内容がバッファリングされている場合は削除する。 - -**6. (正常終了)** - -HTTPレスポンスオブジェクトをリターンして終了する。 - -**[例外処理]** - -**1a. (後続ハンドラ実行中のエラー)** - -後続ハンドラ実行中に例外が送出された場合は、 -既定のエラー画面をレスポンス後、例外を再送出する。 -ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 - -**2a-b. (サーブレットフォーワード先でのエラー)** - -フォーワード先のJSPやサーブレットでエラーが発生した場合は、 -システムエラー画面をクライアント側に送信して終了する。 - -**2a-c. (サーブレットフォーワード中のIOエラー)** - -サーブレットフォーワード処理中にIOエラーが発生した場合は、 -ワーニングレベルのログを出力した上でHTTPレスポンスオブジェクトをリターンして終了する。 - -**5a. (レスポンス処理中のIOエラー)** - -レスポンス処理および、終端処理においてIOエラーが発生した場合は、 -ワーニングレベルのログを出力した上で処理を継続する。 - -**5a. (レスポンス処理中のその他のエラー)** - -レスポンス処理および、終端処理において例外が発生した場合は、 -システムエラー画面をクライアントに送信し、 **5.** の終端処理を行なったうえで、例外を再送出する。 - ------ - -#### ステータスコードの変換 - -HTTPレスポンスハンドラは、内部で 404 などのエラー用レスポンスが返された際に、正常レスポンスを表す 200 にステータスコードを変換する。 - -これは、ブラウザのレスポンスコードによる挙動の差異を発生させないための施策である。 - -例外的に、転送に用いられる 300 系のレスポンスコードであった場合と、 -クライアントからのリクエストヘッダ "X-Requested-With" の値が "XMLHttpRequest" である -場合(つまり AJAX のリクエストの場合) 内部のエラーコードをそのままステータスコードとする。 - -#### 言語毎のコンテンツパスの切り替え - -HTTPレスポンスハンドラは、HTTPリクエストから取得した言語設定をもとに、フォーワード先を動的に切り替える機能をもつ。 -ResourcePathRule抽象クラスのサブクラスを使用して言語毎のコンテンツパスを取得することで、 -HTTPレスポンスハンドラは言語毎のコンテンツパスの切り替えを行う。 - -ResourcePathRuleおよび本フレームワークがデフォルトで提供するサブクラスを下記に示す。 - -| クラス名 | 説明 | -|---|---| -| ResourcePathRule | 言語対応リソースパスのルールを表すクラス。 言語はスレッドコンテキストから取得する。 スレッドコンテキストへの言語設定については、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) を参照。 スレッドコンテキストから言語を取得できない場合は指定されたリソースパスをそのまま返す。 言語対応のリソースパスが指すファイルが存在する場合のみ言語対応のリソースパスを返す。 ファイルが存在しない、または指定されたリソースパスに拡張子を含まない場合は 指定されたリソースパスをそのまま返す。 サブクラスでは言語対応のリソースパスを作成するメソッドを実装する。 | -| DirectoryBasedResourcePathRule | コンテキストルート直下のディレクトリを言語の切り替えに使用するクラス。 ```bash # /management/user/search.jspを日本語(ja)と英語(en)に対応する場合の配置例 # コンテキストルート直下に言語ごとにディレクトリを作成する。 # ディレクトリ名は言語名とする。 コンテキストルート ├─en │ └─management │ └─user │ search.jsp └─ja └─management └─user search.jsp ``` | -| FilenameBasedResourcePathRule | ファイル名を言語の切り替えに使用するクラス。 ```bash # /management/user/search.jspを日本語(ja)と英語(en)に対応する場合の配置例 # 言語毎にファイルを作成する。 # ファイル名にはサフィックス「"_"＋言語名」を付ける。 コンテキストルート └─management └─user search_en.jsp search_ja.jsp ``` | - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 言語毎コンテンツパスの対応ルール | contentPathRule | ResourcePathRule | 任意指定(デフォルト=DirectoryBasedResourcePathRule) | - -**標準設定** - -以下は標準設定におけるDI設定の例である。 - -```xml - - -``` - -**言語毎のコンテンツパス切り替えを行なう場合の設定** - -言語毎に切り替えたいコンテンツは、コンテキストルート直下に言語毎のディレクトリを作成し、 -言語毎のディレクトリにデフォルトのコンテンツパスと同じでパスで配置する。 -コンテンツパスの例を示す。 - -```bash -# デフォルトのコンテンツパス -/management/user/search.jsp - -# 日本語対応のコンテンツパス -/ja/management/user/search.jsp - -# 英語対応のコンテンツパス -/en/management/user/search.jsp -``` - -リポジトリの設定例を示す。 - -```xml - - - - - - - -``` - -スレッドコンテキストに設定された言語と使用されるコンテンツパスの例を示す。 -ここでは上記コンテンツパスの例に記載したファイルが配置されているものとする。 - -```bash -# HttpResponseオブジェクトに設定されたコンテンツパス -servlet:///management/user/search.jsp - -# スレッドコンテキストの言語 -> 使用されるコンテンツパス -ja -> /ja/management/user/search.jsp -en -> /en/management/user/search.jsp -it -> /management/user/search.jsp -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpRewriteHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpRewriteHandler.md deleted file mode 100644 index 5e78466e2..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-HttpRewriteHandler.md +++ /dev/null @@ -1,279 +0,0 @@ -## HTTPリライトハンドラ - -**クラス名:** `nablarch.fw.web.handler.HttpRewriteHandler` - ------ - ------ - -### 概要 - -このハンドラでは、HTTPリクエストオブジェクトおよび、HTTPレスポンスオブジェクトの内容を、 -事前に設定されたルール(リライトルール)に従って動的に書き換える機能を提供する。 - -また、書換えが行われた際に、リクエストパスの部分文字列や、リクエストパラメータ、 -HTTPヘッダーのなどの内容を各スコープ上の変数として設定することができる。 - -> **Note:** -> 本ハンドラは個別プロジェクトでの特殊要件に柔軟に対応する目的で作成されており、 -> 標準ハンドラ構成には含まれない。 - -#### リライトルール - -本ハンドラの動作は、本節で解説する [リライトルール](../../component/handlers/handlers-HttpRewriteHandler.md#リライトルール) 呼ばれる設定項目によって定義され、 -その内容に従って様々な処理を行うことができる。 - -1つのリライトルールに関する情報は、 [RewriteRule](../../javadoc/nablarch/fw/handler/RewriteRule.html) オブジェクトのプロパティとして保持される。 - -本ハンドラでは、 HTTPリクエストオブジェクトのリクエストパスおよび、HTTPレスポンスオブジェクトの -[コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) に対する書換えを行うことができる。 -設定は、それぞれ [RewriteRule](../../javadoc/nablarch/fw/handler/RewriteRule.html) のサブクラスである [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) および [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) を用いて行うが、 -書換えの対象が異なるだけで、設定項目の内容は同じである。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 処理対象パターン | pattern | String | 必須指定 書き換え処理が行われるパスのパターンを 正規表現で指定する。 | -| 置換先パス | rewriteTo | String | 任意指定 パスの書き換え処理の内容を表す文字列を 指定する。 省略した場合は置換処理は行わず、現在のパスを そのまま使用する。 | -| 適用条件リスト | conditions | List | 任意指定(デフォルトは空のList) 書き換え処理が行われるための追加条件を指定する。 | -| 変数定義リスト | exports | List | 任意指定(デフォルトは空のList) 書き換え処理が行われた際に、各種スコープ上 (リクエスト、セッション、スレッドコンテキスト等) に定義する変数名とのその内容を指定する。 | - -以下では、このリライトルールについて具体例を挙げて解説する。 - -**例1) 単純置換** - -この設定例では、サーブレットコンテキストルートに対するアクセスに対してログインJSP画面を表示させている。 - -```xml - - - - - -``` - -処理対象パターンは上記例のようにサーブレットコンテキストを起点とする相対パスへの正規表現として指定する。 -( [リクエストハンドラエントリ](../../component/handlers/handlers-RequestHandlerEntry.md) のようなGlob式によるパターン指定とは異なるので注意すること。) - -また、置換先パスが **"servlet://** もしくは **redirect://** で始まる場合は、それぞれサーブレットフォーワード、 -HTTPリダイレクトによるレスポンスが返されるので、後続のハンドラに処理は移譲されない。 - -一方、ログイン画面の表示処理が単純なJSPへのフォーワードでは無く、業務アクションでの処理を要する場合は、 -以下の様に指定する。 - -```xml - - - - - -``` - -この場合は、リクエストパスを、 **"/"** から **/action/LoginAction/authenticate** に書き換えた上で -後続のハンドラに処理を移譲する。 - -**例2) 適用条件の追加** - -書き換えを行う条件は、リクエストパスのパターン以外の方法で判定することができる。 -以下の設定例では、セッションスコープ上にユーザIDが設定されていれば、ログイン画面ではなく、 -メニュー画面に直接遷移させている。 - -```xml - - - - - - %{session:user.id} ^\w+$ - - - - -``` - -上記例のように、条件の指定は以下の書式で行う。 - -```bash -%{(変数種別名):(変数名)} (パターン) -``` - -各リライトルールで使用可能な変数種別は以下の通り。 - -| 変数種別 | 書式 | 対象 | -|---|---|---| -| セッションスコープ | %{session:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) / [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | -| リクエストスコープ | %{request:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) / [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | -| スレッドコンテキスト | %{thread:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) / [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | -| リクエストパラメータ | %{param:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) | -| HTTPヘッダ | %{header:(ヘッダー名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) / [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | -| HTTPリクエストメソッド | %{httpMethod} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) | -| HTTPバージョン | %{httpVersion} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) | -| 全リクエストパラメータ名 | %{paramNames} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) | -| ステータスコード | %{statusCode} | [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | - -**例3) 変数の設定** - -パスの書き換えと同時に、各種スコープ上に変数を定義し、後続のハンドラやJSPから参照することが可能である。 -以下の設定例では、HTTPリファラヘッダの値をリクエストスコープ変数 **prevUrl** に設定している。 - -```xml - - - - - - - - %{header:Referer} ^\S+$ - - - - - - %{request:prevUrl} ${header:Referer} - - - -``` - -HTTPリクエストの書き換えでは、以下のスコープ上に変数を設定することができる。 - -| 変数スコープ | 書式 | 対象 | -|---|---|---| -| セッションスコープ | %{session:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) / [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | -| リクエストスコープ | %{request:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) / [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | -| スレッドコンテキスト | %{thread:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) / [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) | -| ウィンドウスコープ | %{param:(変数名)} | [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) | - -また、 **rewriteTo** 属性で指定される置換先パス、および、 **exports** 属性で指定される変数値には、 -以下の書式で埋め込みパラメータを使用することができる。 - -| 書式 | 意味 | -|---|---| -| ${(バックトラック番号)} | pattern属性に指定されたリクエストパス に対する部分マッチ(キャプチャ)の内容。 **${0}** : マッチ内容全体 **${1}** : 第1キャプチャの内容 **${n}** : 第nキャプチャの内容 | -| ${(変数種別名):(変数名)} | 各変数の内容 **${session:user.id}** : セッションスコープ上のuser.id変数の値 **${httpMethod}** : HTTPリクエストメソッド名(GET/POST/PUT...) | -| ${(変数種別名):(変数名):バックトラック番号} | condition属性で指定された適用条件に対する部分マッチ (キャプチャ)の内容。 **${header:Referer:1}** : リファラヘッダに対する第1キャプチャの内容 | - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTPレスポンスハンドラ | nablarch.fw.web.handler.HttpResponseHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容に沿ってレスポンス処理かサーブレットフォーワードのいずれかを行う。 | 既定のエラー画面をレスポンス後、例外を再送出する。ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 | -| HTTPリライトハンドラ | nablarch.fw.web.handler.HttpRewriteHandler | HttpRequest | HttpResponse | HTTPリクエストパスの内容を指定した条件に従って書き換える。 | HTTPレスポンスのコンテンツパスの内容を、指定した条件に従って書き換える。 | - | -| スレッドコンテキスト変数設定ハンドラ(リクエストスレッド) | nablarch.common.handler.ThreadContextHandler_request | Object | Object | 前のループで設定されたスレッドコンテキスト変数をクリアするためここで再初期化する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) | 本ハンドラで [HttpResponse](../../javadoc/nablarch/fw/web/HttpResponse.html) 内のコンテンツパスの書き換えを行う場合は、 [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) を本ハンドラの上位に配置しないと、書き換え後のパスが レスポンスに反映されない。 | -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | 本ハンドラで書換えたリクエストパスや各種スコープ変数の内容もとに、 [スレッドコンテキスト](../../component/libraries/libraries-thread-context.md) 上の属性を導出している 場合は、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) を本ハンドラの後続に配置し、本ハンドラで 書換えた内容を反映させる必要がある。 特に、リクエストパスから導出されるリクエストIDは後続ハンドラへの影響が 大きいので留意すること。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (リクエストパスに対する書き換え処理)** - -本ハンドラの **requestPathRewriteRules** に設定された [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) の先頭要素から順に -条件が合致するかどうかを確認する。 -合致したものがあれば、その内容に従ってリクエストパスの書き換えとスコープに対する変数定義を行う。 -どれか1つでも条件に合致すれば、それ以降のルールについては評価されない。 - -**1a. (サーブレットフォワード)** - -**1.** での処理の結果、書き換え先のパスが "servlet://" で開始されるリライトルールが適合した場合、 -当該のコンテンツパスによるHTTPレスポンスオブジェクトを生成し、リターンして終了する。 -(後続ハンドラに対する処理の移譲は行われない。) - -**1b. (リダイレクト)** - -**1.** での処理の結果、書き換え先のパスが "redirect://" で開始されるリライトルールが適合した場合、 -当該のコンテンツパスによるHTTPレスポンスオブジェクトを生成し、リターンして終了する。 -(後続ハンドラに対する処理の移譲は行われない。) - -**2. (後続ハンドラへの処理移譲)** - -**1.** で書き換え処理を行ったHTTPリクエストオブジェクトを -後続ハンドラに渡して処理を委譲し、その結果となるHTTPレスポンスオブジェクトを取得する。 - -**[復路での処理]** - -**3. (コンテンツパスに対する書き換え処理)** - -**2.** で取得したHTTPレスポンスオブジェクトに設定されたコンテンツパスに対して -本ハンドラに設定された [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) を順次適用し、 -コンテンツパスの書き換えおよび、変数定義を行う。 -リクエストパスの書き換えと同様、どれか1つでも条件に合致すれば、それ以降のルールについては評価されない。 - -**4. (正常終了)** - -**3.** で書き換えを行ったHTTPレスポンスオブジェクトをリターンし、終了する。 - -**[例外処理]** - -**2a. (後続ハンドラ処理中のエラー)** - -後続ハンドラの処理中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの挙動は、HTTPリクエストに対する書き換え処理を定義する [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) -および、HTTPレスポンスに使用するコンテンツパスの書き換え処理を定義する [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) によって -決定される。 - -本ハンドラにはそれらのリストを設定する。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| リクエストリライト定義 | requestPathRewriteRules | List | 任意指定(デフォルトは空のリスト) HTTPリクエストパスに対する書き換え 処理定義のリストを設定する。 | -| コンテンツパスリライト定義 | contentsPathRewriteRules | List | 任意設定(デフォルトは空のリスト) HTTPレスポンスのコンテンツパスに 対する書き換え処理定義のリストを 設定する。 | - -以下は設定例である。 -( [HttpRequestRewriteRule](../../javadoc/nablarch/fw/web/handler/HttpRequestRewriteRule.html) と、 [ContentPathRewriteRule](../../javadoc/nablarch/fw/web/handler/ContentPathRewriteRule.html) の設定内容については [リライトルール](../../component/handlers/handlers-HttpRewriteHandler.md#リライトルール) を参照すること。) - -```xml - - - - - - - - - - %{session:user.id} ^\S+$ - - - - - - - - - - - - - - - - - - - - - - - - %{statusCode} ^401$ - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-KeitaiAccessHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-KeitaiAccessHandler.md deleted file mode 100644 index 866609939..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-KeitaiAccessHandler.md +++ /dev/null @@ -1,90 +0,0 @@ -## 携帯端末アクセスハンドラ - -**クラス名:** `nablarch.fw.web.handler.KeitaiAccessHandler` - ------ - ------ - -### 概要 - -本ハンドラは携帯端末、特にいわゆる「フィーチャーフォン」からのアクセスを想定したページを出力するハンドラである。 -具体的には以下の処理を行う。 - -* リクエストパラメータ中に埋め込まれた遷移先URIでリクエストパスを置換する。 - これにより、javascriptに対応していない携帯端末でも、サブミットボタン毎の遷移先切替、 - ウィンドウスコープの利用等が可能となる。 -* javascript等の出力を抑制するフラグ(nablarch_jsUnsupported)をリクエストスコープ変数に設定する。 - (このフラグはJSP中の各カスタムライブラリで使用される。) - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTPレスポンスハンドラ | nablarch.fw.web.handler.HttpResponseHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容に沿ってレスポンス処理かサーブレットフォーワードのいずれかを行う。 | 既定のエラー画面をレスポンス後、例外を再送出する。ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 | -| 携帯対応ハンドラ | nablarch.fw.web.handler.KeitaiAccessHandler | HttpRequest | HttpResponse | - | - | - | -| スレッドコンテキスト変数設定ハンドラ(リクエストスレッド) | nablarch.common.handler.ThreadContextHandler_request | Object | Object | 前のループで設定されたスレッドコンテキスト変数をクリアするためここで再初期化する。 | - | - | -| Nablarchカスタムタグ制御ハンドラ | nablarch.common.web.handler.NablarchTagHandler | HttpRequest | HttpResponse | Nablarchカスタムタグの動作に必要な事前処理を実施する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) | 本ハンドラでは、携帯端末向けにjavascriptを使用しないHTMLを出力させるフラグを設定 するため、 [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) を本ハンドラの上位に配置しないと、 その設定がレスポンスに反映されない。 | -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | 本ハンドラで書換えたリクエストパスの内容をもとに、 [スレッドコンテキスト](../../component/libraries/libraries-thread-context.md) 上のリクエストID属性 を決定するので、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) は本ハンドラの後続に配置する必要が ある。 | -| [Nablarchカスタムタグ制御ハンドラ](../../component/handlers/handlers-NablarchTagHandler.md) | 本ハンドラで設定したリクエストパラメータ **nablarch_sumbit** の値をもとに 改竄チェックやウィンドウスコープの展開等を行うので、 [Nablarchカスタムタグ制御ハンドラ](../../component/handlers/handlers-NablarchTagHandler.md) は、本ハンドラの後続に配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (携帯対応画面出力フラグを設定)** - -遷移先のJSPページでの javascript等の出力を抑制するフラグ変数 (**nablarch_jsUnsupported**) -をリクエストスコープに設定する。 - -**2. (リクエストパスに対する書き換え処理)** - -リクエストパラメータ中に"nablarch_uri_override"で始まる名前のパラメータが -存在した場合、その内容を元に、リクエストパスを置換するとともに、リクエストパラメータ **nablarch_sumit** -の値を設定する。 - -**3. (後続ハンドラへの処理移譲)** - -**2.** で書き換え処理を行ったHTTPリクエストオブジェクトを -後続ハンドラに渡して処理を委譲する。 -その結果であるHTTPレスポンスオブジェクトを取得する。 - -**[復路での処理]** - -**4. (正常終了)** - -**3.** で取得したHTTPレスポンスオブジェクトをリターンして終了する。 - -**[例外処理]** - -**3a. (後続ハンドラ処理中のエラー)** - -後続ハンドラの処理中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラ自体に設定項目は存在しないが、 -携帯対応を行うリクエストパスの範囲を限定するため、通常は [リクエストハンドラエントリ](../../component/handlers/handlers-RequestHandlerEntry.md) と組み合わせて使用する。 - -**設定例** - -この設定例では、サーブレットコンテキストからの相対パス "/action/mobile/" 配下のアクセスに対して -本ハンドラを動作させている。 - -```xml - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-LoopHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-LoopHandler.md deleted file mode 100644 index 13098a5e7..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-LoopHandler.md +++ /dev/null @@ -1,149 +0,0 @@ -## トランザクションループ制御ハンドラ - -**クラス名:** `nablarch.fw.handler.LoopHandler` - ------ - ------ - -### 概要 - -本ハンドラは、データリーダ上に処理対象のデータが存在する間、後続ハンドラの処理を繰り返し実行するとともに、 -トランザクション制御を行ない、一定の繰り返し回数ごとにトランザクションをコミットする。 -これにより、バッチ処理のスループットを向上させることができる。 - -本ハンドラの機能はトランザクション管理機能とループ制御機能を兼ねているため -[トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) および [リクエストスレッド内ループ制御ハンドラ](../../component/handlers/handlers-RequestThreadLoopHandler.md) とは排他利用である。 - -> **Warning:** -> 本ハンドラでは、複数の業務処理の一括コミットを許容している。 -> このため、業務アクションハンドラ上の処理が正常終了したとしても、後続レコードの処理でエラーが -> 発生することによりロールバックされる可能性がある。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| データベース接続管理ハンドラ | nablarch.common.handler.DbConnectionManagementHandler | Object | Object | 業務処理用ＤＢ接続を取得し、スレッドローカル上に保持する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | - | -| トランザクションループハンドラ | nablarch.fw.handler.LoopHandler | Object | Object | 実行中の業務トランザクションがなければ、新規のトランザクションを開始する。 | コミット間隔毎に業務トランザクションをコミットする。また、データリーダ上に処理対象データが残っていればループを継続する。 | 業務トランザクションをロールバックする。 | 1.コミット完了後 / 2.ロールバック後 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [データベース接続管理ハンドラ](../../component/handlers/handlers-DbConnectionManagementHandler.md) | このハンドラの上位に配置することで、本ハンドラが管理するトランザクションにDB接続を参加させることができる。 | - -**コールバックイベント** - -本ハンドラでは [データベース接続管理ハンドラ](../../component/handlers/handlers-DbConnectionManagementHandler.md) と同様のコールバックを行なう。 -後続のハンドラがイベントリスナ **TransactionManagementHandler.Callback** を実装することで、 -下記のイベント発生時にコールバックを受けることができる。 - -1. 業務処理正常終了時 - -```java -TransactionManagementHandler.Callback#transactionNormalEnd(TData data, ExecutionContext context): void -``` - -> **Warning:** -> このコールバックは、レコード一件に対する業務処理が正常終了した場合に呼ばれるが、 -> [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) とは異なり、この時点ではまだ -> トランザクションのコミットが確定していない点に留意すること。 - -> これは、本ハンドラでは、コミット単位を任意に設定することができることに起因する制約である。 - -1. トランザクションロールバック直後 - -```java -TransactionManagementHandler.Callback#transactionAbnormalEnd(TData data, ExecutionContext context): void -``` - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (トランザクションの取得と開始)** - -本ハンドラに設定されたトランザクションファクトリからトランザクションオブジェクトを取得し、 -トランザクションを開始する。 -また、取得したトランザクションオブジェクトをスレッドローカル変数に格納する。 - -**2. (ループ開始前の初期化処理)** - -ループ開始前のハンドラキューのシャローコピーを作成する。 -未コミット件数を0に初期化する。 - -**3. (ループ開始)** - -実行コンテキスト上のハンドラキューの内容を **2.** で作成したループ開始前の状態に戻す。 - -**4. (後続ハンドラの実行)** - -ハンドラキュー上の後続のハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**5. (1件分の処理が正常終了)** - -後続ハンドラでの処理が正常終了した場合は、未コミット件数を1件増加させる。 -また、後続ハンドラのうち、イベントリスナ **TransactionManagementHandler.Callback** を実装しているハンドラに対して -以下のコールバックを呼び出す。: - -``` -TransactionManagementHandler.Callback#transactionNormalEnd(TData data, ExecutionContext context): void -``` - -**5a. (データリーダが終端に達していた場合)** - -**4.** の結果が **nablarch.fw.DataReader.NoMoreRecord** であった場合は、 -業務処理が呼ばれる前にデータリーダの終端に達しているため、コールバックは呼ばずにスキップする。 - -**6. (コミット判定)** - -現在の未コミット件数が、本ハンドラに設定されたコミット間隔に一致する場合は、現在のトランザクションをコミットする。 - -**7. (ループ継続)** - -実行コンテキスト上のデータリーダの状態を確認し、終端に達していなければ、 -**3.** 以降の処理を再度実行する。 - -**7a. (ループ終端)** - -データリーダが終端に達していた場合は、未コミット処理をコミットした上で、 -**4.** の処理結果をリターンして終了する。 - -**例外処理** - -**5b. (例外制御)** - -**4.** での処理中に、後続ハンドラから未捕捉の例外が送出された場合は、トランザクションをロールバックする。 -(未コミットの処理についてもあわせてロールバックされる。) -また、後続ハンドラのうち、イベントリスナ **TransactionManagementHandler.Callback** を実装しているハンドラに対して -以下のコールバックを呼び出す。: - -``` -TransactionManagementHandler.Callback#transactionAbnormalEnd(TData data, ExecutionContext context): void -``` - -例外を再送出し、ループを終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| コミット間隔回数 | commitInterval | int | 任意指定(デフォルト=1) | -| トランザクション取得機能 | transactionFactory | TransactionFactory | 必須指定 | -| 使用DBコネクション名 | transactionName | String | 任意指定(デフォルト="transaction") | - -以下はDIリポジトリ設定ファイルへの記述例である。 -コミット間隔は運用状況等に応じて変更される可能性があるので、埋め込みパラメータとして定義しておくことを推奨する。 - -```xml - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-Main.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-Main.md deleted file mode 100644 index 847710e84..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-Main.md +++ /dev/null @@ -1,203 +0,0 @@ -## 共通起動ランチャ - -**クラス名:** `nablarch.fw.launcher.Main` - ------ - ------ - -### 概要 - -[共通起動ランチャ](../../component/handlers/handlers-Main.md) は本フレームワークの起動シーケンスの起点となるクラスであり、javaコマンドから直接起動することで、 -リポジトリの初期化を行い、そこに定義されたハンドラキューを実行させることができる。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| 共通起動ランチャ | nablarch.fw.handler.Main | CommandLine | Integer | Javaコマンドから直接実行することで、DIリポジトリを初期化し、ハンドラキューを構築・実行する。 | 後続ハンドラの処理結果(整数値)を終了コードに指定し、プロセスを停止する。 | Fatalログを出力しプロセスを異常終了させる。 | -| ステータスコード→プロセス終了コード変換 | nablarch.fw.handler.StatusCodeConvertHandler | CommandLine | Integer | - | 後続ハンドラの処理結果をもとに、プロセス終了コード(整数値)を決定して返す。 | - | -| グローバルエラーハンドラ | nablarch.fw.handler.GlobalErrorHandler | Object | Result | - | - | 全ての実行時例外・エラーを捕捉し、ログ出力を行う | -| スレッドコンテキスト変数設定ハンドラ(メインスレッド) | nablarch.common.handler.ThreadContextHandler_main | Object | Object | 起動引数の内容からリクエストID、ユーザID等のスレッドコンテキスト変数を初期化する。 | - | - | -| リクエストディスパッチハンドラ | nablarch.fw.handler.RequestPathJavaPackageMapping | Request | Object | 引数として渡されたリクエストオブジェクトのリクエストパスから、処理対象の業務アクションを決定しハンドラキューに追加する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [ステータスコード→プロセス終了コード変換ハンドラ](../../component/handlers/handlers-StatusCodeConvertHandler.md) | ハンドラキューの先頭に配置する。 [共通起動ランチャ](../../component/handlers/handlers-Main.md) では、このハンドラが返した整数値をプロセス終了コードとして使用する。 終了コードの体系はプロジェクト毎に異なる可能性があるので 必要に応じて差し替えられるよう、本クラスから責務を分離している。 | -| [グローバルエラーハンドラ](../../component/handlers/handlers-GlobalErrorHandler.md) | 後続のハンドラで発生した全ての実行時例外およびエラーはこのハンドラによって捕捉される。 [共通起動ランチャ](../../component/handlers/handlers-Main.md) では、このハンドラが [ステータスコード→プロセス終了コード変換ハンドラ](../../component/handlers/handlers-StatusCodeConvertHandler.md) の後続に 配置されていることを前提としている。 | -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | [共通起動ランチャ](../../component/handlers/handlers-Main.md) の起動引数 **-requestPath** および、 **-userId** の値をもとに、 スレッドコンテキスト変数の **リクエストID** および、 **ユーザID** の値をそれぞれ設定する。 | -| [リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) | [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) などでは、 [共通起動ランチャ](../../component/handlers/handlers-Main.md) の起動引数 **-requestPath** の値をもとに業務アクションクラスのディスパッチを 行う。 | - -### ハンドラ処理フロー - -本ハンドラの処理の流れは以下のとおりである。 - -> **Note:** -> 以下の説明において **異常終了する** と表現されている部分では、障害ログを出力してプロセスを終了させる。 - -**[往路処理]** - -**1. (起動引数の解析)** - -main関数に渡された起動引数をパースし、その結果をコマンドラインオブジェクト([CommandLine](../../javadoc/nablarch/fw/launcher/CommandLine.html))に設定する。 -起動引数の扱いについては、 [後述](../../component/handlers/handlers-Main.md#コマンドライン起動引数の扱い) する。 - -**2. (リポジトリの初期化)** - -**-diConfig** パラメータに指定されたリポジトリ定義ファイルの内容に沿って初期化を行なう。 -初期化が正常終了した場合は、下記のオブジェクトIDに登録されたオブジェクトを取得する。 - -| 論理名 | オブジェクトID | オブジェクトの型 | -|---|---|---| -| ハンドラキュー | **handlerQueue** | **List>** | -| データリーダ | **dataReader** | [DataReader](../../javadoc/nablarch/fw/DataReader.html) | -| データリーダファクトリ | **dataReaderFactory** | [DataReaderFactory](../../javadoc/nablarch/fw/DataReaderFactory.html) | - -**3. (実行コンテキストの構築)** - -実行コンテキスト([ExecutionContext](../../javadoc/nablarch/fw/ExecutionContext.html))を生成し、以下の処理を行う。 - -1. ハンドラキューを設定 -2. データリーダおよびデータリーダファクトリを設定 -3. セッションスコープ変数に、起動パラメータのMapを設定する。 - -**4. (ハンドラキューの実行)** - -ハンドラキュー上の最初のハンドラに対して、コマンドラインオブジェクトと実行コンテキストを引数として処理を委譲する。 -これにより、ハンドラキュー上の各ハンドラの処理が順次実行され、その処理結果オブジェクトが返される。 - -**[復路処理]** - -**5. (正常終了)** - -後続のハンドラが正常終了した場合、処理結果オブジェクトのステータスコードを終了コードとしてプロセスを終了させる。 -ただし、ステータスコードが127を越えていた場合の終了コードは127とする。 - -**[例外処理]** - -**1a. (必須パラメータ未指定エラー)** - -以下の必須パラメータのうちいずれかが指定されていなかった場合は異常終了する。(終了コード127) - -**-diConfig** 、 **-requestPath** 、 **-userId** - -**2a. (リポジトリ初期化エラー)** - -リポジトリ初期化時にエラーが発生した場合、もしくはハンドラキューが取得できな買った場合は異常終了する。 -(終了コード=127) - -**5a. (異常終了)** - -後続ハンドラの実行中に実行時例外およびエラーが送出された場合、 -それらを捕捉し、異常終了させる。(ステータスコード=127) - -> **Note:** -> 本ハンドラはグローバルエラーハンドラの手前に配置されるため、基本的にここで例外を捕捉することは無い - ------ - -### コマンドライン起動引数の扱い - -**起動引数の処理** - -本クラスにおける起動引数の扱いについて、以下の実行例をもとに解説する。 - -```bash -java \ - -server \ - -Xmx128m \ - -DcommitInterval=100 \ - -DmaxExecutionCount=100000 \ -nablarch.fw.launcher.Main \ - -diConfig file:./batch-config.xml \ - -requestPath admin.DataUnloadBatchAction/BC0012 \ - -userId testUser \ - -namedParam value \ - value1 value2 value3 -``` - -Javaコマンドに指定する引数は以下の3つに分類することができる。 -それぞれについて、本クラスでの取扱いについて述べる。 - -1. Java VMパラメータ -2. Javaシステムプロパティ -3. クラス引数 - -1. JavaVMパラメータ - -上記例中の **-server** や **-Xmx** はJavaVM自体の挙動に関するパラメータである。 -本フレームワークでこれらの値を直接使用することは無い。 - -1. Javaシステムプロパティ - -DIリポジトリ設定ファイル中の埋め込みパラメータの値は、Javaシステムプロパティを用いて指定することができる。 -上記の例では、 **-DcommitInterval=100** と **-DmaxExecutionCount=100000** がこれに相当し、それぞれ -埋め込みパラメータ **${commitInterval}** および **${maxExecutionCount}** の値を指定している。 - -1. クラス引数 - -本クラスに対する引数は、下記の形式に従ってパースし、 -後述するコマンドラインオブジェクト(nablarch.fw.launcher.Commandline)の属性値として設定する。 - -1. 名前付きパラメータ - -**書式**: - -``` -'-' + (パラメータ名) + '　' + (パラメータ値) -``` - -**アクセス方法**: - -``` -Commandline#getParamMap() : Map -``` - -**上記例で取得できる値** - -```javascript -{ diConfig : "file:./batch-config.xml", - requestPath: "nablarch.fw.sample.SampleBatchAction", - userId : "testUser", - namedParam : "value" } -``` - -1. 無名パラメータ - -**書式**: - -``` -(パラメータ値) -``` - -**アクセス方法**: - -``` -Commandline#getArgs() : List -``` - -**上記例で取得できる値** - -```javascript -[ "value1", "value2", "value3" ] -``` - -**必須パラメータ** - -フレームワークの動作に必要となる以下の3つのパラメータについては、起動パラメータとして必ず指定する必要がある。 - -| パラメータ | 内容 | -|---|---| -| **-diConfig** | リポジトリの設定ファイルのパスを指定する。 | -| **-requestPath** | 以下の書式で定義される文字列を設定する。: ``` (実行対象アクションハンドラクラス) + '/' + (リクエストID値) ``` この値はコマンドラインオブジェクトに設定され、以下のハンドラで使用される。 * [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) * [リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) | -| **-userId** | プロセスの実行権限ユーザIDを設定する。 この値はセッションコンテキスト変数に格納される。 また、後続の [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) によってスレッドコンテキストに保持されることで、 ハンドラ以外の任意のコンポーネントからアクセスできるようになる。 (権限制御と関係なく、何らかの識別文字列を設定する必要がある。) | - -上記の必須パラメータのうちいずれかが欠けていた場合は、即座に異常終了する。(終了コード = 127) - -### 設定項目・拡張ポイント - -本クラスはJavaコマンドラインから直接実行するため、固有の設定項目は存在しない。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessageReplyHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessageReplyHandler.md deleted file mode 100644 index 0578a151a..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessageReplyHandler.md +++ /dev/null @@ -1,103 +0,0 @@ -## 電文応答制御ハンドラ - -**クラス名:** `nablarch.fw.messaging.handler.MessageReplyHandler` - ------ - -### 概要 - -本ハンドラでは、後続ハンドラの処理結果である [ResponseMessage](../../javadoc/nablarch/fw/messaging/ResponseMessage.html) オブジェクトの内容を -もとに応答電文を構築し送信する。 -送信した応答電文オブジェクトをこのハンドラの戻り値として返す。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| メッセージングコンテキスト管理ハンドラ | nablarch.fw.messaging.handler.MessagingContextHandler | Object | Object | メッセージングコンテキスト(MQ接続)を取得し、スレッドローカルに保持する。 | メッセージングコンテキストを開放する。（プールに戻す） | メッセージングコンテキストを開放する。（プールに戻す） | - | -| 電文応答制御ハンドラ | nablarch.fw.messaging.handler.MessageReplyHandler | Object | ResponseMessage | - | 後続ハンドラから返される応答電文オブジェクトの内容をもとに電文を作成して送信する。 | エラーオブジェクトの内容をもとに電文を作成して送信する。 | - | -| データリードハンドラ(FW制御ヘッダリーダ/メッセージリーダ利用) | nablarch.fw.handler.DataReadHandler_messaging | Object | Result | 要求電文を受信しFW制御ヘッダ部を解析して要求電文オブジェクト(RequestMessage)を作成し後続のハンドラに渡す。また、FW制御ヘッダのrequestId/userIdの値をメッセージコンテキストに設定する。 | - | - | - | -| トランザクション制御ハンドラ | nablarch.fw.common.handler.TransactionManagementHandler | Object | Object | 業務トランザクションの開始 | トランザクションをコミットする。 | トランザクションをロールバックする。 | 1.コミット完了後 / 2.ロールバック後 | - -**関連するハンドラ** - -応答電文の内容を編集する必要のあるハンドラは、全てこのハンドラの後続に配置する必要がある。 - -| ハンドラ | 内容 | -|---|---| -| [メッセージングコンテキスト管理ハンドラ](../../component/handlers/handlers-MessagingContextHandler.md) | 本ハンドラでは、スレッドローカル上のメッセージングコンテキストを用いて 応答電文の送信を行なうので、本ハンドラより上位に配置する必要がある。 | -| [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) | 同ハンドラとの前後関係は、2相コミットを使用するか否かで変わる。 **a)** 2相コミットを使用する場合。 DBトランザクションとJMSトランザクションをトランザクションマネージャー側で まとめてコミットするので、トランザクション制御ハンドラは、このハンドラより 先に実行されなければならない。 **b)** 2相コミットを使用しない場合。 このハンドラが応答を送信する前に、DBトランザクション終了させ、 業務処理の結果を確定させる必要がある。 このため、トランザクション制御ハンドラはこのハンドラの後に実行されなければならない。 | -| [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) | 要求電文のフォーマット不正に起因する例外はデータリーダ上で発生する可能性がある。 そのエラー応答電文をこのハンドラで送信するためには、 [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) を本ハンドラの後続に配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (後続ハンドラの実行)** - -本ハンドラは往路において特段の処理を行なわずに後続のハンドラに処理を委譲し、 -その処理結果を取得する。 - -**[復路処理]** - -**2. (応答電文オブジェクトの取得)** - -**1.** での処理結果の型が応答電文オブジェクト([ResponseMessage](../../javadoc/nablarch/fw/messaging/ResponseMessage.html)) であった場合は、 -処理結果を応答電文オブジェクトにキャストして以降の処理で用いる。 - -**2a. (受信待機タイムアウト)** - -キュー上に取得対象電文が存在しないまま、データリーダが一定時間待機し続けた場合、 [DataReader.NoMoreRecord](../../javadoc/nablarch/fw/DataReader.NoMoreRecord.html) が返される。 -**1.** の処理結果がこの型であった場合は、応答処理は行なわずに、処理結果をそのままリターンして終了する。 - -**2b. (処理結果タイプエラー)** - -**1.** での処理結果の型が、応答電文オブジェクトでも [DataReader.NoMoreRecord](../../javadoc/nablarch/fw/DataReader.NoMoreRecord.html) でも無かった場合は、 -実行時例外 (java.lang.ClassCastException) を送出する。 - -**3. (処理結果コードの設定)** - -フレームワーク制御ヘッダ中の処理結果コードが未設定であった場合は、処理結果オブジェクトのステータスコードを設定する。 - -**4. (メッセージ送信)** - -スレッドローカル上のメッセージコンテキストを使用して、応答電文オブジェクトの送信(応答キューへのPUT)を行なう。 - -**5. (正常終了)** - -応答電文オブジェクトをリターンする。 - -**5a. (エラー応答正常終了)** - -ただし、後続ハンドラの処理で例外が送出されていた場合( **2c.** )は、その例外を再送出する。 - -**[例外処理]** - -**2c. (エラー応答電文作成)** - -後続ハンドラの処理中に実行時例外/エラーが発生した場合、 -エラー内容をもとに応答電文を作成し、それを **3.** 以降で使用する。 -なお、元例外は本ハンドラの処理終了時に再送出する。 - -**4a. (応答電文送信エラー)** - -送信処理中に例外が送出された場合は、送信元に対する応答を断念し、例外を再送出して終了する。 - -**4b. (エラー応答電文送信エラー)** - -送信処理中に例外が送出され、それ以前に、後続ハンドラの処理でも例外が送出されていた( **2c.** )場合、 -送信処理中に発生した例外についてはワーニングレベルのログとして出力した上で、 -**2c.** で捕捉していた例外を再送出する。 - -### 設定項目・拡張ポイント - -本ハンドラに設定項目は設けられていない。 - -**標準設定** - -```xml - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessageResendHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessageResendHandler.md deleted file mode 100644 index 3e43954f4..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessageResendHandler.md +++ /dev/null @@ -1,212 +0,0 @@ -## 再送電文制御ハンドラ - -**クラス名:** `nablarch.fw.messaging.handler.MessageResendHandler` - -### 概要 - -応答電文の再送処理制御を行うハンドラ。 - -一般に、外部システムに対する要求電文がタイムアウトした場合、 -再送要求電文や、取消電文といった補償電文を送信することがある。 - -本ハンドラではこのうち、再送要求に対する制御をフレームワークレベルで実装している。 -初回電文/再送要求電文の判定は [フレームワーク制御ヘッダ](../../component/libraries/libraries-enterprise-messaging.md#基本概念) 上の **再送要求フラグ** の値を用いて行う。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| 電文応答制御ハンドラ | nablarch.fw.messaging.handler.MessageReplyHandler | Object | ResponseMessage | - | 後続ハンドラから返される応答電文オブジェクトの内容をもとに電文を作成して送信する。 | エラーオブジェクトの内容をもとに電文を作成して送信する。 | - | -| データリードハンドラ(FW制御ヘッダリーダ/メッセージリーダ利用) | nablarch.fw.handler.DataReadHandler_messaging | Object | Result | 要求電文を受信しFW制御ヘッダ部を解析して要求電文オブジェクト(RequestMessage)を作成し後続のハンドラに渡す。また、FW制御ヘッダのrequestId/userIdの値をメッセージコンテキストに設定する。 | - | - | - | -| トランザクション制御ハンドラ | nablarch.fw.common.handler.TransactionManagementHandler | Object | Object | 業務トランザクションの開始 | トランザクションをコミットする。 | トランザクションをロールバックする。 | 1.コミット完了後 / 2.ロールバック後 | -| 再送電文制御ハンドラ | nablarch.fw.messaging.handler.MessageResendHandler | RequestMessage | ResponseMessage | 再送要求に対し、以前応答した電文が保存されていれば、その内容をリターンする。(後続ハンドラは実行しない) | 業務トランザクションが正常終了(コミット)された場合のみ電文を保存する | - | - | -| 同期応答電文処理用業務アクションハンドラ | nablarch.fw.action.MessagingAction | RequestMessage | ResponseMessage | 要求電文の内容をもとに業務処理を実行する。 | 業務処理の結果と要求電文の内容から応答電文の内容を作成して返却する。 | - | トランザクションロールバック時にエラー応答電文を作成する。 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [電文応答制御ハンドラ](../../component/handlers/handlers-MessageReplyHandler.md) | 本ハンドラの作成した再送電文オブジェクトは、 [電文応答制御ハンドラ](../../component/handlers/handlers-MessageReplyHandler.md) によって送信される。 | -| [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) | 送信済み電文は、業務トランザクションと同じトランザクションでコミットするので、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) の後続にこのハンドラを配置する。 | -| [同期応答電文送信処理用業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-MessagingAction.md) | 本ハンドラでは、業務アクションが応答した電文オブジェクトを応答済み電文テーブルに 保存する。 | - ------ - -**再送制御** - -本システムに対する処理要求メッセージ(初回電文)が、転送経路上のネットワークエラーや -遅延により外部システム側でタイムアウトし、その補償電文として再送要求電文が送信されたとする。 -この際、再送要求電文を受信した時点でのシステムの状態は、以下の4つに分類できる。 - -1. ネットワークエラーもしくは遅延により、初回電文が未受信。 -2. 初回電文を処理中。 -3. 初回電文に対する業務処理は正常終了(トランザクションをコミット)したが、 - ネットワークエラーもしくは遅延により応答電文が未達。 -4. 初回電文に対する業務処理が異常終了(トランザクションをロールバック)し、 - ネットワークエラーもしくは遅延によりエラー応答電文が未達。 - -それぞれのケースについて、本システムの挙動は以下のようになる。 - -1. 初回電文が未受信 - 再送要求電文を初回電文として処理する。 - この場合、再送要求電文を処理中に、遅延していた初回電文を並行実行する可能性があるが - 先にコミットされたトランザクションのみ正常終了し、それ以外はロールバックする。 - また、ロールバックされた要求の応答として、先に正常終了した電文の応答を再送する。 -2. 本システムで初回電文を処理中 - 再送要求電文も初回電文として処理し、先に完了したトランザクションをコミットし、 - もう一方をロールバックする。 - (1.と同じ扱い。) -3. 業務処理は正常終了したが応答電文が未達 - 再送用電文テーブルから当該メッセージIDの電文データを取得し、応答電文として送信する。 - 業務処理は実行されない。 -4. 業務処理が正常終了したがエラー応答電文が未達 - 再送要求電文を初回電文として処理する。 - -本機能は大きく以下の2つの機能によって構成されている。 - -**1. 再送応答機能** - -接続先システムから再送要求電文が送信された場合に、 -後述の送信済電文保存機能が保持する過去の応答電文の内容を再送信する機能。 - -**2. 送信済電文保存機能** - -送信に成功した(=ローカルキューに対するPUT命令が完了した)メッセージの内容をデータベース上の -送信済電文テーブルに保存する機能。 -送信済電文の内容は業務トランザクションとともにコミットされる。 -従って、業務処理がエラー終了した場合には再送用電文は残らない。 - -再送電文管理テーブルのスキーマ構造として、以下のようなテーブル構造を想定している。 - -| 論理名 | データ型 | -|---|---| -| メッセージID | VARCHAR PK | -| リクエストID | VARCHAR PK | -| 応答宛先キュー | VARCHAR | -| 処理結果コード | VARCHAR | -| 電文データ部 | BLOB | - -下にデフォルト設定でのテーブル名、カラム名に沿ったテーブルスキーマのサンプルを示す。 - -```sql -CREATE TABLE SENT_MESSAGE ( - MESSAGE_ID VARCHAR(64) -, REQUEST_ID VARCHAR(64) -, REPLY_QUEUE VARCHAR(64) -, STATUS_CODE CHAR(4) -, BODY_DATA BLOB -, CONSTRAINT pk_SENT_MESSAGE - PRIMARY KEY(MESSAGE_ID, REQUEST_ID) -); -``` - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (再送要求フラグの取得)** - -要求電文のフレームワーク制御ヘッダ中の再送要求フラグ(resendFlag)を取得する。 - -**1a. (再送要求フラグを使用しない電文のスキップ)** - -要求電文のフレームワーク制御ヘッダに再送要求フラグが定義されていなかった場合、 -本ハンドラではなにもせず、後続のハンドラに処理を移譲し、その結果を返して終了する。 - -**2. (再送応答)** - -要求電文中のメッセージIDとリクエストIDをキーとして送信済電文テーブルを検索し、 -条件に合致する送信済電文が存在した場合は、その内容に沿って [ResponseMessage](../../javadoc/nablarch/fw/messaging/ResponseMessage.html) を作成し、 -それを返して終了する。この場合、後続ハンドラへの処理移譲は行なわずに折り返すため -業務処理は実行されない。 - -**2a. (初回電文の処理が未完→再送要求を初回電文として実行)** - -条件に合致する送信済電文が存在しない場合は、後続のハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**3. (正常終了)** - -後続のハンドラから返された応答電文を送信済電文テーブルに保存した後、応答電文を返す。 - -**[例外処理]** - -**3a. (並行に処理された電文の応答を再送)** - -応答電文を保存した際に、一意制約違反エラーが発生した場合は、並行するトランザクションによって -既に正常終了しているため、送信済電文テーブルから応答電文を取得して返す。 - -**3c. (エラー応答1)** - -一意制約違反エラーが発生したにも関わらず、送信済み電文テーブルに送信電文が登録されていない場合は、 -元例外を再送出する。(通常は発生しえない。) - -**4. (エラー応答2)** - -上記以外のケースで発生した実行時例外・エラーについては、このハンドラでは捕捉せず、 -上位のハンドラに再送出される。 - -### 設定項目・拡張ポイント - -* **基本設定** - - 要求電文から再送要求フラグを取得する際にフレームワーク制御ヘッダー定義を使用するため、 - 必ず設定する必要がある。 - 下記の例では、フレームワーク標準のヘッダー定義を使用している。 - - ```xml - - - - - - - - - - ``` -* **テーブル名、カラム名の変更** - - 命名規約や既存システムとの整合性の確保などの理由により、、 - デフォルト設定とは異なるテーブル名、カラム名を利用する必要がある場合は以下のように設定する。 - - ```xml - - - - - - - - - - - - - - ``` -* **再送要求フラグ定義方法の変更** - - デフォルトの設定での再送要求フラグの仕様が、プロジェクトの要件に合致しない場合は、 - フレームワーク制御ヘッダー定義を拡張する必要がある。 - - フレームワーク制御ヘッダー定義の拡張については、「フレームワーク制御ヘッダリーダ」の項を参照すること。 - - ```xml - - - - - - - - - - ``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessagingAction.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessagingAction.md deleted file mode 100644 index 5a1b5ef1d..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessagingAction.md +++ /dev/null @@ -1,102 +0,0 @@ -## 同期応答電文送信処理用業務アクションハンドラのテンプレートクラス - -**クラス名:** `nablarch.fw.action.MessagingAction` - ------ - -### 概要 - -本クラスは、 [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) における -業務アクションハンドラを実装する際に使用するテンプレートクラスである。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| 同期応答電文処理用業務アクションハンドラ | nablarch.fw.action.MessagingAction | RequestMessage | ResponseMessage | 要求電文の内容をもとに業務処理を実行する。 | 業務処理の結果と要求電文の内容から応答電文の内容を作成して返却する。 | - | トランザクションロールバック時にエラー応答電文を作成する。 | - ------ - -本クラスを継承してアクションハンドラを実装するには、以下のテンプレートメソッドを必要に応じて実装する。 - -| メソッド名 | 内容 | -|---|---| -| onReceive() | (必須実装) 本ハンドラの往路処理の中で呼ばれる。 要求電文オブジェクト( [RequestMessage](../../javadoc/nablarch/fw/messaging/RequestMessage.html) )の内容をもとに業務処理を実行し、 応答電文オブジェクト( [ResponseMessage](../../javadoc/nablarch/fw/messaging/ResponseMessage.html) )に応答電文の内容を格納してリターンする。 | -| onError() | (任意実装) 業務トランザクションがロールバックされた時点で、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) からコールバックされる。 エラー応答電文を作成してリターンする。 オーバーライドしなかった場合は、FW制御ヘッダのみが設定された電文がエラー応答として 送信される。 | -| usesAutoRead() | (任意実装) 要求電文のデータ部の読込みを自動で行うか否かを指定する。 要求電文のデータ部がマルチレコード/マルチフォーマット構成である場合は、 このメソッドをオーバーライドしてfalseをリターンすることで、 データ部の解析を手動で行うことができる。 | - -以下のソースコードは、フレームワークが本クラスの各テンプレートメソッドを -どのタイミングで呼び出すかを表したものである。 - -```java -RequestMessage req; -ResponseMessage res; -ExecutionContext ctx; - -req = receive(); // (フレームワークが要求電文を受信) - -try { - if ( usesAutoRead() ) { - req.readRecord(); // 要求電文のデータ部からデータレコードを自動的に読み込む。 - // (主にシングルレコード形式の電文で使用する。) - } - - res = onReceive(req, ctx); // 要求電文毎に呼ばれる。 - commit(); // (フレームワークが業務トランザクションをコミットする。) - -} catch(e) { - rollback(); // (業務トランザクションをロールバックする。) - res = onError(e, req, ctx); // 業務処理で例外が発生し、業務トランザクションが - // ロールバックされた直後に呼ばれる。 - // エラー応答電文をリターンして返す。 -} finally { - send(res); // (フレームワークが応答電文を送信) -} -``` - -> **Note:** -> このコードはあくまで説明用に単純化したものであり、実際の処理フローはこのようなロジックでは無く、 -> ハンドラ構成によって制御されており、全く別物である。 - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (業務データ部の自動読み込み)** - -**usesAutoRead()** を実行し、その結果が **true** であった場合は、 -[RequestMessage](../../javadoc/nablarch/fw/messaging/RequestMessage.html) の **readRecord()** メソッドを呼び出し、 -要求電文内の業務データレコードの読み込みを行なう。 - -ここで読み込まれたデータレコードの内容は、 **getParamMap()** 等のメソッドにより、 -レコードのフィールド名をキーとするMapとしてアクセスすることができる。 - -**2. (業務ロジックの実行)** - -要求電文オブジェクトと実行コンテキストを引数として、 **onReceive()** メソッドを実行し、 -その結果(応答電文オブジェクト)を取得する。 - -**[復路処理]** - -**3. (正常終了)** - -**2.** で作成した応答電文オブジェクトをリターンし終了する。 - -**[例外処理]** - -**1a. (データ終端エラー)** - -要求電文内のデータレコードを読み込んだ時点で、データ部の終端に達しなかった場合は、 -実行時例外( [InvalidDataFormatException](../../javadoc/nablarch/core/dataformat/InvalidDataFormatException.html) )を送出する。 - -> **Note:** -> 電文内に複数のレコードが格納されうる場合は、 **usesAutoRead()** をオーバライドし、falseを返すこと。 - -**[コールバック]** - -**4. (エラー応答電文の制御)** - -本ハンドラでの処理終了後、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) で業務トランザクションがロールバックされた場合、 -**onError()** メソッドを実行し、その結果(エラー応答電文オブジェクト)を返す。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessagingContextHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessagingContextHandler.md deleted file mode 100644 index 66df2c28a..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MessagingContextHandler.md +++ /dev/null @@ -1,84 +0,0 @@ -## メッセージングコンテキスト管理ハンドラ - -**クラス名:** `nablarch.fw.messaging.handler.MessagingContextHandler` - ------ - -### 概要 - -メッセージングコンテキストの管理を行うハンドラ。 - -リクエストスレッド毎にメッセージングコンテキスト初期化とスレッドローカル変数への格納、 -および終端処理を行う。 -メッセージングコンテキストをはじめとする、本フレームワークのメッセージング機能の内容については、 -[システム間メッセージング機能](../../component/libraries/libraries-enterprise-messaging.md) を参照すること。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| マルチスレッド実行制御ハンドラ | nablarch.fw.handler.MultiThreadExecutionHandler | Object | MultiStatus | サブスレッドを作成し、後続ハンドラの処理を並行実行する。 実行コンテキスト上にデータリーダが存在しない場合は、コールバックを行う。 | 全スレッドの正常終了まで待機する。 | 処理中のスレッドが完了するまで待機し起因例外を再送出する。 | 1. 処理開始前 / 2. データリーダ作成 / 3. スレッド異常終了時 / 4. 処理完了時 | -| メッセージングコンテキスト管理ハンドラ | nablarch.fw.messaging.handler.MessagingContextHandler | Object | Object | メッセージングコンテキスト(MQ接続)を取得し、スレッドローカルに保持する。 | メッセージングコンテキストを開放する。（プールに戻す） | メッセージングコンテキストを開放する。（プールに戻す） | - | -| 電文応答制御ハンドラ | nablarch.fw.messaging.handler.MessageReplyHandler | Object | ResponseMessage | - | 後続ハンドラから返される応答電文オブジェクトの内容をもとに電文を作成して送信する。 | エラーオブジェクトの内容をもとに電文を作成して送信する。 | - | -| データリードハンドラ(FW制御ヘッダリーダ/メッセージリーダ利用) | nablarch.fw.handler.DataReadHandler_messaging | Object | Result | 要求電文を受信しFW制御ヘッダ部を解析して要求電文オブジェクト(RequestMessage)を作成し後続のハンドラに渡す。また、FW制御ヘッダのrequestId/userIdの値をメッセージコンテキストに設定する。 | - | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) (MessageReader使用時) | メッセージ受信処理では、 [受信電文リーダ](../../component/readers/readers-MessageReader.md) を使用して受信電文の読み込みを行うが、この際、 本ハンドラが初期化するメッセージングコンテキストを使用する。 そのため、 [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) は本ハンドラの後続に配置する必要がある。 | -| [電文応答制御ハンドラ](../../component/handlers/handlers-MessageReplyHandler.md) | メッセージ応答処理で、本ハンドラが初期化するメッセージングコンテキストを 使用するため、 [電文応答制御ハンドラ](../../component/handlers/handlers-MessageReplyHandler.md) は、 本ハンドラの後続に配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (メッセージングコンテキストの取得)** - -本ハンドラに設定された **メッセージングプロバイダ** からメッセージングコンテキストを取得する。 - -**2. (メッセージングコンテキストをスレッドローカルに設定)** - -**1.** で取得したインスタンスを、スレッドローカルに保持する。 - -**3. (後続ハンドラへの処理委譲)** - -ハンドラキュー上の後続ハンドラに対して処理を委譲し、その結果を取得する。 - -**[復路での処理]** - -**4. (終端処理)** - -メッセージコンテキストをクローズすることで、使用していたメッセージングサーバへの接続をコネクションプールに返却し、 -スレッドローカル上からメッセージングコンテキストへの参照を除去する。 - -**5. (正常終了)** - -**3.** での処理結果をリターンし、終了する。 - -**[例外処理]** - -**3a. (終端処理)** - -本ハンドラ、および後続ハンドラの処理中に実行時例外/エラーが発生した場合でも、 -**4.** の終端処理を実行してからエラーを再送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 -メッセージングプロバイダの設定については、 [システム間メッセージング機能](../../component/libraries/libraries-enterprise-messaging.md) を参照すること。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| メッセージングプロバイダ | messagingProvider | MessagingProvider | 必須指定 | - -**標準設定** - -```xml - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MultiThreadExecutionHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MultiThreadExecutionHandler.md deleted file mode 100644 index fee2cd250..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MultiThreadExecutionHandler.md +++ /dev/null @@ -1,134 +0,0 @@ -## マルチスレッド実行制御ハンドラ - -**クラス名:** `nablarch.fw.MultiThreadExecutionHandler` - ------ - ------ - -### 概要 - -本ハンドラでは、サブスレッドを作成し、ハンドラキュー上の後続ハンドラの処理を各サブスレッド上で並行実行することができる。 -このハンドラでの処理結果は、各サブスレッドでの実行結果を集約したオブジェクト([Result.MultiStatus](../../javadoc/nablarch/fw/Result.MultiStatus.html))となる。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| マルチスレッド実行制御ハンドラ | nablarch.fw.handler.MultiThreadExecutionHandler | Object | MultiStatus | サブスレッドを作成し、後続ハンドラの処理を並行実行する。 実行コンテキスト上にデータリーダが存在しない場合は、コールバックを行う。 | 全スレッドの正常終了まで待機する。 | 処理中のスレッドが完了するまで待機し起因例外を再送出する。 | 1. 処理開始前 / 2. データリーダ作成 / 3. スレッド異常終了時 / 4. 処理完了時 | - -**コールバック** - -下記の抽象クラス／インターフェースを後続のハンドラで継承／実装することにより、本ハンドラ実行中にコールバックを受けることができる。 - -| 抽象クラス／インターフェース | メソッド | イベント | -|---|---|---| -| [BatchActionBase](../../javadoc/nablarch/fw/action/BatchActionBase.html) | initialize | マルチスレッド実行開始前一度だけ呼ばれる。 | -| | error | サブスレッドのいずれかが異常終了(未捕捉の実行時例外またはエラーを送出) した場合に一度だけ呼ばれる。 | -| | terminate | サブスレッド上の処理完了後に一度だけ呼ばれる。 (異常終了時では、error後に呼ばれる。) | -| [DataReaderFactory](../../javadoc/nablarch/fw/DataReaderFactory.html) | createReader | 実行コンテキスト上にデータリーダが設定されていなかった場合は、 BatchActionBase#initialize() の呼び出し直後に一度だけ呼ばれる。 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [バッチ処理用業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-BatchAction.md) | バッチアクションでは、本ハンドラのコールバックを利用することで、 バッチの初期処理及び終了処理を実装している。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (並行実行スレッド数をスレッドコンテキストに登録)** - -このハンドラに設定されている **並行実行スレッド数** をスレッドコンテキストの属性値として登録する。 -この値は後続処理において、シングルスレッド環境でしか利用できない機能の実行可否を判定する際に参照する。 - -**2. (コールバック呼び出し)** - -後続ハンドラの内、 **BatchActionBase** を継承しているものについて、下記のコールバックを呼び出す。: - -``` -BatchActionBase#initialize(Object data, ExecutionContext context): Object -``` - -**3. (データリーダを取得)** - -サブスレッドで使用するデータリーダを実行コンテキスト([ExecutionContext](../../javadoc/nablarch/fw/ExecutionContext.html))から取得する。 -データリーダが実行コンテキストに設定されていなかった場合は、データリーダファクトリを使用して -データリーダを作成する。 - -**3a. (データリーダ未設定エラー)** - -実行コンテキスト上にデータリーダ及びデータリーダファクトリのいずれも設定されていなかった場合、 -実行時例外([IllegalStateException](http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/IllegalStateException.html))を送出する。 - -**4. (実行コンテキストのコピー)** - -各サブスレッドで使用する実行コンテキストを、現在の実行コンテキストをもとに作成する。 -この際、実行コンテキストの各属性は以下のように複製される。 - -| 属性名 | データ型 | コピーされる内容 | -|---|---|---| -| ハンドラキュー | List<[Handler](../../javadoc/nablarch/fw/Handler.html) > | 現在のListのシャローコピーを作成する。 従って、各ハンドラはスレッドセーフに作成される必要がある。 | -| リクエストコンテキスト | Map | 新規のMapを作成する。 メインスレッド側の変数はサブスレッドに引き継がれない。 | -| セッションコンテキスト | Map | 現在のセッションスコープのMapをそのまま設定する。 各サブスレッドは、単一のMapを共有する。 | -| データリーダ | [DataReader](../../javadoc/nablarch/fw/DataReader.html) | 現在のデータリーダをそのまま設定する。 | -| データリーダファクトリ | [DataReaderFactory](../../javadoc/nablarch/fw/DataReaderFactory.html) | 現在のファクトリをそのまま設定する。 | - -**5. (サブスレッドの作成と実行)** - -サブスレッドを作成し実行する。 -各サブスレッドでは、 **4.** で作成した実行コンテキスト中のハンドラキューに処理を委譲し、その結果をサブスレッドの実行結果として -メインスレッドに返す。 -メインスレッドは全てのサブスレッドが終了するまで待機する。 - -**[復路処理]** - -**6. (コールバック呼び出し)** - -後続ハンドラの内、 **BatchActionBase** を継承しているものについて、下記のコールバックを呼び出す。: - -``` -BatchActionBase#terminate(Object data, ExecutionContext context): Object -``` - -**7. (正常終了)** - -各サブスレッドの処理結果を [Result.MultiStatus](../../javadoc/nablarch/fw/Result.MultiStatus.html) に追加してリターンする。 - -**[例外処理]** - -**5a. (サブスレッドが異常終了)** - -サブスレッド上のいずれかが異常終了(=未捕捉の実行時例外またはエラーを送出)した場合、 -後続ハンドラの内、 **BatchActionBase** を継承しているものについて、下記のコールバックを呼び出す。: - -``` -BatchActionBase#error(Throwable e, ExecutionContext context): void -``` - -次に、現在実行中の各サブスレッド対して割り込み要求をおこなった上で、 -全サブスレッドが完了するか、 **スレッド停止タイムアウト** を経過するまで待機する。 -最後に **6.** のコールバックを呼び出した上で、起因例外を再送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 並行実行スレッド数 | concurrentNumber | int | デフォルト値は1 | -| スレッド停止のタイムアウト秒数 | terminationTimeout | int | デフォルト値は600(秒) | - -**基本設定** - -以下は標準的なスレッドコンテキストの設定例である。 -並行実行スレッド数は、運用時に値を変更する可能性が高い為、 -埋め込みパラメータとして定義することを推奨する。 - -```xml - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MultipartHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MultipartHandler.md deleted file mode 100644 index c806b88b1..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-MultipartHandler.md +++ /dev/null @@ -1,133 +0,0 @@ -## マルチパートリクエストハンドラ - -**クラス名:** `nablarch.fw.web.upload.MultipartHandler` - ------ - ------ - -### 概要 - -本ハンドラは、HTTPリクエストボディがマルチパート形式であった場合にその内容を解析し、一時ファイルに保存する。 -保存されたファイルは、アップロード用ユーティリティを使用することで、業務アクションハンドラから参照することが可能となる。 - -![MultipartHandler.png](../../../knowledge/assets/handlers-MultipartHandler/MultipartHandler.png) - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTPレスポンスハンドラ | nablarch.fw.web.handler.HttpResponseHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容に沿ってレスポンス処理かサーブレットフォーワードのいずれかを行う。 | 既定のエラー画面をレスポンス後、例外を再送出する。ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 | -| HTTPエラー制御ハンドラ | nablarch.fw.web.handler.HttpErrorHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容が設定されていない場合は、ステータスコードに応じたデフォルトページを遷移先に設定する。 | 送出されたエラーに応じた遷移先のHTTPレスポンスオブジェクトを返却する。送出されたエラーはリクエストスコープに設定される。 | -| マルチパートリクエストハンドラ | nablarch.fw.web.upload.MultipartHandler | HttpRequest | HttpResponse | HTTPリクエストボディがマルチパート形式であった場合にその内容を解析し、一時ファイルに保存する。 | アップロードされた一時ファイルを全て削除する。 | アップロードされた一時ファイルを全て削除する。 | -| Nablarchカスタムタグ制御ハンドラ | nablarch.common.web.handler.NablarchTagHandler | HttpRequest | HttpResponse | Nablarchカスタムタグの動作に必要な事前処理を実施する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [HTTPエラー制御ハンドラ](../../component/handlers/handlers-HttpErrorHandler.md) | 本ハンドラでは、アップロードされたファイルが許容上限サイズを越えた場合などに 例外が送出される可能性があるので、 [HTTPエラー制御ハンドラ](../../component/handlers/handlers-HttpErrorHandler.md) の後続に配置し、 適切なエラー画面が表示されるようにする必要がある。 | -| [Nablarchカスタムタグ制御ハンドラ](../../component/handlers/handlers-NablarchTagHandler.md) | このハンドラでは、HTTPリクエストオブジェクトのリクエストパラメータを使用するので、 POSTパラメータの解析の際にリクエストボディが読み込まれる。 そのため、本ハンドラを [Nablarchカスタムタグ制御ハンドラ](../../component/handlers/handlers-NablarchTagHandler.md) よりも上位に配置する必要がある。 | - -> **Note:** -> 一般に、HTTPリクエストのリクエストボディの読みこみを行うハンドラは、必ず [マルチパートリクエストハンドラ](../../component/handlers/handlers-MultipartHandler.md) -> の後続に配置する必要がある。 - -> 具体的には、 [HTTPアクセスログハンドラ](../../component/handlers/handlers-HttpAccessLogHandler.md) を拡張し、特定のリクエストパラメータを出力するケースや、 -> [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) にリクエストパラメータの内容に依存したカスタムの属性を追加するようなケースがこれに該当する。 - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (非マルチパートリクエストのスキップ)** - -HTTPリクエストのCONTENT-TYPEヘッダー値を取得し、 **"multipart/form-data"** に一致しない場合は、 -このハンドラでは何もせずに、後続のハンドラの実行結果をリターンして終了する。 - -**2. (マルチパートリクエストの解析)** - -HTTPリクエストオブジェクトのメッセージボディを読み込み、マルチパートの解析を行い、アップロードされたファイルを -一時ファイルとして保存する。 -保存先は、論理パス名 **"uploadFileTmpDir"** に設定されたパスとなる。 -また、論理パスが設定されていない場合は、OS標準の一時ファイル保存先(Javaシステムプロパティ **"java.io.tmpdir"** の値)となる。 - -解析結果は、HTTPリクエストオブジェクト自体に格納され、アップロードファイルに関する情報は [HttpRequest.getPart()](../../javadoc/nablarch/fw/web/HttpRequest.html#getPart(java.lang.String)) で取得できる。 -また、アップロードファイル以外のパラメータについては、通常どおり [HttpRequest.getParam()](../../javadoc/nablarch/fw/web/HttpRequest.html#getParam(java.lang.String)) 等で取得できる。 - -**3. (ログ出力)** - -アップロードされたファイルに関する情報をログに出力する。(INFOレベル) - -**4. (後続ハンドラに対する処理委譲)** - -ハンドラキュー上の後続ハンドラに対して処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**5. (終端処理)** - -アップロードされた一時ファイルを全て削除する。 - -**6. (正常終了)** - -**4.** の結果をリターンして終了する。 - -**2a. (マルチパート形式エラー)** - -アップロード中に、接続が切断されるなどの事由により、読み込んだリクエストボディの内容がマルチパートフォーマットに反した場合は、 -実行時例外 [Result.BadRequest](../../javadoc/nablarch/fw/Result.BadRequest.html) を送出して終了する。(ステータスコード400) - -**2b. (アップロード上限超過エラー)** - -読み込んだデータのサイズが本ハンドラに設定されたアップロードサイズの上限値を超過した場合は、 -実行時例外 [Result.BadRequest](../../javadoc/nablarch/fw/Result.BadRequest.html) を送出して終了する。(ステータスコード413) - -**[例外処理]** - -**4a. (終端処理)** - -後続ハンドラの処理中に何らかの例外が発生した場合は、 **5.** の終端処理を実行し、例外を再送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定値は、 [UploadSettings](../../javadoc/nablarch/fw/web/upload/UploadSettings.html) に集約されており、その内容は以下の通りである。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| アップロードサイズ上限 | contentLengthLimit | int | 任意設定。(単位:バイト) 1リクエストでアップロードできるデータの上限値 (ファイルサイズの上限ではない。) デフォルトは無制限。 | -| 一時ファイル自動削除の実施有無 | autoCleaning | boolean | 任意指定。デバッグや障害解析用に無効化する。 デフォルトはtrue(自動削除を実施) > **Note:** > 一時ファイル保存中に例外が発生した場合には、 > 自動削除の設定がオフの場合でもファイルを削除する。 > これにより、不正な状態のファイル（空ファイルや途中まで > 保存されたファイル）が作成されることを防ぐことが出来る。 > ※一時ファイルが正常に保存でき、後続のハンドラに処理が > 移譲できた場合には、自動削除がオンの場合のみファイルを削除する。 | - -**基本設定** - -アップロードサイズの上限値を定めておくことを強く推奨する。 -また、上限値はユーザ要望等の事由によって変更になる可能性があるので、設定パラメータとして外部化しておくこと。 - -```xml - - - - - - - - -``` - -**アップロードファイルの一時保存先の設定** - -アップロードされたファイルの一時保存先を指定する場合は、論理パス名 **"uploadFileTmpDir"** を使用すること。 -保存先のパスは環境依存値となるので、設定パラメータとして外部化しておくこと。 - -```xml - - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NablarchServletContextListener.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NablarchServletContextListener.md deleted file mode 100644 index 5dc9d49ae..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NablarchServletContextListener.md +++ /dev/null @@ -1,69 +0,0 @@ -## Nablarchサーブレットコンテキスト初期化リスナ - -**クラス名:** `nablarch.fw.web.servlet.NablarchServletContextListener` - ------ - -### 概要 - -このクラスはサーブレットコンテキストの初期化時(デプロイ時)に呼ばれ、 -リポジトリの初期化処理を行う。 -また、ログの初期化処理および終端処理を行う。 - -特に、画面オンライン処理における、ハンドラキュー構成とハンドラキューの起点となる -サーブレットフィルタ [Webフロントコントローラ (サーブレットフィルタ)](../../component/handlers/handlers-WebFrontController.md) の初期化はここで行われる。 - -> **Note:** -> このクラスはハンドラでは無いが、ハンドラ構成を説明する都合上ここであわせて解説する。 - ------ - -**処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| Nablarchサーブレットコンテキスト初期化リスナ | nablarch.fw.web.servlet.NablarchServletContextListener | - | - | サーブレットコンテキスト初期化時に、リポジトリおよびハンドラキューの初期化処理を行う。 | - | Fatalログを出力した上で再送出する。(デプロイエラーになる。) | -| Webフロントコントローラ (サーブレットフィルタ) | nablarch.fw.web.servlet.WebFrontController | ServletRequest/Response | - | HttpServletRequest/HttpServletResponseからHTTPリクエストオブジェクトを作成し、ハンドラキューに処理を委譲する。 | (Webコンテナ側に制御を戻す。) | このハンドラでは例外およびエラーの捕捉は行なわず、そのまま送出する。 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [Webフロントコントローラ (サーブレットフィルタ)](../../component/handlers/handlers-WebFrontController.md) | 本クラスが初期化するリポジトリ内に、このサーブレットフィルタが オブジェクトキー名 **webFrontController** で定義されている必要がある。 | - -### 設定項目・拡張ポイント - -本クラスは、サーブレットコンテキストリスナとしてデプロイし、 -コンテキスト初期化時に以下のコンテキスト変数を参照する。 - -| 変数名 | 設定内容 | -|---|---| -| di.config (必須) | リポジトリの設定ファイルのパスを設定する。 設定ファイルは基本的にクラスパスリソースから検索されるが、 **“file://“** から始まるパスを設定することでローカルファイルシステム上の ファイルを検索できる。 | -| di.duplicate-definition-policy | リポジトリの設定ファイル読み込み時に、 設定値の上書き設定が検出された際の動作ポリシーを設定する。 設定すべき値の詳細については、 [リポジトリ](../02_FunctionDemandSpecifications/01_Core/02_Repository.html) を参照。 設定しなかった場合、OVERRIDE。 | - -以下は **web.xml** の設定例である。 - -```xml - - - - di.config - web-component-configuration.xml - - - - nablarch.fw.web.servlet.NablarchServletContextListener - - - - controller - nablarch.fw.web.servlet.RepositoryBasedWebFrontController - - - - controller - /* - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NablarchTagHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NablarchTagHandler.md deleted file mode 100644 index ae8351259..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NablarchTagHandler.md +++ /dev/null @@ -1,134 +0,0 @@ -## Nablarchカスタムタグ制御ハンドラ - -**クラス名:** `nablarch.common.web.handler.NablarchTagHandler` - ------ - ------ - -### 概要 - -本ハンドラは、本フレームワークが提供するカスタムタグと連動し、ウィンドウスコープをはじめとする -各種機能を実現するハンドラである。 - -カスタムタグの詳細については、以下を参照すること。 - -* [JSPカスタムタグライブラリ](../../component/libraries/libraries-07-WebView.md) - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| マルチパートリクエストハンドラ | nablarch.fw.web.upload.MultipartHandler | HttpRequest | HttpResponse | HTTPリクエストボディがマルチパート形式であった場合にその内容を解析し、一時ファイルに保存する。 | アップロードされた一時ファイルを全て削除する。 | アップロードされた一時ファイルを全て削除する。 | -| Nablarchカスタムタグ制御ハンドラ | nablarch.common.web.handler.NablarchTagHandler | HttpRequest | HttpResponse | Nablarchカスタムタグの動作に必要な事前処理を実施する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [マルチパートリクエストハンドラ](../../component/handlers/handlers-MultipartHandler.md) | 本ハンドラでは、POSTパラメータの内容を使用するためにリクエストボディを読み込む。 そのため、本ハンドラを [Nablarchカスタムタグ制御ハンドラ](../../component/handlers/handlers-NablarchTagHandler.md) の後続に配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (内部フォーワードによる重複実行スキップ)** - -内部フォーワードによる再実行であった場合は、本ハンドラでの処理を行わずに、 -後続ハンドラに処理を委譲し、その結果をリターンして終了する。 - -**2. (Nablarchカスタムタグ向け処理の実行)** - -以下の処理を実行する。 - -* ボタン又はリンク毎のパラメータ変更機能を実現するために、リクエストに変更パラメータを設定する。 -* リクエストにcheckboxタグのチェックなしに対応する値を設定する。 -* hiddenタグの暗号化機能に対応する改竄チェックと復号を行う。 -* HTTPアクセスログのリクエストパラメータを出力する。 -* カスタムタグのデフォルト値をJSPで参照できるように、 [CustomTagConfig](../../javadoc/nablarch/common/web/tag/CustomTagConfig.html) をリクエストスコープに設定する。 - 設定可能なデフォルト値の詳細は [NablarchTagHandlerの設定](../../component/libraries/libraries-07-HowToSettingCustomTag.md#nablarchtaghandlerの設定) の項を参照すること。 - -> **Note:** -> 改竄チェックと復号は、カスタムタグのデフォルト値設定において、 -> hiddenタグの暗号化機能を「使用する」に設定している場合のみ処理を行う。 - -**2a. (Hidden項目改竄)** - -復号されたHidden項目内のチャレンジコードがセッション上に格納されたものと一致しなかった場合は、 -INFOレベルのログを出力したのち、本ハンドラに設定されたエラー遷移先/ステータスコードを指定した -HTTPエラーレスポンスを送出する。 - -**3. (後続ハンドラに対する処理委譲)** - -ハンドラキュー上の後続ハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**4. (正常終了)** - -**3.** で取得した処理結果をリターンして終了する。 - -**[例外制御]** - -**3a. (後続ハンドラでのエラー)** - -後続ハンドラ実行中にエラーが発生した場合は、そのまま再送出して終了する。 - ------ - -### 改竄検知の判定について - -本ハンドラは下記順序でリクエストの改ざんを検知する。 - -1. リクエストが HTTP POST 以外で送信されていた場合、改竄エラーとして処理する。 -2. セッションからウィンドウスコープの暗号化に使用する鍵を取得。 - (セッションから鍵が取得できなかった場合、改竄エラーまたはセッション無効化時エラーとして処理する。) -3. ウィンドウスコープに保持するデータをセッションに保持した鍵を使用して複合する。 - リクエストパラメータからウィンドウスコープの値が取得出来なかった場合、複合に失敗した場合は改竄エラーとして処理する。 -4. 複合したデータに含まれるデータのハッシュ値を、複合したデータのハッシュ値と比較して複合したデータが有効であるか判定する。 - ハッシュ値が一致しなかった場合、改竄エラーとして処理する。 -5. ウィンドウスコープに保持する値から、前画面で表示したJSPから遷移できるリクエストIDを全て取得し、処理中のリクエストのリクエストIDと比較する。 - 処理中のリクエストのリクエストIDが、前画面から遷移可能なリクエストIDに含まれていなかった場合は改竄エラーとして処理する。 - -NablarchTagHandler の判定条件が上記の通りであるため、本フレームワークを使用した場合、実際に悪意あるユーザが改竄したリクエストを送信した場合に -加えて下記のケースも改竄エラーとして処理される。 - -* セッションから暗号化に使用する鍵が取得できなかった場合。 - このケースには、ユーザが長時間アプリケーションを使用しなかったことで、セッションが無効になったケースや、ログアウト後に - 別ウィンドウに表示されたボタンを押下してリクエストを送信した場合なども含まれる。(ただしこの場合は、 sessionExpirePath を - 設定してあれば sessionExpirePath で指定したフォワード先を使用できる。 -* 改竄検知対象のリクエストIDの画面リクエストを URL 直接指定した場合。 - このケースには、画面のブックマークを含む。 -* 前画面で Nablarch のカスタムタグで作成したサブミットボタン押下以外の方法でリクエストパラメータをPOSTした場合。 - これは、改竄以外にアプリケーションバグで発生しうる。 - -このため、改竄エラー時のエラー画面設計時は、上記事象が発生した際に表示されてもユーザにとって意味のあるエラー画面を設定する必要がある。 -通常改竄エラーは、実際に改竄を行ったユーザに対して通知する必要がないため、基本的にはエラー画面には下記いずれかが発生したことを伝える -メッセージを表示すればよい。 - -* 既にログアウトしたか、長期間使用しないためにログアウトしてしまった。 -* 正しくない画面遷移が行われた。 - -### 設定項目・拡張ポイント - -本ハンドラの設定値は以下の通り。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 改竄エラー画面パス | path | String | (必須指定) hidden項目の改竄を検知した場合に送信する 画面のリソースパス。 改竄の判定基準は [改竄検知の判定について](../../component/handlers/handlers-NablarchTagHandler.md#改竄検知の判定について) に記載した通り。 | -| 改竄エラーステータスコード | statusCode | int | (任意指定: デフォルト=400) 改竄を検知した場合のレスポンスステータス。 | -| セッション無効化時エラー画面パス | sessionExpirePath | String | (任意指定: デフォルト=path に指定した値) セッションが無効化されていた際に遷移する 画面のリソースパス。 指定しなかった場合、 path と同じ | -| セッション無効化時エラーステータスコード | sessionExpireStatusCode | int | (任意指定: デフォルト=400) セッションが無効化されていた場合の レスポンスステータス。 | - -NablarchTagHandlerの設定例を下記に示す。 - -```xml - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NoInputDataBatchAction.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NoInputDataBatchAction.md deleted file mode 100644 index e05c733b6..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-NoInputDataBatchAction.md +++ /dev/null @@ -1,107 +0,0 @@ -## 入力データを使用しないバッチ処理用業務アクションハンドラのテンプレートクラス - -**クラス名:** `nablarch.fw.action.NoInputDataBatchAction` - ------ - -### 概要 - -このクラスは [都度起動バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-batch-single-shot.md) において、 -一括データ削除を行うクリーニングバッチのように、単発の処理を実行するバッチを実装する場合に使用する -アクションハンドラのテンプレートクラスである。 - -具体的には、一度だけダミー読込みを行うデータリーダを使用することにより、 -一回だけアクションハンドラの処理を実行させるようにする。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| 単発バッチ処理用業務アクションハンドラ | nablarch.fw.action.NoInputDataBatchAction | SqlRow | Result | データリーダが読み込んだ1件分のデータレコードを入力として業務処理を実行する。 | 処理結果オブジェクトを返す。(通常はResult.Successを返す) | - | 一度だけダミー読込みを行うデータリーダを作成して返す。 | - ------ - -本クラスを継承してアクションハンドラを実装するには、以下のテンプレートメソッドを必要に応じて実装する。 - -| メソッド名 | 内容 | -|---|---| -| handle() | (必須実装) このアクションハンドラで実行する業務処理を実装する。 [バッチ処理用業務アクションハンドラのテンプレートクラス](../../component/handlers/handlers-BatchAction.md) とは異なり、データリーダーを使用せず、常に1度だけ呼ばれる。 なお、引数は実行コンテキストのみとなる。(オーバーロード) | -| initialize() | (任意実装) バッチ処理の開始前に一度だけ呼ばれる。 デフォルトでは何もしない。 | -| error() | (任意実装) 実行時例外/エラーの発生によってバッチがエラー終了した場合に 一度だけコールバックされる。 デフォルトでは何もしない。 | -| terminate() | (任意実装) バッチ処理が全件終了もしくはエラーにより終了した後で 一度だけコールバックされる。 デフォルトでは何もしない。 | - -以下のソースコードは、フレームワークが本クラスの各テンプレートメソッドを -どのタイミングで呼び出すかを表したものである。 - -```java -CommandLine command; // バッチ起動時のコマンドライン -ExecutionContext ctx; // 実行コンテキスト - -initialize(command, ctx); // バッチ処理開始前に一度だけ呼ばれる。 - -Result result = null; - -try { - result = handle(ctx); // 業務処理を実行。 - commit(); // 業務トランザクションをコミット - -} catch(e) { - rollback(); // 業務トランザクションをロールバック - error(e, ctx); // バッチがエラー終了した場合に、一度だけ呼ばれる。 - -} finally { - terminate(result, ctx) // バッチが終了した後、一度だけ呼ばれる。 -} -``` - -> **Note:** -> このコードはあくまで説明用に単純化したものであり、実際の処理フローはこのようなロジックでは無く、 -> ハンドラ構成によって制御されており、全く別物である。 - -### ハンドラ処理フロー - -**[コールバック]** - -**1. (バッチ処理開始前初期処理)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) での処理開始時に **initialize()** を実行する。 - -**2. (データリーダ生成)** - -続いて、 [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) のコールバックで、ダミーのデータリーダを作成して返す。 -このデータリーダでは、1度だけダミーの読込みを行い、それ以降はデータリーダがクローズされた場合と同じ動作となる。 - -これにより、アクションハンドラが1度だけ実行されるようにする。 - -**[往路処理]** - -**3. (業務処理を実行)** - -業務処理を実行する。 - -**[復路処理]** - -**4. (正常終了)** - -正常終了を表すマーカオブジェクト( [Result.Success](../../javadoc/nablarch/fw/Result.Success.html) ) をリターンする。 - -**[例外処理]** - -**4a. (エラー終了)** - -業務処理に失敗した場合は、実行時例外を送出する。 - -**[コールバック]** - -**5. (バッチエラー終了時)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) でバッチ処理実行用のサブスレッドがエラーにより停止した場合、 -本ハンドラの **error()** を実行する。 - -**6. (バッチ終了時)** - -[マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) でバッチ処理実行用のサブスレッドが終了した場合、 -本ハンドラの **terminate()** を実行する。 -(このコールバックは、バッチがエラー終了した場合でも、 **6.** の処理の後で呼ばれる。) diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-PermissionCheckHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-PermissionCheckHandler.md deleted file mode 100644 index 6d78f0d75..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-PermissionCheckHandler.md +++ /dev/null @@ -1,107 +0,0 @@ -## 認可制御ハンドラ - -**クラス名:** `nablarch.common.handler.PermissionCheckHandler` - ------ - ------ - -### 概要 - -リクエストIDを単位とした認可判定を行うハンドラ。 - -また、認可通過以降は、認可関連情報をスレッドコンテキスト経由で取得することができる。 -認可機能の詳細については、 [認可](../../component/libraries/libraries-04-Permission.md) の章を参照すること。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| スレッドコンテキスト変数設定ハンドラ(リクエストスレッド) | nablarch.common.handler.ThreadContextHandler_request | Object | Object | 前のループで設定されたスレッドコンテキスト変数をクリアするためここで再初期化する。 | - | - | -| 内部フォーワードハンドラ | nablarch.fw.web.handler.ForwardingHandler | HttpRequest | HttpResponse | - | 遷移先に内部フォーワードパスが指定されていた場合、HTTPリクエストオブジェクトのリクエストURIを内部フォーワードパスに書き換えた後、後続のハンドラを再実行する。 | - | -| 認可制御ハンドラ | nablarch.fw.common.handler.PermissionCheckHandler | Object | Object | スレッドコンテキスト上の userId/requestId をもとに認可判定を行う。認可判定に失敗した場合は例外を送出して終了する。成功した場合は、認可情報オブジェクトをスレッドローカルに設定する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | 本ハンドラではスレッドコンテキスト上に設定されたリクエストID/ユーザIDをもとに 認可判定を行なうため、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) を本ハンドラの上位に配置する必要がある。 | -| [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) | [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) において、内部フォーワードを行った際の認可判定を フォーワード先のリクエストID ([内部リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#特殊なリクエスト処理)) で行う場合、 本ハンドラは [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) より下位に配置する必要がある。 | -| [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) | [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) では、 [要求電文(FWヘッダ)リーダ](../../component/readers/readers-FwHeaderReader.md) が受信電文中のフレームワークヘッダ部を解析する際に、 **requestId** および **userId** ヘッダの値をスレッドコンテキストに設定する。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (リクエストIDの取得)** - -スレッドコンテキストから [リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) もしくは -[内部リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#特殊なリクエスト処理) を取得する。 - -**1a. (認可処理のスキップ)** - -**1.** 取得したリクエストIDの値が、本ハンドラに設定された **認可対象外リクエストIDリスト** に含まれている場合、 -本ハンドラではそれ以上の処理を行なわず、後続ハンドラに処理を委譲し、その結果をリターンして終了する。 - -**2. (ユーザIDの取得)** - -スレッドコンテキストからユーザIDを取得する。 - -**3. (認可情報取得)** - -本ハンドラに設定された **認可情報取得コンポーネント** を用いて、 **2.** で取得したユーザIDに対する -認可情報を取得する。 - -**4. (認可判定)** - -**1.** で取得したリクエストIDが **2.** で取得した認可情報に含まれていることを確認し、 -認可情報をスレッドローカルに格納する。 - -**4a. (認可エラー)** - -**1.** で取得したリクエストIDが **2.** で取得した認可情報に含まれていなかった場合は、 -後続のハンドラの処理を実行せずに、実行時例外 [Result.Forbidden](../../javadoc/nablarch/fw/Result.Forbidden.html) を送出して終了する。 - -**5. (後続ハンドラの実行)** - -後続のハンドラに処理を委譲し、その結果を取得する。 - -**[往路での処理]** - -**6. (正常終了)** - -**5.** で取得した処理結果をリターンし終了する。 - -**[例外処理]** - -**5a. (後続ハンドラの処理でエラー)** - -後続ハンドラの実行中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 -**認可情報取得コンポーネント** の設定については -[認可](../../component/libraries/libraries-04-Permission.md) の章を参照すること。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 認可情報取得コンポーネント | permissionFactory | PermissionFactorry | 必須指定 | -| 認可判定対象外リクエストIDリスト | ignoreRequestIds | String[] | 任意指定(デフォルトは空のリスト) | -| 内部リクエストIDによる判定を行うかどうか | usesInternalRequestId | boolean | 任意指定(デフォルト=false) | - -**標準設定** - -以下は [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) における本ハンドラの設定例である。 -[画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) では -**認可判定対象外リクエストIDリスト** にログイン画面に対するリクエストIDを設定する必要がある。 - -```xml - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ProcessResidentHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ProcessResidentHandler.md deleted file mode 100644 index 8fff47bdb..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ProcessResidentHandler.md +++ /dev/null @@ -1,114 +0,0 @@ -## プロセス常駐化ハンドラ - -**クラス名:** `nablarch.fw.handler.ProcessResidentHandler` - ------ - ------ - -### 概要 - -後続のハンドラキューの内容を一定間隔毎に繰り返し実行するハンドラ。 -本ハンドラは、特定のデータソース上の入力データを定期的に監視してバッチ処理を行う、 -いわゆる常駐起動型のバッチ処理で用いられる。 - -> **Note:** -> 本ハンドラと [リクエストスレッド内ループ制御ハンドラ](../../component/handlers/handlers-RequestThreadLoopHandler.md) の責務は似通っているが、 -> [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) ではメインスレッド上でのループ制御を行い、 -> [リクエストスレッド内ループ制御ハンドラ](../../component/handlers/handlers-RequestThreadLoopHandler.md) は各サブスレッド上でのループ制御を行うという違いから -> 例外制御のポリシーなどの面で挙動が大きく異なっており、共用はできない。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| リトライ制御ハンドラ | nablarch.fw.handler.RetryHandler | Object | Object | - | - | リトライ可能な実行時例外を捕捉し、かつリトライ上限に達していなければ後続のハンドラを再実行する。 | -| プロセス常駐化ハンドラ | nablarch.fw.handler.ProcessResidentHandler | Object | Object | データ監視間隔ごとに後続処理を繰り返し実行する。 | ループを継続する。 | ログ出力を行い、実行時例外が送出された場合はリトライ可能例外にラップして送出する。エラーが送出された場合はそのまま再送出する。 | -| 処理停止制御ハンドラ | nablarch.fw.handler.ProcessStopHandler | Object | Object | リクエストテーブル上の処理停止フラグがオンであった場合は、後続の処理は行なわずにプロセス停止例外(ProcessStop)を送出する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [プロセス停止制御ハンドラ](../../component/handlers/handlers-ProcessStopHandler.md) | 本ハンドラを組み込んだハンドラキューは、シグナル送信以外の手段で 外部から停止させることができなくなる。 外部コマンドなどによって正常終了させるには、 [プロセス停止制御ハンドラ](../../component/handlers/handlers-ProcessStopHandler.md) を本ハンドラの後続に設定する必要がある。 | -| [リトライ制御ハンドラ](../../component/handlers/handlers-RetryHandler.md) | 後続ハンドラの実行中に本ハンドラが実行時例外を捕捉した場合、 リトライ可能例外でラップして再送出し、バッチプロセスの継続制御を [リトライ制御ハンドラ](../../component/handlers/handlers-RetryHandler.md) で行う。そのため、このハンドラを本ハンドラの 上位に配置する必要がある。 | - -### ハンドラ処理フロー - -**[往路での処理]** - -**1. (ハンドラキューのコピー)** - -本ハンドラ開始時点でのハンドラキューのスナップショット(シャローコピー)を作成する。 - -**2. (ループ開始)** - -実行コンテキスト上のハンドラキューの内容を、 **1.** で作成したスナップショットの状態に復旧する。 - -**3. (後続ハンドラの実行)** - -後続のハンドラを実行し、その結果を取得する。 - -**[復路での処理]** - -**4. (実行待機)** - -本ハンドラに設定されたデータ監視時間から、後続ハンドラの実行時間を差し引いた時間を待機する。 - -**5. (正常終了->ループ継続)** - -**2.** 以降の処理を繰り返す。 - -**[例外処理]** - -**3a. (閉局エラー→ループ継続)** - -後続ハンドラ実行中に、サービス閉局エラー(nablarch.fw.Result.ServiceUnavailable)が送出された場合は、 -何もせずに、 **4.** **5.** の往路処理を行なう。 - -**3b. (プロセス正常停止)** - -後続ハンドラ実行中に、プロセス停止要求(nablarch.fw.handler.ProcessStopHandler.ProcessStop) が送出された場合は、 -ループを中断し、後続ハンドラによる直近の処理結果オブジェクトをリターンして終了する。 - -**3c. (プロセス異常停止)** - -後続ハンドラ実行中に、プロセス異常停止要求(nablarch.fw.ProcessAbnormalEnd)が送出された場合は、 -ループを中断し、捕捉した例外を再送出して終了する。 - -**3d. (実行時例外→リトライ)** - -後続ハンドラ実行中にその他の実行時例外が送出された場合は、その内容を障害ログに出力した上で、 -リトライ可能例外(RetryableException)でラップして送出し終了する。 - -**3e. (エラー終了)** - -後続ハンドラ実行中にエラー(java.lang.Error)が送出された場合は、捕捉したエラーをそのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| データ監視間隔 (単位:msec) | dataWatchInterval | int | 任意指定 (デフォルト=1000) | -| プロセスを正常停止させる例外 | normalEndExceptions | List | 任意指定 (デフォルト=[ProcessStop.class]) | -| プロセスを異常終了させる例外 | abnormalEndExceptions | List | 任意指定 (デフォルト=[ProcessAbnormalEnd.class]) | - -**標準設定** - -データ監視間隔は、常駐プロセスごとに異なる値を設定したり、また、運用状況に応じて変更することが想定されるため、 -下記例のように埋め込みパラメータとして定義することを強く推奨する。 - -```xml - - - - -``` - -> **Note:** -> プロセス正常停止、プロセス異常停止の対象となる例外クラスについては、本ハンドラの設定により -> 追加・変更することが可能だが、特段の理由が無い限りはデフォルト設定を使用すること。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ProcessStopHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ProcessStopHandler.md deleted file mode 100644 index 3d3cb5589..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ProcessStopHandler.md +++ /dev/null @@ -1,135 +0,0 @@ -## プロセス停止制御ハンドラ - -**クラス名:** `nablarch.fw.handler.ProcessStopHandler` - ------ - ------ - -### 概要 - -本ハンドラは、 [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) のような、ループ制御を行なうハンドラの後続に配置することで、 -DB上のフラグ変更によってループを中断させ、プロセスを正常終了させることを可能とするハンドラである。 - -> **Warning:** -> 本ハンドラでは、処理停止フラグの初期化は行なわない。 -> 停止フラグを立ててプロセスを停止させた後、再度同じプロセスを実行する際には、 -> 停止フラグをクリアする必要がある。 - ------ - -**ハンドラ処理概要** ( [常駐バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-batch-resident.md) での例) - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| スレッドコンテキスト変数設定ハンドラ(メインスレッド) | nablarch.common.handler.ThreadContextHandler_main | Object | Object | 起動引数の内容からリクエストID、ユーザID等のスレッドコンテキスト変数を初期化する。 | - | - | -| プロセス常駐化ハンドラ | nablarch.fw.handler.ProcessResidentHandler | Object | Object | データ監視間隔ごとに後続処理を繰り返し実行する。 | ループを継続する。 | ログ出力を行い、実行時例外が送出された場合はリトライ可能例外にラップして送出する。エラーが送出された場合はそのまま再送出する。 | -| 処理停止制御ハンドラ | nablarch.fw.handler.ProcessStopHandler | Object | Object | リクエストテーブル上の処理停止フラグがオンであった場合は、後続の処理は行なわずにプロセス停止例外(ProcessStop)を送出する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | 本ハンドラではスレッドコンテキスト上のリクエストID属性を使用するので、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) を本ハンドラより前に配置する必要がある。 | -| [トランザクションループ制御ハンドラ](../../component/handlers/handlers-LoopHandler.md) | [都度起動バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-batch-single-shot.md) を実行中に停止させる場合は、 [トランザクションループ制御ハンドラ](../../component/handlers/handlers-LoopHandler.md) の後続にこのハンドラを配置する。 | -| [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) | [常駐バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-batch-resident.md) では、 [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) の後続にこのハンドラを配置する。 なお、停止時の終了コードは(0:正常終了)となる。 | -| [リクエストスレッド内ループ制御ハンドラ](../../component/handlers/handlers-RequestThreadLoopHandler.md) | [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) では、 [リクエストスレッド内ループ制御ハンドラ](../../component/handlers/handlers-RequestThreadLoopHandler.md) の後続にこのハンドラを配置する。 なお、停止時の終了コードは(0:正常終了)となる。 | - -**テーブル構成** - -以下は、本ハンドラが参照するリクエスト管理テーブルの構造である。 - -| 論理名 | データ型 | 備考 | -|---|---|---| -| リクエストID | VARCHAR PK | プロセスを特定するためのID | -| 処理停止フラグ | CHAR(1) | "0": 通常、"1": 停止 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (停止フラグ確認処理のスキップ)** - -本ハンドラの総実行回数が、停止フラグ確認間隔の値の倍数でない場合、 -このハンドラでは何もせずに、後続のハンドラに処理を委譲し、その処理結果をリターンして終了する。 - -**2. (停止フラグ確認)** - -本ハンドラの総実行回数が、停止フラグ確認間隔の値の倍数に一致する場合、 -リクエストテーブルに以下のクエリを発行し、停止フラグの状態を確認する。 - -**抽出条件**: - -``` -リクエストID = (スレッドコンテキストのリクエストID属性値) AND 処理停止フラグ = '1' -``` - -**2a. (プロセス停止)** - -**2.** の結果セットが空ではない場合、後続ハンドラの実行は行なわず、 `ProcessStopHandler.ProcessStop` を送出し終了する。 -これにより、ループは中断され、運用ログを出力したのち、プロセスが停止する。また、未コミットの例外は全てロールバックされる。 - -**3. (後続ハンドラへの処理移譲)** - -**2.** の結果セットが空であった場合、後続のハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**4. (正常終了)** - -**3.** で取得した処理結果をリターンして終了する。 - -**[例外処理]** - -**3a. (後続ハンドラ処理中のエラー)** - -後続ハンドラの処理中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 停止フラグ確認間隔 | checkInterval | int | 任意指定(デフォルト = 1:毎回) | -| リクエストテーブル名 | tableName | String | 必須指定 | -| リクエストIDカラム名 | requestIdColumnName | String | 必須指定 | -| 処理停止フラグカラム名 | processHaltColumnName | String | 必須指定 | -| DBトランザクションマネージャ | dbTransactionManager | SimpleDbTransactionManager | 必須指定 | -| プロセス停止時終了コード | exitCode | Integer | 任意指定(デフォルト = 1) | - -**基本設定** - -```xml - - - - - - - - - - -``` - -**任意の設定項目も含めた例** - -```xml - - - - - - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestHandlerEntry.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestHandlerEntry.md deleted file mode 100644 index 7c2aa21d6..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestHandlerEntry.md +++ /dev/null @@ -1,145 +0,0 @@ -## リクエストハンドラエントリ - -**クラス名:** `nablarch.fw.RequestHandlerEntry` - -このハンドラは、対象のハンドラをラップし、そのハンドラを特定の [リクエストパス](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストに対する業務処理のディスパッチ) に対してのみ実行することができる。 - -**リクエストパスのパターン指定** - -このハンドラでは、リクエストパスとして、URIや Unixのシステムパス、Javaの名前空間のように、"/"で区切られた -階層構造を想定しており、 -ハンドラを実行するリクエストパスのパターンを **Glob式** に似た書式で指定することができる。 - -1. ワイルドカードの指定等、基本的にUnixやDOSで使用されるGlob式の記法に準じる。 - '*'はワイルドカードであり'.'と'/'を除く任意の文字の任意個の列にマッチする。 - - | requestPattern | リクエストパス | 結果 | - |---|---|---| - | / | / | 呼ばれる | - | | /index.jsp | 呼ばれない | - | /* | / | 呼ばれる | - | | /app | 呼ばれる | - | | /app/ | 呼ばれない (* は'/'にはマッチしない) | - | | /index.jsp | 呼ばれない (* は'.'にはマッチしない) | - | /app/*.jsp | /app/index.jsp | 呼ばれる | - | | /app/admin | 呼ばれない | - | /app/*/test | /app/admin/test | 呼ばれる | - | | /app/test/ | 呼ばれない | -2. 最後尾の'/'が'//'と重ねられていた場合、それ以前の文字列について - 前方一致すればマッチ成功と判定する。 - リソース名を表す'//'以降の文字列については別途マッチ判定が行われる。 - (すなわち、"サブディレクトリ全体"に対してマッチする。) - - | requestPattern | リクエストパス | 結果 | - |---|---|---| - | /app// | / | 呼ばれない | - | | /app/ | 呼ばれる | - | | /app/admin/ | 呼ばれる | - | | /app/admin/index.jsp | 呼ばれる | - | //*.jsp | /app/index.jsp | 呼ばれる | - | | /app/admin/index.jsp | 呼ばれる | - | | /app/index.html | 呼ばれない('*.jsp'がマッチしない) | - ------ - ------ - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (ハンドラ実行判定)** - -ハンドラの引数として渡されたリクエストオブジェクトから、リクエストパスを取得し、 -本ハンドラに設定された **実行対象リクエストパスパターン** と合致するかどうかを上述した判定ロジックに沿って判定する。 - -**2. (実行対象外リクエストパス)** - -**1.** の判定でパターンが合致しなかった場合は、それ以上このハンドラでは処理を行わず、 -後続のハンドラに処理移譲し、その結果を取得する。 - -**2a. (実行対象リクエストパス)** - -**1.** の判定でパターンが合致した場合は、このハンドラに設定された **委譲対象ハンドラ** に処理を委譲し、 -その結果を取得する。 - -**[復路処理]** - -**3. (正常終了)** - -**2.** もしくは **2a.** の結果をリターンして終了する。 - -**[例外処理]** - -**2b. (エラー終了)** - -後続のハンドラ、もしくは **委譲対象ハンドラの** 処理中にエラーが発生した場合は、 -特段の例外処理は行なわず、後続ハンドラで送出された例外をそのまま送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 委譲対象ハンドラ | handler | Handler | (必須指定) | -| 実行対象リクエストパスパターン | requestPattern | String | (必須指定) 委譲対象のハンドラを実行するリクエストパスのパターン。 | - -**画面オンライン処理での設定例** - -宣言的トランザクション制御の対象範囲を、特定のパス(/action) 配下に限定する場合。 - -```xml - - - - - -``` - -**複数のパッケージを使用する設定例** - -上記の設定例のように、単一のリクエストハンドラエントリを使用した場合、 -ベースパッケージが異なるパッケージに対してディスパッチすることははできない（下図参照）。 - -*【図：ss11AAをベースパッケージに指定した場合のディスパッチ範囲】* - -```text -nablarch - +-sample - +- ss11AA <-- ベースパッケージ - | +- RM11AA0101Action <-- 委譲可 - | +- RM11AA0102Action <-- 委譲可 - +- ss99ZZ - +- RM99ZZ0101Action <-- 委譲不可 -``` - -異なるリクエストパスにマッチするリクエストハンドラエントリを複数使用することにより、 -複数のベースパッケージ配下のクラスにディスパッチすることができる。 - -以下に設定例を記載する。 -リクエストパスのパターンとベースパッケージの対応関係に注目されたい。 - -```xml - - - - - - - - - - - - - - - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestPathJavaPackageMapping.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestPathJavaPackageMapping.md deleted file mode 100644 index 7e43ab597..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestPathJavaPackageMapping.md +++ /dev/null @@ -1,220 +0,0 @@ -## リクエストディスパッチハンドラ - -**クラス名:** `nablarch.fw.handler.RequestPathJavaPackageMapping` - ------ - ------ - -### 概要 - -[リクエストディスパッチハンドラ](../../component/handlers/handlers-RequestPathJavaPackageMapping.md) は、 [リクエストパス](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) をJavaパッケージ階層にマッピングすることで、 -リクエストパスの値に応じて実行するハンドラを任意に切り替えることを可能とするハンドラである。 - -主に **業務アクションハンドラ** のディスパッチを行う際に使用する。 - -例えば、以下の設定例では、リクエストパスが **/app/action/** で始まる場合に、 -後続処理を Javaパッケージ **nablarch.application** 配下のクラスにディスパッチする。 -(ディスパッチ対象のクラスをハンドラキューに追加する。) - -```xml - - - - - -``` - -この場合、リクエストパスの値とディスパッチ先のクラス名との対応は以下のようになる。 - -| リクエストパス | ディスパッチ対象クラス | -|---|---| -| /app/action/AdminApp | nablarch.application.AdminApp | -| /app/action/user/UserApp | nablarch.application.user.UserApp | -| /app/application/AdminApp | (ディスパッチ対象無し:404エラー) | - ------ - -**ハンドラ処理概要** ([同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) での構成) - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| データリードハンドラ(FW制御ヘッダリーダ/メッセージリーダ利用) | nablarch.fw.handler.DataReadHandler_messaging | Object | Result | 要求電文を受信しFW制御ヘッダ部を解析して要求電文オブジェクト(RequestMessage)を作成し後続のハンドラに渡す。また、FW制御ヘッダのrequestId/userIdの値をメッセージコンテキストに設定する。 | - | - | - | -| リクエストディスパッチハンドラ | nablarch.fw.handler.RequestPathJavaPackageMapping | Request | Object | 引数として渡されたリクエストオブジェクトのリクエストパスから、処理対象の業務アクションを決定しハンドラキューに追加する。 | - | - | - | -| 同期応答電文処理用業務アクションハンドラ | nablarch.fw.action.MessagingAction | RequestMessage | ResponseMessage | 要求電文の内容をもとに業務処理を実行する。 | 業務処理の結果と要求電文の内容から応答電文の内容を作成して返却する。 | - | トランザクションロールバック時にエラー応答電文を作成する。 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [共通起動ランチャ](../../component/handlers/handlers-Main.md) | [バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-architectural-pattern-batch.md) では、プロセス起動引数 **--requestPath** に指定された [リクエストパス](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) の値に応じてディスパッチを行う。 | -| [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) | [同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) では、 [要求電文(FWヘッダ)リーダ](../../component/readers/readers-FwHeaderReader.md) が読み込むフレームワーク制御ヘッダ領域のリクエストIDヘッダ **(項目名:requestId)** の値を使用する。 | -| [HTTPリクエストディスパッチハンドラ](../../component/handlers/handlers-HttpRequestJavaPackageMapping.md) | [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) では、本ハンドラを拡張した [HTTPリクエストディスパッチハンドラ](../../component/handlers/handlers-HttpRequestJavaPackageMapping.md) を使用する。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (リクエストパスの取得)** - -ハンドラの引数として渡されたリクエストオブジェクトから、以下のAPIを使用してリクエストパスを取得する。: - -``` -nablarch.fw.Request#getRequestPath(): String -``` - -**1a. (ベースパス外アクセスエラー)** - -取得したリクエストパスに対して、本ハンドラに設定されたベースパスが前方一致しない場合は、 -実行時例外 [Result.NotFound](../../javadoc/nablarch/fw/Result.NotFound.html) を送出する。 - -**1b. (非Java識別子を含むパスによるアクセスエラー)** - -取得したリクエストパスの各ディレクトリ文字列中に、Java識別子以外の文字 [1] が含まれていた場合は、 -Javaの名前空間にマッピングすることができないので、実行時例外 [Result.NotFound](../../javadoc/nablarch/fw/Result.NotFound.html) を送出する。 - -**2. (ディスパッチ対象クラスの決定)** - -以下の仕様に従って、ディスパッチ対象クラスの完全修飾名を決定する。 - -1. リクエストパス中の **”.”** を **”/”** に置換する。 -2. リクエストパスの先頭から 本ハンドラに設定された **ベースパス** と一致する部分を、同じく本ハンドラに設定された - **マッピング先Javaパッケージ名** に置換する。 - (**optionalPackageMappingEntries** が設定されている場合は、そちらの設定によるマッピングが優先される。 - マッチするものが存在しなかった場合は、上記の **ベースパス** によるマッチングを行う。 - **optionalPackageMappingEntries** の仕様と設定方法については、 [複雑なマッピング定義](../../component/handlers/handlers-RequestPathJavaPackageMapping.md#-javaパッケージの組み合わせ----------------------------------------------javapackagemappingentry----デフォルト--null---) - の項を参照。) -3. **2.** の結果文字列を **”.”** で分割する。分割後の各トークンの内、英大文字で始まっているものをクラス名とし、 - それ以前の各トークンをパッケージ階層とする。 -4. 本ハンドラ設定値として、 **ディスパッチ対象クラス名の接頭辞/接尾辞** が設定されている場合はクラス名の前後にそれぞれ付加する。 - -**3. (ディスパッチ対象クラスのインスタンス作成)** - -コンテキストクラスパスから、 **2.** で決定された完全修飾名のクラスをロードし、 -デフォルトコンストラクタを用いてインスタンスを作成する。 - -**3a. (クラスロードエラー)** - -対象のクラスがコンテキストクラスパス上に存在しなかった場合は、実行時例外 [Result.NotFound](../../javadoc/nablarch/fw/Result.NotFound.html) を送出する。 - -**3b. (インスタンス生成時エラー)** - -対象のクラスにデフォルトコンストラクタが定義されていない場合や、コンストラクタ内で例外が送出されるなど、 -何らかの理由でインスタンスの生成に失敗した場合は、実行時例外を送出する。 - -**5. (ハンドラインスタンスをハンドラキューに追加)** - -実行コンテキスト上のハンドラキューにハンドラインスタンスを追加する。 -ハンドラの追加位置は、本ハンドラの設定値(**immediate**)によって以下のように定まる。 - -ディスパッチハンドラの直後にハンドラインスタンスを挿入する。 (デフォルト) - -ハンドラキューの末尾にハンドラインスタンスを追加する。 - -なお、ハンドラキューに追加したインスタンスがハンドラインタフェースを実装していなかった場合は、 -実行コンテキスト上の **MethodBinder** を使用して、 [メソッド単位のディスパッチ](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) を行う -ハンドラインターフェースのアダプタが作成される。 - -**5a. (ディスパッチ不可能エラー)** - -対象のクラスがハンドラインターフェースを実装しておらず、また、実行コンテキスト上に **MethodBinder** が設定されていない場合は、 -[Result.NotFound](../../javadoc/nablarch/fw/Result.NotFound.html) が送出される。 - -**6. (後続ハンドラの実行)** - -ハンドラキュー上の後続ハンドラに対して処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**7. (正常終了)** - -**6.** の結果をリターンして終了する。 - -**[例外処理]** - -**6a. (後続ハンドラ処理でエラー)** - -後続ハンドラの処理中に例外が発生した場合はそのまま再送出して終了する。 - -リクエストパスに ascii範囲外のマルチバイト文字が含まれていても許容される。 -ただし、マッピング先のJavaクラスにascii範囲外の文字が含まれる場合は、404エラー扱いとなる。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| ベースパス文字列 | basePath | String | 任意指定 (デフォルト = "") | -| ベースパッケージ | basePackage | String | 任意指定 (デフォルト = "") | -| ディスパッチ対象クラス名の接頭辞 | classNamePrefix | String | 任意指定 (デフォルト = "") | -| ディスパッチ対象クラス名の接尾辞 | classNameSuffix | String | 任意指定 (デフォルト = "") | -| ハンドラ追加位置 | immediate | boolean | 任意指定 (デフォルト = true) | -| リクエストパスのパターンとマッピング先 Javaパッケージの組み合わせ | optionalPackageMappingEntries | nablarch.fw.handler .JavaPackageMappingEntry | 任意指定 (デフォルト = null) | - -**基本設定** - -```xml - - - - - - -``` - -**ディスパッチ対象のクラス名を [リソース名] + "Action" とする場合** - -```xml - - - - - -``` - -**複雑なマッピング設定** - -optionalPackageMappingEntries プロパティに設定を行うことで、リクエストパスごとにマッピング先Javaパッケージを切り替えることができる。 -optionalPackageMappingEntries プロパティには、リクエストパスのパターンとJava パッケージの組み合わせを設定する。 - -optionalPackageMappingEntries プロパティに設定した順番にリクエストパスのパターンとリクエストパスとのマッチングが行われ、 -最初にマッチしたJavaパッケージが使用される。マッチするものが存在しない場合、本ハンドラのbasePackage プロパティに設定したJavaパッケージが使用される。 - -リクエストパスのパターンは、Glob式に似た書式で指定することができる。 -詳細は、 [リクエストハンドラエントリ](../../component/handlers/handlers-RequestHandlerEntry.md#リクエストハンドラエントリ) を参照すること（リクエストハンドラエントリと同一の記法でパターンを指定できる）。 - -例えば、以下の設定では、リクエストパスのパターン **/sample/admin//** をJavaパッケージ **nablarch.sample.app1** 、 -リクエストパスのパターン **/sample/user//** をJavaパッケージ **nablarch.sample.apps2** に対応させている。 -いずれのリクエストパターンにもマッチしない場合は、本ハンドラのbasePackage プロパティに設定した **nablarch.sample.base** が使用される。 - -```xml - - - - - - - - - - - - - - - - - - -``` - -| リクエストパス | ディスパッチ対象クラス | -|---|---| -| /admin/AdminApp | nablarch.sample.apps1.admin.AdminApp | -| /user/UserApp | nablarch.sample.apps2.user.UserApp | -| /BaseApp | nablarch.sample.base.BaseApp | - -> **Note:** -> リクエストパスのパターンのマッチは、リクエストパス中のすべての **”.”** をスラッシュ **”/”** に置換してから行われる。 -> この仕様は、Nablarchのバッチ処理で過去に使用していたドット区切りのリクエストパス（例： ss01A001.B01AA001Action/B01AA0010）との互換性を保つために存在している。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestThreadLoopHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestThreadLoopHandler.md deleted file mode 100644 index 01264f105..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RequestThreadLoopHandler.md +++ /dev/null @@ -1,142 +0,0 @@ -## リクエストスレッド内ループ制御ハンドラ - -**クラス名:** `nablarch.fw.handler.RequestThreadLoopHandler` - ------ - ------ - -### 概要 - -リクエストスレッド上のループ制御を行うハンドラ。 - -本ハンドラは、サーバソケットや受信電文キュー等を監視し、リアルタイム応答を行う -サーバ型プロセスにおいて、各リクエストスレッド上で以下のループ制御を行うハンドラである。: - -``` -データリーダによるリクエストの受信 → リクエスト処理の実行 → 次のリクエストの待機 -``` - -サーバ型処理では、バッチ処理とは異なり、個々のリクエスト処理は完全に独立しているので、 -1つのリクエスト処理がエラーとなっても他のリクエスト処理はそのまま継続しなければならない。 -このため、本ハンドラで捕捉した例外は、プロセス正常停止要求や致命的な一部の例外を除き -再送出せずにそのまま処理を継続する。 - -> **Note:** -> 本ハンドラと [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) の責務は似通っているが、 -> [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) ではメインスレッド上でのループ制御を行い、 -> [リクエストスレッド内ループ制御ハンドラ](../../component/handlers/handlers-RequestThreadLoopHandler.md) は各サブスレッド上でのループ制御を行うという違いから -> 例外制御のポリシーなどの面で挙動が大きく異なっており、共用はできない。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| マルチスレッド実行制御ハンドラ | nablarch.fw.handler.MultiThreadExecutionHandler | Object | MultiStatus | サブスレッドを作成し、後続ハンドラの処理を並行実行する。 実行コンテキスト上にデータリーダが存在しない場合は、コールバックを行う。 | 全スレッドの正常終了まで待機する。 | 処理中のスレッドが完了するまで待機し起因例外を再送出する。 | 1. 処理開始前 / 2. データリーダ作成 / 3. スレッド異常終了時 / 4. 処理完了時 | -| リクエストスレッド内ループ制御ハンドラ | nablarch.fw.handler.RequestThreadLoopHandler | Object | Object | データリーダが閉じられるまで、後続のハンドラを繰り返し実行する。 | ハンドラキューの内容を復旧しループを継続する。 | プロセス停止か致命的なエラーが発生した場合のみループを停止する。 | - | -| 処理停止制御ハンドラ | nablarch.fw.handler.ProcessStopHandler | Object | Object | リクエストテーブル上の処理停止フラグがオンであった場合は、後続の処理は行なわずにプロセス停止例外(ProcessStop)を送出する。 | - | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) | 本ハンドラーは、 [マルチスレッド実行制御ハンドラ](../../component/handlers/handlers-MultiThreadExecutionHandler.md) が作成する 各リクエストスレッド内のループ制御を行う。 | -| [プロセス停止制御ハンドラ](../../component/handlers/handlers-ProcessStopHandler.md) | 本ハンドラを組み込んだハンドラキューは、データリーダが閉じられるか、 致命的なエラーが発生しない限り停止しない。 外部からプロセスを正常終了させる場合は [プロセス停止制御ハンドラ](../../component/handlers/handlers-ProcessStopHandler.md) を後続ハンドラとして組み込む必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (ループ終了判定)** - -データリーダが開いていることを確認する。 - -**1a.(ループ終了)** - -データリーダが閉じられていた場合は、ループを終了し、直近の処理結果をリターンする。 - -**2. (実行コンテキストのコピー)** - -ループ開始前の実行コンテキストをコピーして、1回分のループで使用する実行コンテキストを作成する。 -この際、実行コンテキストの各属性は以下のように複製される。 - -| 属性名 | データ型 | コピーされる内容 | -|---|---|---| -| ハンドラキュー | List<[Handler](../../javadoc/nablarch/fw/Handler.html)> | ループ開始前のハンドラキューのシャローコピーを作成する。 | -| リクエストコンテキスト | Map | 新規のMapを作成する。 | -| セッションコンテキスト | Map | ループ開始前のセッションスコープのMapをそのまま設定する。 | -| データリーダ | [DataReader](../../javadoc/nablarch/fw/DataReader.html) | ループ開始前のデータリーダをそのまま設定する。 | -| データリーダファクトリ | [DataReaderFactory](../../javadoc/nablarch/fw/DataReaderFactory.html) | ループ開始前のファクトリをそのまま設定する。 | - -**3. (後続ハンドラの実行)** - -コピーした実行コンテキストを用いて、ハンドラキュー上の後続のハンドラに処理を委譲する。 - -**[復路処理]** - -**4. (リクエスト処理正常終了 → ループ継続)** - -後続ハンドラが正常終了した場合は、 **1.** に戻りループを継続する。 - -**[例外処理]** - -**3a. (プロセス停止コマンド投入による正常停止)** - -[プロセス停止制御ハンドラ](../../component/handlers/handlers-ProcessStopHandler.md) によりプロセス停止例外が送出された場合は、ループを中断し [Result.Success](../../javadoc/nablarch/fw/Result.Success.html) を返却して -終了コード0で正常終了させる。 - -**3b. (例外制御)** - -後続ハンドラの処理中に実行時例外もしくはエラーが送出された場合でも、 -ログ出力のみ行い、原則としてループは継続させる。 -ただし、プロセスの継続に影響するような致命的なエラーが発生した場合のみ、例外を再送出し -プロセスを停止させる。 - -捕捉した例外/エラーの型ごとの処理内容の詳細は以下のとおり。 - -| 捕捉した例外クラス | 障害ログ出力 | ログレベル | 処理結果 | 備考 | -|---|---|---|---|---| -| nablarch.fw.Result.ServiceUnavailable | なし | Trace | ループ継続 | 業務機能が閉局していた場合に [開閉局制御ハンドラ](../../component/handlers/handlers-ServiceAvailabilityCheckHandler.md) から送出される。 INFOログを出力し、 本ハンドラに設定された **業務閉局時待機時間** だけwait した後でループを継続する。 | -| nablarch.fw.handler.retry.Retryable | なし | なし | 捕捉した例外 を再送出 | DB/MQの接続エラーなどの単純再実行による処理継続が可能な エラーが生じた場合に送出される。 再送出し上位の [リトライ制御ハンドラ](../../component/handlers/handlers-RetryHandler.md) で継続判断を行う。 | -| java.lang.ThreadDeath | なし | Info | 捕捉した例外 を再送出 | 外部からスレッド停止APIが呼ばれた場合に発生する。 通常運用で発生しうるため、Infoレベルのログを出力し、 再送出する。 | -| java.lang.StackOverflowError | あり | Fatal | ループ継続 | アプリケーションロジックの問題(無限ループ等)である 可能性が高いのでFatalログを出力し、再送出はしない。 | -| java.lang.OutOfMemoryError | あり | Fatal | ループ継続 | リソースを浪費しているリクエストスレッドが終了することで 復旧する可能性があるため、Fatalログを出力し再送出はしない。 なお、ログ出力の際には失敗する可能性があるので、 ログ出力前に標準エラー出力に最小限のメッセージを出力する。 | -| java.lang.VirtualMachineError | なし | なし | 捕捉した例外 を再送出 | (OutOfMemoryError/StackOverFlowErrorを除く) | -| nablarch.fw.launcher.ProcessAbnormalEnd | なし | なし | 捕捉した例外 を再送出 | (極めて特殊なケースを除き使用されない。) | -| nablarch.fw.Result.ServiceError | あり | Fatal/Warn | ループ継続 | アプリケーション側から障害ログの出力が要求された場合に 送出される。 | -| nablarch.fw.Result.Error | あり | Fatal | ループ継続 | | -| (上記以外の実行時例外/エラー) | あり | Fatal | ループ継続 | | - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| 業務閉局時待機時間(単位:msec) | serviceUnavailabilityRetryInterval | int | 任意指定 (デフォルト=1000) | - -**標準設定** - -[同期応答メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-request-reply.md) では、 -エラー応答送信後、速やかにメッセージ待機状態に移行するため、 -業務閉塞時の待機時間を0に設定する。 - -```xml - - - -``` - -一方、 [応答不要メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging-receive.md) では、 -業務閉塞時は要求電文のGET処理は行なわず、業務が開局されるまで各リクエストスレッド上で、 -リクエストテーブルをポーリングしつつ待機する。 -このポーリング間隔を調整する場合は明示的に値を設定する。 -(デフォルトでは1000msecずつ待機する。) - -```xml - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ResourceMapping.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ResourceMapping.md deleted file mode 100644 index fb5a4c26b..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ResourceMapping.md +++ /dev/null @@ -1,156 +0,0 @@ -## リソースマッピングハンドラ - -**クラス名:** `nablarch.fw.web.handler.ResourceMapping` - ------ - ------ - -### 概要 - -業務アクションの処理を経由せずに、直接レスポンスとして返却するリソースを決定するハンドラ。 - -このハンドラは、主にログイン画面のようにビジネスロジックを介さずに表示するJSPや、 -javascriptや画像のような静的リソースのレスポンスを行なう場合に使用する。 - -レスポンスされるリソースは、事前に定義されたリクエストパスと -[コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) とのマッピング定義を元に決定される。 - -マッピング先のリソースは、以下のいずれかを指定することができる。 - -1. サーブレット/JSPフォーワード (**servlet://** スキーム) **[デフォルト]** -2. 内部フォーワードの実行結果 (**forward://** スキーム) -3. コンテキストクラスローダ上のリソース (**classpath://** スキーム) - -なお、セキュリティ上の配慮から、ファイルシステム上のローカルファイル(**file://** スキーム)を -マッピング先に指定することはできない。また、スキームの指定を省略した場合は **servlet://** スキームが指定されたものと -みなされる。 - -> **Note:** -> 通常のサーブレットアプリケーションでは、直接アクセス不可能なリソースは **/WEB-INF/** 配下に配置するのが -> 一般的であるが、本フレームワークでは、JSP、画像などのリソースは全てサーブレットコンテキスト配下に -> 直接配置することを推奨している。 - -> この場合、デフォルトでは全てのリソースに対する直接アクセスは拒否され、 -> 業務アクションのレスポンスもしくは、本ハンドラのマッピング定義の対象となるリソースのみアクセス可能となる。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| HTTPレスポンスハンドラ | nablarch.fw.web.handler.HttpResponseHandler | HttpRequest | HttpResponse | - | HTTPレスポンスの内容に沿ってレスポンス処理かサーブレットフォーワードのいずれかを行う。 | 既定のエラー画面をレスポンス後、例外を再送出する。ただしサーブレットフォーワード処理中にエラーが発生した場合はログ出力のみを行なう。 | -| 内部フォーワードハンドラ | nablarch.fw.web.handler.ForwardingHandler | HttpRequest | HttpResponse | - | 遷移先に内部フォーワードパスが指定されていた場合、HTTPリクエストオブジェクトのリクエストURIを内部フォーワードパスに書き換えた後、後続のハンドラを再実行する。 | - | -| リソースマッピングハンドラ | nablarch.fw.web.handler.ResourceMapping | HttpRequest | HttpResponse | リクエストURIを、クラスパス上のリソースパスもしくはサーブレットフォーワードパスにマッピングすることで、業務アクションを実行することなくHTTPレスポンスオブジェクトを作成して返却する。 | - | - | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md) | 本ハンドラが返却したHTTPレスポンスオブジェクト中の [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) の内容に 基づいてレスポンス処理を行う。 | -| [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) | [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) が **forward://** で開始されている場合に内部フォーワード 処理を行う。 | -| [リクエストハンドラエントリ](../../component/handlers/handlers-RequestHandlerEntry.md) | 本ハンドラによるマッピング対象となるリクエストを限定するために、 必ず、 [リクエストハンドラエントリ](../../component/handlers/handlers-RequestHandlerEntry.md) と組み合わせて使用する。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (マッピング対象リクエスト判定)** - -本ハンドラに設定された **マッピング元ベースURI** が、リクエストパス(サーブレットコンテキストからの相対パス)に対して -前方一致するかどうかを判定する。 - -**1a. (マッピング対象外のリクエスト)** - -**1.** でパスが一致しなかった場合、当該リクエストは本ハンドラによるマッピングの対象外と判断し、 -ステータスコード **404** のレスポンスをリターンし、終了する。 - -**2.(マッピング先コンテンツパスの算出)** - -リクエストパス中の **1.** で前方一致した部分文字列を、本ハンドラに設定された **マッピング先ベースコンテンツパス** に置換し、 -**マッピング先コンテンツパス** とする。 -なお、 **マッピング先ベースコンテンツパス** にスキームが明示されていない場合は、 **servlet://** を補完する。 - -**3. (マッピング先コンテンツパス実在チェック)** - -**マッピング先コンテンツパス** のスキームが **classpath://** であった場合は当該のパス上にリソースが実在するかどうかを -チェックし、もし存在しなければ、ステータスコード **404** のレスポンスをリターンし、終了する。 - -**4. (HTTPレスポンスの返却)** - -ステータスコード **200** のHTTPレスポンスを作成し、 **2.** で算出した [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) を設定した上でリターンする。 - -**[復路処理]** - -(本ハンドラは後続のハンドラに対する処理委譲を行なわない。) - -**[例外処理]** - -(本ハンドラは後続のハンドラに対する処理委譲を行なわない。) - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| マッピング元ベースURI | baseUri | String | **必須指定** リクエストURIの置換対象となる部分文字列(前方一致)を指定する。 | -| マッピング先ベースコンテンツパス | basePath | String | **必須指定** リクエストURI中のマッピング元ベースURIを置換する文字列 ([コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容))を指定する。 スキームの指定を省略した場合は、 **servlet://** が指定されたものとみなされる。 | - -**画像ファイルに対するマッピングの設定例** - -次の例では、リクエストパス **/img/** 配下の画像ファイルに対するリクエストを、 -サーブレットコンテキスト配下のパス **/resources/img/** を参照するようにマッピングしている。 - -```xml - - - - - - - - - - - - - -``` - -このマッピングにより、HTTPリクエストと、それに対するレスポンスの [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) との対応は以下のようになる。 -(サーブレットコンテキストパスが **/webapp/** であった場合。) - -| HTTPリクエストライン | コンテンツパス | -|---|---| -| GET /webapp/img/logo.png | servlet:///resource/img/logo.png | -| GET /webapp/img/page1/figure01.png | servlet:///resource/img/page1/figure01.png | - -**直接表示可能なJSP画面** - -次の例では、リソース名の末尾が **-public.jsp** となっている場合に、当該ページに対する直接アクセスを可能としている。 - -```xml - - - - - - - - - - - - - -``` - -このマッピングにより、HTTPリクエストと、それに対するレスポンスの [コンテンツパス](../../component/handlers/handlers-HttpMethodBinding.md#業務アクションハンドラの実装内容) との対応は以下のようになる。 -(サーブレットコンテキストパスが **/webapp/** であった場合。) - -| HTTPリクエストライン | コンテンツパス | -|---|---| -| GET /webapp/jsp/login-public.jsp | servlet:///jsp/login-public.jsp | -| GET /webapp/jsp/welcome.jsp | (404エラー) | diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RetryHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RetryHandler.md deleted file mode 100644 index 1324bb3cb..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-RetryHandler.md +++ /dev/null @@ -1,146 +0,0 @@ -## リトライ制御ハンドラ - -**クラス名:** `nablarch.fw.handler.RetryHandler` - ------ - ------ - -### 概要 - -[リトライ制御ハンドラ](../../component/handlers/handlers-RetryHandler.md) はデータベースアクセス時のデッドロックのように、 -単純リトライによってリカバリ可能なエラーについて、自動的なリトライ制御を行うハンドラである。 - -本ハンドラでは、 [Retryable](../../javadoc/nablarch/fw/handler/retry/Retryable.html) インターフェースを実装した実行時例外を -リトライ可能なエラーなとみなし、後続ハンドラの再実行を行う。 -なお、リトライ上限の判定に関する処理は、 [RetryContext](../../javadoc/nablarch/fw/handler/RetryHandler.RetryContext.html) インターフェースの実装クラスとして外部化されている。 -デフォルトでは以下の実装が提供されている。 - -* [CountingRetryContext](../../javadoc/nablarch/fw/handler/retry/CountingRetryContext.html) - - リトライ回数に対する上限を設定する。 -* [TimeRetryContext](../../javadoc/nablarch/fw/handler/retry/TimeRetryContext.html) - - 初回実行時からの経過時間に対する上限を設定する。 - -**ハンドラ処理概要** ([常駐バッチ実行制御基盤](../../processing-pattern/nablarch-batch/nablarch-batch-batch-resident.md) での構成) - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| リトライ制御ハンドラ | nablarch.fw.handler.RetryHandler | Object | Object | - | - | リトライ可能な実行時例外を捕捉し、かつリトライ上限に達していなければ後続のハンドラを再実行する。 | -| プロセス常駐化ハンドラ | nablarch.fw.handler.ProcessResidentHandler | Object | Object | データ監視間隔ごとに後続処理を繰り返し実行する。 | ループを継続する。 | ログ出力を行い、実行時例外が送出された場合はリトライ可能例外にラップして送出する。エラーが送出された場合はそのまま再送出する。 | -| データベース接続管理ハンドラ | nablarch.common.handler.DbConnectionManagementHandler | Object | Object | 業務処理用ＤＢ接続を取得し、スレッドローカル上に保持する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | -| メッセージングコンテキスト管理ハンドラ | nablarch.fw.messaging.handler.MessagingContextHandler | Object | Object | メッセージングコンテキスト(MQ接続)を取得し、スレッドローカルに保持する。 | メッセージングコンテキストを開放する。（プールに戻す） | メッセージングコンテキストを開放する。（プールに戻す） | - ------ - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) | [プロセス常駐化ハンドラ](../../component/handlers/handlers-ProcessResidentHandler.md) では後続ハンドラから例外が送出された場合、 その例外をリトライ可能例外にラップして再送出し、 [リトライ制御ハンドラ](../../component/handlers/handlers-RetryHandler.md) 側 でプロセス継続/中止の判断を行う。 | -| * [データベース接続管理ハンドラ](../../component/handlers/handlers-DbConnectionManagementHandler.md) * [メッセージングコンテキスト管理ハンドラ](../../component/handlers/handlers-MessagingContextHandler.md) | 本フレームワークでは、DBやメッセージングキューへの接続エラーが発生 した場合にリトライ可能例外を送出する。 そのため、これらのハンドラを [リトライ制御ハンドラ](../../component/handlers/handlers-RetryHandler.md) の 後続に配置しないと再接続が行われない。 | - -### ハンドラ処理フロー - -本ハンドラの処理の流れは以下のとおりである。 - -**[往路処理]** - -**1. (ハンドラキューのスナップショットを保存)** - -実行コンテキスト上のハンドラキューについて、シャローコピーを作成する。 -また、以降の処理で使用する [RetryContext](../../javadoc/nablarch/fw/handler/RetryHandler.RetryContext.html) のインスタンスを生成する。 - -**2. (後続ハンドラの実行)** - -ハンドラキュー上の後続のハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**3. (正常終了)** - -**2.** の結果をリターンして終了する。 - -**[例外処理]** - -**2a. (リトライ処理)** - -後続ハンドラの実行中に [Retryable](../../javadoc/nablarch/fw/handler/retry/Retryable.html) を実装する実行時例外を捕捉した場合、 -[RetryContext](../../javadoc/nablarch/fw/handler/RetryHandler.RetryContext.html) によるリトライ上限判定を行い、上限に達していない場合は、 -以下の処理を実行する。 - -1. ワーニングレベルのログを出力する。 -2. (初回のみ) リトライ処理開始時刻を設定する。 -3. リトライ回数を1増加させる。 -4. リトライ間隔(msec)待機する。 -5. ハンドラキューの内容を **1.** で作成したスナップショットの内容に戻す。 -6. 後続ハンドラの処理を再実行する。(**2.** に戻る。) - -**2b. (リトライ上限到達)** - -後続ハンドラ実行中に [Retryable](../../javadoc/nablarch/fw/handler/retry/Retryable.html) を実装する実行時例外を捕捉し、 -かつリトライ上限に達していた場合は、ワーニングログを出力し、 [ProcessAbnormalEnd](../../javadoc/nablarch/fw/launcher/ProcessAbnormalEnd.html) を送出する。 -これにより、実行中のプロセスは強制停止される。 - -**2c. (リトライ対象外例外の捕捉)** - -[Retryable](../../javadoc/nablarch/fw/handler/retry/Retryable.html) を実装していない実行時例外を捕捉した場合は、それを再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおりである。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| リトライコンテキスト生成 | retryContextFactory | RetryContextFactor | 必須設定 | -| リトライ上限エラー時障害コード | retryLimitExceededFailureCode | TransactionFactory | 任意指定 | -| リトライ上限エラー時終了コード | retryLimitExceededExitCode | int | 任意指定(デフォルト="180") | - -リトライ上限の判定ロジックは、 RetryContext インターフェースの実装系によって提供される。 -フレームワークに同梱されている実装クラスの設定項目は以下のとおり。 - -[CountingRetryContextFactory](../../javadoc/nablarch/fw/handler/retry/CountingRetryContextFactory.html) の設定項目 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| リトライ間隔 (msec) | retryIntervals | long | 任意設定(デフォルト="0") | -| リトライ上限回数 | retryCount | int | 任意指定(デフォルト="0") | - -[TimeRetryContextFactory](../../javadoc/nablarch/fw/handler/retry/TimeRetryContextFactory.html) の設定項目 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| リトライ間隔 (msec) | retryIntervals | long | 任意設定(デフォルト="0") | -| リトライ上限時間 | retryTime | int | 任意指定(デフォルト="0") | - -以下はリポジトリ設定ファイルの記述例である。 - -[CountingRetryContext](../../javadoc/nablarch/fw/handler/retry/CountingRetryContext.html) を使用する例。 - -```xml - - - - - - - - - -``` - -[TimeRetryContextFactory](../../javadoc/nablarch/fw/handler/retry/TimeRetryContextFactory.html) を使用する例。 - -```xml - - - - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ServiceAvailabilityCheckHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ServiceAvailabilityCheckHandler.md deleted file mode 100644 index 4039c82cd..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ServiceAvailabilityCheckHandler.md +++ /dev/null @@ -1,91 +0,0 @@ -## 開閉局制御ハンドラ - -**クラス名:** `nablarch.common.handler.ServiceAvailabilityCheckHandler` - ------ - -### 概要 - -リクエストID単位での開閉局制御を行うハンドラ。 - -開閉局機能の詳細については、 -[開閉局](../../component/libraries/libraries-05-ServiceAvailability.md) -の章を参照すること。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| スレッドコンテキスト変数設定ハンドラ(リクエストスレッド) | nablarch.common.handler.ThreadContextHandler_request | Object | Object | 前のループで設定されたスレッドコンテキスト変数をクリアするためここで再初期化する。 | - | - | -| 内部フォーワードハンドラ | nablarch.fw.web.handler.ForwardingHandler | HttpRequest | HttpResponse | - | 遷移先に内部フォーワードパスが指定されていた場合、HTTPリクエストオブジェクトのリクエストURIを内部フォーワードパスに書き換えた後、後続のハンドラを再実行する。 | - | -| 開閉局制御ハンドラ | nablarch.fw.common.handler.ServiceAvailabilityCheckHandler | Request | Result | リクエストＩＤ単位での開閉局制御を行う | - | - | - ------ - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) | 本ハンドラではスレッドコンテキスト上に設定された [内部リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#特殊なリクエスト処理) をもとに開閉局判定を行なうため、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) を本ハンドラの上位に配置する必要がある。 | -| [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) | [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) において内部フォーワードが行われた際に、 開閉局の制御をフォーワード先のリクエストID ([内部リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#特殊なリクエスト処理)) で行う必要がある場合は、本ハンドラを [内部フォーワードハンドラ](../../component/handlers/handlers-ForwardingHandler.md) より下位に配置する必要がある。 | -| [データリードハンドラ](../../component/handlers/handlers-DataReadHandler.md) | [メッセージング実行制御基盤](../../processing-pattern/mom-messaging/mom-messaging-messaging.md) では、 受信電文中のフレームワークヘッダ内に定義された **requestId** ヘッダの値を使用して 開閉局制御を行う。 (この場合、 [要求電文(FWヘッダ)リーダ](../../component/readers/readers-FwHeaderReader.md) が **requestId** ヘッダの値を スレッドコンテキストに設定するので、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md) は使用しなくてもよい) | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (リクエストIDの取得)** - -スレッドコンテキストから [リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) もしくは -[内部リクエストID](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#特殊なリクエスト処理) を取得する。 - -**2. (開閉局判定)** - -本ハンドラに設定された **サービス開閉局判定オブジェクト** を使用して、 -**1.** で取得したリクエストIDに対するサービスが開局中であることを確認する。 - -**2a. (閉局エラー)** - -サービスが閉局中であった場合は、後続のハンドラを実行せず、 -実行時例外 [Result.ServiceUnavailable](../../javadoc/nablarch/fw/Result.ServiceUnavailable.html) (**ステータスコード:503**)を送出して終了する。 - -**3. (後続ハンドラの実行)** - -当該サービスが開局状態であれば、後続のハンドラを実行し、その結果を取得する。 - -**[復路処理]** - -**4. (正常終了)** - -**3.** で取得した処理結果をリターンし終了する。 - -**[例外処理]** - -**3a. (後続ハンドラの処理でエラー)** - -後続ハンドラの実行中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -なお、開閉局機能の設定内容の詳細については、 -[開閉局](../../component/libraries/libraries-05-ServiceAvailability.md) -の章を参照すること。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| サービス開閉局判定コンポーネント | serviceAvailability | ServiceAvailability | 必須指定 | -| 内部リクエストIDによる判定を行うかどうか | usesInternalRequestId | boolean | 任意指定 (デフォルト=false) | - -**標準設定** - -```xml - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-SessionConcurrentAccessHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-SessionConcurrentAccessHandler.md deleted file mode 100644 index 2a45e863f..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-SessionConcurrentAccessHandler.md +++ /dev/null @@ -1,135 +0,0 @@ -## セッション並行アクセスハンドラ - -**クラス名:** `nablarch.fw.handler.SessionConcurrentAccessHandler` - ------ - ------ - -### 概要 - -セッションスコープは、複数のリクエストに跨って共有されるため、セッションスコープ上の変数は -複数のリクエストスレッドから並行アクセスされる可能性がある。 -この際、セッション変数単体の読み書きについてはスレッドセーフであることが保証されるものの、 -セッションオブジェクト全体の整合性については保証されない。 - -本ハンドラはセッションスコープに対する並行アクセス制御をフレームワークレベルで実装するものである。 - -現バージョンでは、CONCURRENT同期ポリシーのみサポートする。 - -> **Warning:** -> 同期方式のうちMANUALとSERIALIZEは廃止されました。 - -> 本ハンドラを使用する場合は排他ロックによる同期制御が必要なオブジェクトを、セッションに格納しないでください。 - -**CONCURRENT** - -スレッド毎のスナップショットを作成することで、並行アクセスに対する一貫読み取りおよび、 -楽観ロック方式による書き込みを行う。 - -リクエストスレッドがセッションスコープ上の変数にアクセスした時点で、 -セッションスコープのスナップショット（ディープコピー）をスレッドローカル変数上に作成する。 -以降、当該リクエストスレッドからのアクセスはこのスナップショットに対して行われる。 -スナップショットに変更を加えた場合、リクエスト終了時にセッションスコープに反映される。 -このとき、セッションスコープが既に他のリクエストスレッドによって変更されていれば、 -変更の反映は行わず、ワーニングメッセージを登録する。 - -> **Note:** -> セッションスコープの変更反映に失敗した場合でも、DBのトランザクションは正常にコミットされる。 -> ただし、アノテーション **@ErrorOnSessionWriteConflict** をリクエストハンドラに付与することで、 -> セッションの変更に失敗した場合に実行時例外を送出させ、DBのトランザクションをロールバックさせることができる。 - -> 以下はその実装例である。 - -> ```java -> public class SampleHandler implements Handler { -> @ErrorOnSessionWriteConflict // セッションへの書込みに失敗した場合に実行時例外を送出する。 -> public HttpResponse handle(HttpRequest req, ExecutionContext ctx) { -> SampleForm form = validate(req); // HttpRequestオブジェクトからリクエストパラメータを取得 -> Map results = doBusiness(form); // 業務処理を実行 -> -> ctx.setSessionScopedVar("results", results); // セッションスコープに処理結果を設定 -> -> return new HttpResponse("servlet://success.jsp"); // 遷移先の画面を指定 -> } -> } -> ``` - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| セッション並行アクセスハンドラ | nablarch.fw.handler.SessionConcurrentAccessHandler | Object | Object | ハンドラに設定された同期ポリシーを実装したラッパーをセッションスコープに適用し、スコープ上の各変数に対する同期アクセス制御を開始する。 | 同期アクセス制御を停止する。 | 同期アクセス制御を停止する。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (セッションスコープラッパーの作成)** - -本ハンドラに指定されたセッション同期ポリシーに対応したセッションスコープのラッパーオブジェクトを作成し、 -実行コンテキストに設定する。 - -| 同期ポリシー | ラッパークラス | -|---|---| -| CONCURRENT | nablarch.core.util.map.CopyOnReadMap | - -**2. (後続ハンドラの実行)** - -ハンドラキュー上の後続ハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**3. (同期ポリシーCONCURRENT: セッション変更の反映)** - -本ハンドラに設定された同期ポリシーが **CONCURRENT** であった場合、 -後続のハンドラキュー上の処理の中で、セッションスコープに対して変更を加えていた場合、 -その変更内容が保持されたスナップショットをセッションスコープ本体に反映する。 - -**4. (セッションスコープラッパーの除去)** - -実行コンテキスト上のセッションスコープを、もとのスコープに差し替える。 - -**5. (正常終了)** - -**2.** で取得した処理結果をリターンして終了する。 - -**[例外処理]** - -**2a. (後続ハンドラ処理でエラー)** - -後続ハンドラの処理中に例外が送出された場合にも、上記 **3.** 、 **4.** での処理を実行した後、 -例外を再送出する。 - -**3a (同期ポリシーCONCURRENT: セッション変更反映の際に論理排他エラー)** - -本ハンドラに設定された同期ポリシーが **CONCURRENT** であった場合、 -後続処理でのセッション変更内容を反映する際に、 -並行するスレッドによって同一セッションによる変更が既に反映されていた場合、 -リクエストスコープ上にワーニングメッセージを登録する。 - -ただし、業務アクションに **@ErrorOnSessionWriteConflict** アノテーションが付与されていた場合は、 -実行時例外を送出する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| セッションスコープ並行アクセスポリシー | concurrentAccessPolicy | String | 任意指定(デフォルト="CONCURRENT") | -| セッション書込エラーメッセージID | conflictWarningMessageId | String | 任意指定 | - -**基本設定** - -以下は **CONCURRENT** ポリシーを使用する設定例である。 - -```xml - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-StatusCodeConvertHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-StatusCodeConvertHandler.md deleted file mode 100644 index ed31c9406..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-StatusCodeConvertHandler.md +++ /dev/null @@ -1,75 +0,0 @@ -## ステータスコード→プロセス終了コード変換ハンドラ - -**クラス名:** `nablarch.fw.handler.StatusCodeConvertHandler` - ------ - ------ - -### 概要 - -ステータスコードをプロセスの終了コードに変換するハンドラ。 - -[共通起動ランチャ](../../component/handlers/handlers-Main.md) の直後のハンドラとして設定することにより、 -後続ハンドラによる処理結果のステータスコード値をプロセスの終了コードに変換するハンドラである。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| 共通起動ランチャ | nablarch.fw.handler.Main | CommandLine | Integer | Javaコマンドから直接実行することで、DIリポジトリを初期化し、ハンドラキューを構築・実行する。 | 後続ハンドラの処理結果(整数値)を終了コードに指定し、プロセスを停止する。 | Fatalログを出力しプロセスを異常終了させる。 | -| ステータスコード→プロセス終了コード変換 | nablarch.fw.handler.StatusCodeConvertHandler | CommandLine | Integer | - | 後続ハンドラの処理結果をもとに、プロセス終了コード(整数値)を決定して返す。 | - | -| グローバルエラーハンドラ | nablarch.fw.handler.GlobalErrorHandler | Object | Result | - | - | 全ての実行時例外・エラーを捕捉し、ログ出力を行う | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [共通起動ランチャ](../../component/handlers/handlers-Main.md) | [共通起動ランチャ](../../component/handlers/handlers-Main.md) では、本ハンドラの戻り値を終了コードとして使用する。 | -| [グローバルエラーハンドラ](../../component/handlers/handlers-GlobalErrorHandler.md) | 本ハンドラでは例外制御は行なわないため、後続ハンドラで例外/エラーが送出された場合は [共通起動ランチャ](../../component/handlers/handlers-Main.md) に対してそのまま送出される。 そのため、本ハンドラの直後に [グローバルエラーハンドラ](../../component/handlers/handlers-GlobalErrorHandler.md) を配置し、 本ハンドラに対してエラーが送出されないようにする必要がある。 | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (後続ハンドラに対する処理委譲)** - -ハンドラキュー上の後続ハンドラに対して処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**2. (ステータスコードからプロセス終了コードを決定)** - -**1.** で後続のハンドラから返された処理結果オブジェクトのステータスコード値をもとに、 -プロセス終了コードを決定して返す。 - -| ステータスコード | プロセス終了コード | -|---|---| -| -1 以下 | 1 | -| 0 | 0 | -| 1 ～ 199 | (ステータスコードと同じ) | -| 200 ～ 399 | 0 | -| 400 | 10 | -| 401 | 11 | -| 403 | 12 | -| 404 | 13 | -| 409 | 14 | -| 上記以外の400～499 | 15 | -| 500以上 | 20 | - -**[例外処理]** - -**1a. (後続ハンドラ処理中のエラー)** - -後続ハンドラの処理中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラには特段の設定項目は無い。 -以下はDIリポジトリ設定ファイルへの記述例である。 - -```xml - -``` - -終了コードをプロジェクト固有の体系に変更したい場合は、本ハンドラ自体を別実装したものに差し替えること。 diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ThreadContextClearHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ThreadContextClearHandler.md deleted file mode 100644 index 38e24a10d..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ThreadContextClearHandler.md +++ /dev/null @@ -1,53 +0,0 @@ -## スレッドコンテキスト変数削除ハンドラ - -**クラス名:** `nablarch.common.handler.threadcontext.ThreadContextClearHandler` - ------ - ------ - -### 概要 - -[スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) で設定したスレッドローカル上の変数を削除するハンドラである。 - -> **Note:** -> 本ハンドラは極力手前側に配置すること。 -> なぜなら往路処理では、本ハンドラより手前のハンドラではスレッドコンテキストにアクセスできなくなるため。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| スレッドコンテキスト変数削除ハンドラ | nablarch.common.handler.threadcontext.ThreadContextClearHandler | Object | Object | - | ThreadContextHandlerで設定したスレッドローカル上の変数を削除する | ThreadContextHandlerで設定したスレッドローカル上の変数を削除する | -| スレッドコンテキスト変数設定ハンドラ(メインスレッド) | nablarch.common.handler.ThreadContextHandler_main | Object | Object | 起動引数の内容からリクエストID、ユーザID等のスレッドコンテキスト変数を初期化する。 | - | - | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (後続ハンドラへの処理委譲)** - -往路では何もせずに後続のハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**2. (正常終了)** - -[スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) で設定したスレッドローカル上の変数を削除する。 - -**[例外処理]** - -**1. (エラー終了)** - -後続ハンドラの処理中にエラーが発生した場合も、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) で設定したスレッドローカル上の変数を削除する。 - -### 設定項目・拡張ポイント - -本ハンドラの実装内容は基本的に変更不要なものであり、そのまま使用することができる。 -以下はDIリポジトリ設定ファイルへの記述例である。 - -```xml - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ThreadContextHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ThreadContextHandler.md deleted file mode 100644 index 47aef7de0..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-ThreadContextHandler.md +++ /dev/null @@ -1,104 +0,0 @@ -## スレッドコンテキスト変数管理ハンドラ - -**クラス名:** `nablarch.common.handler.threadcontext.ThreadContextHandler` - ------ - ------ - -### 概要 - -本ハンドラでは、スレッドコンテキスト上の各属性値について、設定ファイルの内容に沿った初期化処理を -リクエスト毎に行うハンドラである。 - -**スレッドコンテキスト** とは、リクエストIDやユーザIDなど、同一の処理スレッド内で共有する値を -スレッドローカル領域上に保持するための仕組みである。 - -スレッドコンテキスト自体の解説については、 [同一スレッド内でのデータ共有(スレッドコンテキスト)](../../component/libraries/libraries-thread-context.md) を参照すること。 - -> **Note:** -> 本ハンドラで設定したスレッドローカル上の値は、 [スレッドコンテキスト変数削除ハンドラ](../../component/handlers/handlers-ThreadContextClearHandler.md#スレッドコンテキスト変数削除ハンドラ) を使用して、復路処理で削除を行うこと。 -> 往路処理にて本ハンドラより手前のハンドラでスレッドコンテキストにアクセスした場合、 値を取得することはできないため本ハンドラより手前ではスレッドコンテキストにアクセスしないよう注意すること。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| スレッドコンテキスト変数削除ハンドラ | nablarch.common.handler.threadcontext.ThreadContextClearHandler | Object | Object | - | ThreadContextHandlerで設定したスレッドローカル上の変数を削除する | ThreadContextHandlerで設定したスレッドローカル上の変数を削除する | -| スレッドコンテキスト変数設定ハンドラ(メインスレッド) | nablarch.common.handler.ThreadContextHandler_main | Object | Object | 起動引数の内容からリクエストID、ユーザID等のスレッドコンテキスト変数を初期化する。 | - | - | - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (スレッドコンテキストのクリア)** - -スレッドローカル上に保持されているスレッドコンテキスト変数のMapの内容を全てクリアする。 - -**2. (スレッドコンテキスト属性の初期化)** - -本ハンドラに設定された **スレッドコンテキスト属性定義リスト** の内容に沿って初期化処理を実行する。 - -**3. (後続ハンドラの実行)** - -ハンドラキュー上の後続ハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**4. (正常終了)** - -**3.** で取得した処理結果オブジェクトをそのままリターンして終了する。 - -**[例外処理]** - -**3a. (エラー終了)** - -後続ハンドラの処理中にエラーが発生した場合は、そのまま再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| スレッドコンテキスト属性リスト | attributes | List | 必須指定 | - -**基本設定** - -以下は標準的なスレッドコンテキストの設定例である。 -詳細は、 [同一スレッド内でのデータ共有(スレッドコンテキスト)](../../component/libraries/libraries-thread-context.md) を参照すること。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-TransactionManagementHandler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-TransactionManagementHandler.md deleted file mode 100644 index 0850f9da4..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-TransactionManagementHandler.md +++ /dev/null @@ -1,171 +0,0 @@ -## トランザクション制御ハンドラ - -**クラス名:** `nablarch.common.handler.TransactionManagementHandler` - ------ - ------ - -### 概要 - -データベースやメッセージキューなどのトランザクションに対応したリソースを使用し、 -後続処理における透過的トランザクションを実現するハンドラ。 - -トランザクション機能の詳細については、 -[トランザクション管理](../../component/libraries/libraries-03-TransactionManager.md) 機能の項を参照すること。 - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | コールバック | -|---|---|---|---|---|---|---|---| -| データベース接続管理ハンドラ | nablarch.common.handler.DbConnectionManagementHandler | Object | Object | 業務処理用ＤＢ接続を取得し、スレッドローカル上に保持する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | 業務処理用ＤＢ接続を開放（プールに返却）する。 | - | -| トランザクション制御ハンドラ | nablarch.fw.common.handler.TransactionManagementHandler | Object | Object | 業務トランザクションの開始 | トランザクションをコミットする。 | トランザクションをロールバックする。 | 1.コミット完了後 / 2.ロールバック後 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [データベース接続管理ハンドラ](../../component/handlers/handlers-DbConnectionManagementHandler.md) | このハンドラの上位に配置することで、本ハンドラが管理するトランザクションに DB接続を参加させることができる。 | - -**コールバック** - -本ハンドラではトランザクションに関連した以下のイベントリスナを定義している。 -後続のハンドラで実装することにより、本ハンドラ実行中にコールバックを受けることができる。 - -| インターフェース | メソッド | イベント | -|---|---|---| -| [TransactionEventCallback](../../javadoc/nablarch/fw/TransactionEventCallback.html) | transactionNormalEnd() | トランザクションコミット直後に呼ばれる。 | -| | transactionAbnormalEnd() | トランザクションロールバック直後に呼ばれる。 | - -なお、 **transactionAbnormalEnd()** は業務トランザクションのロールバック後に実行されるため、 -個別のトランザクション内で実行される。また、このトランザクションはコールバック完了後 -自動的にコミット/ロールバックされる。 - -### ハンドラ処理フロー - -**[往路処理]** - -**1. (トランザクションオブジェクトの獲得)** - -このハンドラに設定されている **トランザクションファクトリ** を用いて、 -スレッドローカル上のDB接続に対するトランザクションを作成する。 - -**1a. (DB接続未設定エラー)** - -本ハンドラに設定された **スレッドローカル登録名** に対するDB接続がスレッドローカル上に設定されていなかった場合は -実行時例外を送出して終了する。 - -**2. (スレッドローカルへの登録)** - -**1.** で取得したトランザクションオブジェクトを、スレッドローカル変数上のMapに登録する。 -キー名は、本ハンドラに設定された **スレッドローカル登録名** を使用する。 - -**2a. (トランザクション重複登録エラー)** - -スレッドローカル上に同一の登録名で既にトランザクションが設定されていた場合は、実行時例外を送出して終了する。 - -**3. (トランザクション開始とハンドラキューの実行)** - -トランンザクションを開始し、ハンドラキュー上の後続ハンドラに処理を委譲し、その結果を取得する。 - -**[復路処理]** - -**4. (トランザクションコミット)** - -後続ハンドラの処理が正常終了した場合、トランザクションをコミットする。 - -**5. (コールバックの呼び出し)** - -後続ハンドラの内、 **TransactionEventCallback** を実装しているものについて、 -以下のコールバックメソッドを呼び出す。: - -``` -TransactionEventCallback#transactionNormalEnd(Object data, ExecutionContext context): void -``` - -**6. (終端処理)** - -スレッドローカルからトランザクションを除去した上で、トランザクションをクローズする。 - -**7. (正常終了)** - -**3.** で取得した後続ハンドラの処理結果をリターンし終了する。 - -**[例外処理]** - -**3a, 4a.(トランザクションロールバック)** - -後続ハンドラの処理中およびトランザクションのコミット時に例外が送出された場合は、トランザクションをロールバックし、 -以下のコールバックメソッドを呼び出す。: - -``` -TransactionEventCallback#transactionAbnormalEnd(Object data, ExecutionContext context): void -``` - -**6.** の終端処理を実行後、元例外を再送出して終了する。 - -**3b. (コミット対象エラー)** - -後続ハンドラの処理中に送出された実行時例外が本ハンドラに設定された **コミット対象例外クラスリスト** に含まれていた場合は、 -**3a.** のロールバック処理は行わず、かわりに **4.** 、 **5.** 、 **6.** の各処理を実行し、送出された例外を再送出して終了する。 - -### 設定項目・拡張ポイント - -本ハンドラの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| トランザクションファクトリ | transactionFactory | nablarch.core.transaction .TransactionFactory | (必須指定) | -| スレッドローカル登録名 | transactionName | String | (任意指定) カレントスレッドで使用するトランザクションを識別する 文字列。 複数のトランザクションを利用する場合に指定する。 またトランザクションとDBコネクションの登録名は一致させる 必要がある。 省略した場合は既定の接続名("transaction")使用する。 | -| コミット対象例外クラスリスト | transactionCommitExceptioins | List | (任意指定) このハンドラで捕捉してもそのままコミットする実行時例外 のリスト。クラスの完全修飾名のリストを設定する。 | - -**トランザクションファクトリ** の設定方法については -[トランザクション管理](../../component/libraries/libraries-03-TransactionManager.md) -を参照すること。 - -**基本設定** - -```xml - - - - -``` - -デフォルトの設定では、トランザクションが暗黙的に使用する接続名 -に対して接続オブジェクトを登録する。 -接続名を明示的に指定する場合は、属性dbConnectionNameにその値を設定する。 - -```xml - - - - - - - - - - - - - - - -``` - -**特定の例外が発生した場合はロールバックせずにそのままコミットする** - -```xml - - - - - - - example.TransactionCommitException - example.TransactionCommitException2 - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-WebFrontController.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-WebFrontController.md deleted file mode 100644 index 65c552c52..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-WebFrontController.md +++ /dev/null @@ -1,91 +0,0 @@ -## Webフロントコントローラ (サーブレットフィルタ) - -**クラス名:** `nablarch.fw.web.servlet.WebFrontController` - ------ - ------ - -### 概要 - -[画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md) において、サーブレットコンテナから直接コールバックされ、 -ハンドラキューの実行の起点となるクラスである。 - -サーブレットコンテキスト上にサーブレットフィルタとしてデプロイされる。 - ------ - -**ハンドラ処理概要** - -| ハンドラ | クラス名 | 入力型 | 結果型 | 往路処理 | 復路処理 | 例外処理 | -|---|---|---|---|---|---|---| -| Nablarchサーブレットコンテキスト初期化リスナ | nablarch.fw.web.servlet.NablarchServletContextListener | - | - | サーブレットコンテキスト初期化時に、リポジトリおよびハンドラキューの初期化処理を行う。 | - | Fatalログを出力した上で再送出する。(デプロイエラーになる。) | -| Webフロントコントローラ (サーブレットフィルタ) | nablarch.fw.web.servlet.WebFrontController | ServletRequest/Response | - | HttpServletRequest/HttpServletResponseからHTTPリクエストオブジェクトを作成し、ハンドラキューに処理を委譲する。 | (Webコンテナ側に制御を戻す。) | このハンドラでは例外およびエラーの捕捉は行なわず、そのまま送出する。 | - -**関連するハンドラ** - -| ハンドラ | 内容 | -|---|---| -| [Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md) | 本クラスは **NablarchServletContextListener** によって初期化される。 | - -### 処理フロー - -**[往路処理]** - -**1. (HTTPリクエストオブジェクト、実行コンテキストの生成)** - -`HttpServletRequest`/`HttpServletResponse` をラップした -HTTPリクエストオブジェクトおよび実行コンテキストを生成する。 - -**2. (ハンドラキューに対する処理委譲)** - -このサーブレットフィルタに設定されたハンドラキュー内の先頭ハンドラを、 -**2.** で作成したHTTPリクエストオブジェクトおよび実行コンテキストを引数として -実行する。 - -**[往路処理]** - -**3. (正常終了)** - -ハンドラキューでの処理が正常に終了した時点で、当該リクエストに対する処理を終了し、 -サーブレットコンテナ側に制御を戻す。 - -**[例外処理]** - -**3a. (後続ハンドラ処理中のエラー)** - -ハンドラキューでの処理中に例外が送出された場合、特段の例外制御は行なわず -発生した例外をそのまま送出する。 - -ただし、標準ハンドラ構成では、このハンドラの直後に [グローバルエラーハンドラ](../../component/handlers/handlers-GlobalErrorHandler.md) が配置されるため、 -サーバプロセスの継続に影響するような特定の致命的エラーを除けば、ここで例外を捕捉することは無い。 - -### 設定項目・拡張ポイント - -本クラスの設定項目の一覧は以下のとおり。 - -| 設定項目 | プロパティ名 | データ型 | 備考 | -|---|---|---|---| -| ハンドラキュー | handlerQueue | List | 必須指定 | - -**標準設定** - -```xml - - - - - - - - - - - - - - - -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-handler.md b/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-handler.md deleted file mode 100644 index 8527c6914..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/handlers/handlers-handler.md +++ /dev/null @@ -1,60 +0,0 @@ -# ハンドラリファレンス - -## 汎用のハンドラ - -DataReadHandler -GlobalErrorHandler -FileRecordWriterDisposeHandler -RequestPathJavaPackageMapping -RequestHandlerEntry -ThreadContextHandler -ThreadContextClearHandler -DbConnectionManagementHandler -TransactionManagementHandler -PermissionCheckHandler -ServiceAvailabilityCheckHandler -SessionConcurrentAccessHandler -RetryHandler - -## 画面オンライン処理用ハンドラ - -NablarchServletContextListener -WebFrontController -HttpCharacterEncodingHandler -HttpResponseHandler -HttpErrorHandler -ForwardingHandler -ResourceMapping -NablarchTagHandler -HttpAccessLogHandler -MultipartHandler -HttpRequestJavaPackageMapping -HttpRewriteHandler -KeitaiAccessHandler - -## バッチ処理用ハンドラ - -Main -StatusCodeConvertHandler -ProcessStopHandler -DuplicateProcessCheckHandler -ProcessResidentHandler -LoopHandler -MultiThreadExecutionHandler - -## メッセージング処理用ハンドラ - -MessagingContextHandler -MessageResendHandler -MessageReplyHandler -RequestThreadLoopHandler - -## 業務アクションハンドラ - -HttpMethodBinding -BatchAction -FileBatchAction -NoInputDataBatchAction -MessagingAction -AsyncMessageReceiveAction -AsyncMessageSendAction diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-01-FailureLog.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-01-FailureLog.md deleted file mode 100644 index f4daac71c..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-01-FailureLog.md +++ /dev/null @@ -1,736 +0,0 @@ -# 障害ログの出力 - -障害ログは、フレームワーク又はアプリケーションから出力することを想定している。 -フレームワークでは、処理方式毎の例外ハンドラにおいて出力する。 -アプリケーションでは、バッチ処理の障害発生時に後続処理を継続する場合などに出力する。 - -## 障害ログの出力方針 - -障害通知ログと障害解析ログで想定している出力方針を下記に示す。 -障害通知ログは、ログ監視ツールから監視することで障害を検知することを想定しているので、 -ロガー名を付けて障害通知専用のファイルに出力する。 -障害解析ログは、アプリケーション全体のログ出力を行うアプリケーションログに出力する。 - -| ログの種類 | ログレベル | ロガー名 | -|---|---|---| -| 障害通知ログ | FATAL、ERROR | MONITOR | -| 障害解析ログ | FATAL、ERROR | 指定なし(クラス名) | - -上記出力方針に対するログ出力の設定例を下記に示す。 - -log.propertiesの設定例 - -```bash -writerNames=monitorFile,appFile - -# 障害通知ログの出力先 -writer.monitorFile.className=nablarch.core.log.basic.SynchronousFileLogWriter -writer.monitorFile.filePath=/var/log/app/monitor.log -writer.monitorFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.monitorFile.formatter.format=<障害通知ログ用のフォーマット> -writer.monitorFile.lockFilePath=/var/log/lock/monitor.lock -writer.monitorFile.lockRetryInterval=10 -writer.monitorFile.lockWaitTime=3000 -writer.monitorFile.failureCodeCreateLockFile=MSG00101 -writer.monitorFile.failureCodeReleaseLockFile=MSG00102 -writer.monitorFile.failureCodeForceDeleteLockFile=MSG00103 -writer.monitorFile.failureCodeInterruptLockWait=MSG00104 - -# アプリケーションログの出力先 -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=/var/log/app/app.log -writer.appFile.maxFileSize=10000 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=<アプリケーションログ用のフォーマット> - -availableLoggersNamesOrder=MON,ROO - -# アプリケーションログの設定 -loggers.ROO.nameRegex=.* -loggers.ROO.level=INFO -loggers.ROO.writerNames=appFile - -# 障害通知ログの出力設定 -loggers.MON.nameRegex=MONITOR -loggers.MON.level=ERROR -loggers.MON.writerNames=monitorFile -``` - -## 障害ログの出力項目 - -障害通知ログと障害解析ログの出力項目を下記に示す。 -障害通知ログと障害解析ログ毎に出力を想定している項目には、Yマークを入れている。 - -障害通知ログは、ログ監視ツールから通知を受けた運用オペレータが1次切り分け担当者の特定に使用する。 -運用オペレータは、障害通知ログのリクエストIDを参照し、1次切り分け担当者を特定することを想定しているため、 -リクエストIDには、業務コードなど、1次切り分け担当者を特定できるだけの情報(下記ノートを参照)を含める必要がある。 -リクエストIDに1次切り分け担当者を特定できるだけの情報を含めることができない場合は、 [障害の連絡先情報の追加方法](../../component/libraries/libraries-01-FailureLog.md#障害の連絡先情報の追加方法) を使用することで、 -リクエストID毎に連絡先情報をログに含めることができる。 - -| 項目名 | 説明 | 障害通知 | 障害解析 | -|---|---|---|---| -| 出力日時 | ログ出力時のシステム日時。 | Y | Y | -| 障害レベル | 障害のレベルを判断するために使用する。 | Y | Y | -| 障害コード | 障害を一意に識別するコード。障害内容の特定に使用する。 | Y | Y | -| 起動プロセス | 障害が発生したアプリケーションを起動したプロセス名。実行環境の特定に使用する。 | Y | Y | -| 処理方式区分 | 障害が発生した処理方式の特定に使用する。 | Y | Y | -| リクエストID | 障害が発生した処理を一意に識別するID。1次切り分け担当者の特定に使用する。 | Y | Y | -| 実行時ID | 障害が発生した処理の実行を一意に識別するID。 | Y | Y | -| ユーザID | ログインユーザのユーザID。 | Y | Y | -| メッセージ | 障害コードに対応するメッセージ。障害内容の特定に使用する。 | Y | Y | -| 処理対象データ | 障害が発生した処理が対象としていたデータを特定するために使用する。 データリーダを使用して読み込まれたデータオブジェクトのtoStringメソッド を呼び出し出力される。 > **Warning:** > システムのセキュリティ要件により、 > 障害解析ログであっても個人情報や機密情報の出力が許されない場合は、 > この項目に対する出力処理をプロジェクトでカスタマイズすること。 > カスタマイズ方法は、 [プレースホルダのカスタマイズ方法](../../component/libraries/libraries-01-FailureLog.md#プレースホルダのカスタマイズ方法) を参照。 > **Note:** > 処理対象データの出力により、障害ログに派生元実行時情報を出力することができる。 > 派生元実行時情報とは、例えば、画面処理からバッチ処理にデータ連携する場合であれば、 > 画面処理を実行した時点の実行時情報(リクエストIDや実行時IDなど)が > バッチ処理での派生元実行時情報となる。 > 派生元実行時情報の出力方法は、 [派生元実行時情報の出力方法](../../component/libraries/libraries-01-FailureLog.md#派生元実行時情報の出力方法) を参照。 | | Y | -| スタックトレース | 障害発生箇所の特定に使用する。 | | Y | -| 付加情報 | フレームワーク又はアプリケーションで追加する付加情報。 | | Y | - -障害ログの個別項目は下記となる。残りの項目は、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) の設定で指定する共通項目となる。 -共通項目と個別項目を組み合わせたフォーマットについては、 [各種ログの共通項目のフォーマット](../../component/libraries/libraries-01-Log.md#各種ログの共通項目のフォーマット) を参照。 - -* 障害コード -* メッセージ -* 処理対象データ - -> **Note:** -> 起動プロセスとリクエストIDは、システムの規模に応じてプロジェクト毎にID体系を規定する。 -> 例えば、大規模なシステムでは、下記のようなID体系となる。 - -> 起動プロセス: - -> サーバ名(8桁)＋識別文字列(4桁)･･･識別文字列にはバッチ処理のJOBIDなどが入る。 - -> リクエストID: - -> システムID(1桁)＋サブシステムID(2桁)＋業務コード(3桁)＋画面ID(2桁)+イベントID(2桁) - -## 障害ログの出力方法 - -障害ログの出力に使用するクラスを下記に示す。 - -![Log_FailureLog_ClassDiagram.jpg](../../../knowledge/assets/libraries-01-FailureLog/Log_FailureLog_ClassDiagram.jpg) - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.app.FailureLogUtil | 障害ログを出力するクラス。 | -| nablarch.core.log.app.FailureLogFormatter | 障害ログの個別項目をフォーマットするクラス。 | -| nablarch.fw.TransactionAbnormalEnd | トランザクションデータの処理中に異常が発生した場合に送出する例外クラス。 この例外は、フレームワークの例外ハンドラに捕捉され、障害ログの出力に使用される。 この例外に障害コードを指定することで、障害コードに対応するメッセージが障害ログに出力される。 | -| nablarch.fw.launcher.ProcessAbnormalEnd | アプリケーションを異常終了させる際に送出する例外クラス。 この例外は、TransactionAbnormalEndを継承しており使用方法はTransactionAbnormalEndと同じである。 | - -アプリケーションでの障害ログの出力は、下記の2通りの方法がある。 - -* FailureLogUtilを使用して直接出力する。 -* TransactionAbnormalEndやProcessAbnormalEndを送出し例外ハンドラに出力を依頼する。 - -障害ログを出力し業務処理を終了する場合は、TransactionAbnormalEndやProcessAbnormalEndを使用する。 -障害ログを出力するが後続の業務処理を継続する場合は、FailureLogUtilを使用する。 -FailureLogUtilを使用した場合は、例外が送出されるわけではないのでトランザクションがコミットされる。 - -ProcessAbnormalEndの使用例を下記に示す。 - -※TransactionAbnormalEndを使用した場合の実装例は、ProcessAbnormalEndと全く同じとなる。 -このため、本実装例での説明は省略する。 - -```java -// 障害ログを出力し業務処理を終了する場合 - -// バリデーションエラーの場合 -ValidationContext context = - ValidationUtil.validateAndConvertRequest("user", UserForm.class, inputData, "registerUser"); -if (!context.isValid()) { - // 終了コード、バリデーションの例外、障害コードを指定している。 - // 終了コードとはプロセスを終了する際に System#exit(int) メソッドに設定する値である。 - throw new ProcessAbnormalEnd(100, new ApplicationException(context.getMessages()), "UM900001"); -} - -// 自ら例外を生成する場合 -if (user == null) { - // 終了コード、障害コードを指定している。 - throw new ProcessAbnormalEnd(100, "UM900002"); -} - -// 例外を捕捉した場合 -try { - // 業務処理 -} catch (UserNotFoundException e) { - // 終了コード、捕捉した例外、障害コードを指定している。 - throw new ProcessAbnormalEnd(100, e, "UM900003"); -} -``` - -FailureLogUtilの使用例を下記に示す。 - -```java -// 障害ログを出力し後続処理を継続する場合 - -// 障害を検知した場合 -if (user == null) { - // 処理対象データ、障害コードを指定している。 - FailureLogUtil.logError(inputData, "UM800001"); -} - -// 例外を捕捉した場合 -try { - // 業務処理 -} catch (UserNotFoundException e) { - // 捕捉した例外、処理対象データ、障害コードを指定している。 - FailureLogUtil.logError(e, inputData, "UM800001"); -} -``` - -上記使用例のように、障害ログの出力では、ログから障害内容を特定するために障害コードを指定する。 -障害コードのコード体系は、プロジェクト毎に規定すること。 - -障害ログに出力されるメッセージは、 [メッセージ管理](../../component/libraries/libraries-07-Message.md) 機能を使用して障害コードに対応するメッセージを取得する。 -[メッセージ管理](../../component/libraries/libraries-07-Message.md) 機能では、メッセージが見つからない場合に例外が発生する。 -メッセージ取得処理で例外が発生した場合は、障害ログとは別に、メッセージ取得処理で発生した例外をWARNレベルでログ出力し、 -障害ログには下記のメッセージを出力する。 - -```bash -failed to get the message to output the failure log. failureCode = [<障害コード>] -``` - -メッセージが見つからない場合の障害通知ログの出力例を下記に示す。 - -```bash -# 障害コード(fail_code = [AP112233])の後にメッセージを出力している。 -2011-02-23 18:23:45.680 -FATAL- usr_id = [9999999999] fail_code = [AP112233] failed to get the message to output the failure log. failureCode = [AP112233] -``` - -ソース上で指定した障害コードは、設定によりアプリケーションの実行時に変更することができる。 -アプリケーションの障害コードの変更方法については、 [アプリケーションの障害コードの変更方法](../../component/libraries/libraries-01-FailureLog.md#アプリケーションの障害コードの変更方法) を参照。 -また、フレームワークで例外が発生した場合の障害コードの変更方法については、 [フレームワークの障害コードの変更方法](../../component/libraries/libraries-01-FailureLog.md#フレームワークの障害コードの変更方法) を参照。 - -フレームワークの例外ハンドラでRuntimeExceptionを捕捉した場合など、障害コードの指定がない場合は、 -設定で指定するデフォルトの障害コードとメッセージを出力する。 - -## 障害ログの設定方法 - -FailureLogUtilは、プロパティファイル(app-log.properties)を読み込み、 -FailureLogFormatterオブジェクトを生成して、個別項目のフォーマット処理を委譲する。 -プロパティファイルのパス指定や実行時の設定値の変更方法は、 [各種ログの設定](../../component/libraries/libraries-01-Log.md#各種ログの設定) を参照。 -障害ログの設定例を下記に示す。 - -app-log.propertiesの設定例 - -```bash -failureLogFormatter.className=nablarch.core.log.app.FailureLogFormatter -failureLogFormatter.defaultFailureCode=ZZ999999 -failureLogFormatter.defaultMessage=an unexpected exception occurred. -failureLogFormatter.language=en -failureLogFormatter.notificationFormat=fail_code = [$failureCode$] $message$ -failureLogFormatter.analysisFormat=fail_code = [$failureCode$] $message$ -failureLogFormatter.derivedRequestIdPropName=insertRequestId -failureLogFormatter.derivedUserIdPropName=updatedUserId -failureLogFormatter.contactFilePath=classpath:failure-log-contact.properties -failureLogFormatter.appFailureCodeFilePath=classpath:failure-log-app-codes.properties -failureLogFormatter.fwFailureCodeFilePath=classpath:failure-log-fw-codes.properties -``` - -プロパティの説明を下記に示す。 - -| プロパティ名 | 設定値 | -|---|---| -| failureLogFormatter.className | FailureLogFormatterのクラス名。 デフォルトはnablarch.core.log.app.FailureLogFormatter。 FailureLogFormatterを差し替える場合に指定する。 | -| failureLogFormatter.defaultFailureCode(必須) | デフォルトの障害コード。 例外ハンドラでRuntimeExceptionを捕捉した場合など、障害コードの指定がない場合に使用する。 | -| failureLogFormatter.defaultMessage(必須) | デフォルトのメッセージ。 デフォルトの障害コードを使用する場合に出力するメッセージ。 | -| failureLogFormatter.language | メッセージの言語。 障害コードからメッセージを取得する際に使用する言語。 指定がない場合はThreadContextに設定されている言語を使用する。 | -| failureLogFormatter.notificationFormat | 障害通知ログの個別項目のフォーマット。 | -| failureLogFormatter.analysisFormat | 障害解析ログの個別項目のフォーマット。 | -| failureLogFormatter.contactFilePath | 障害の連絡先情報を指定したプロパティファイルのパス。 障害の連絡先情報を出力する場合に指定する。 詳細は [障害の連絡先情報の追加方法](../../component/libraries/libraries-01-FailureLog.md#障害の連絡先情報の追加方法) を参照。 | -| failureLogFormatter.appFailureCodeFilePath | アプリケーションの障害コードの変更情報を指定したプロパティファイルのパス。 障害ログ出力時にアプリケーションの障害コードを変更する場合に指定する。 詳細は [アプリケーションの障害コードの変更方法](../../component/libraries/libraries-01-FailureLog.md#アプリケーションの障害コードの変更方法) を参照。 | -| failureLogFormatter.fwFailureCodeFilePath | フレームワークの障害コードの変更情報を指定したプロパティファイルのパス。 障害ログ出力時にフレームワークの障害コードを変更する場合に指定する。 詳細は [フレームワークの障害コードの変更方法](../../component/libraries/libraries-01-FailureLog.md#フレームワークの障害コードの変更方法) を参照。 | - -フォーマットに指定可能なプレースホルダの一覧を下記に示す。 - -| 項目名 | プレースホルダ | -|---|---| -| 障害コード | $failureCode$ | -| メッセージ | $message$ | -| 処理対象データ | $data$ | -| 連絡先 | $contact$ | - -デフォルトのフォーマットを下記に示す。 - -```bash -fail_code = [$failureCode$] $message$ -``` - -## 障害ログの出力例 - -障害ログの出力例を下記に示す。 -データベースに接続できない障害が発生したため、FailureLogFormatterの設定で指定したデフォルトの障害コードとデフォルトのメッセージが出力されている。 - -app-log.propertiesの設定例 - -```bash -# FailureLogFormatterの設定(デフォルトの障害コードと個別項目のフォーマット) -failureLogFormatter.defaultFailureCode=ZZ999999 -failureLogFormatter.defaultMessage=an unexpected exception occurred. -failureLogFormatter.notificationFormat=[$failureCode$:$message$] -failureLogFormatter.analysisFormat=fail_code = [$failureCode$] $message$ -``` - -log.propertiesの設定例 - -```bash -writerNames=monitorFile,appFile - -# 障害通知ログの出力先 -writer.monitorFile.className=nablarch.core.log.basic.SynchronousFileLogWriter -writer.monitorFile.filePath=/var/log/app/monitor.log -writer.monitorFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.monitorFile.formatter.format=$date$ -$logLevel$- [$executionId$] R[$requestId$] U[$userId$] $message$ -writer.monitorFile.lockFilePath=/var/log/lock/monitor.lock -writer.monitorFile.lockRetryInterval=10 -writer.monitorFile.lockWaitTime=3000 -writer.monitorFile.failureCodeCreateLockFile=MSG00101 -writer.monitorFile.failureCodeReleaseLockFile=MSG00102 -writer.monitorFile.failureCodeForceDeleteLockFile=MSG00103 -writer.monitorFile.failureCodeInterruptLockWait=MSG00104 - -# アプリケーションログの出力先 -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=/var/log/app/app.log -writer.appFile.maxFileSize=10000 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=$date$ -$logLevel$- [$executionId$] R[$requestId$] U[$userId$] $message$$information$$stackTrace$ - -availableLoggersNamesOrder=MON,ROO - -# アプリケーションログの設定 -loggers.ROO.nameRegex=.* -loggers.ROO.level=INFO -loggers.ROO.writerNames=appFile - -# 障害通知ログの出力設定 -loggers.MON.nameRegex=MONITOR -loggers.MON.level=ERROR -loggers.MON.writerNames=monitorFile -``` - -ログの出力例 - -```bash -# 障害通知ログ -2011-02-15 14:47:17.745 -FATAL- [APUSRMGR0001201102151447176990004] R[USERS00101] U[0000000001] [ZZ999999:an unexpected exception occurred.] - -# 障害解析ログ -2011-02-15 14:47:17.745 -FATAL- [APUSRMGR0001201102151447176990004] R[USERS00101] U[0000000001] fail_code = [ZZ999999] an unexpected exception occurred. -Stack Trace Information : -nablarch.core.db.DbAccessException: failed to get database connection. - at nablarch.core.db.connection.BasicDbConnectionFactoryForDataSource.getConnection(BasicDbConnectionFactoryForDataSource.java:35) - at nablarch.common.handler.DbConnectionManagementHandler.handle(DbConnectionManagementHandler.java:72) - at nablarch.common.handler.DbConnectionManagementHandler.handle(DbConnectionManagementHandler.java:1) - at nablarch.fw.ExecutionContext.handleNext(ExecutionContext.java:59) - # 以降のスタックトレースは省略。 -``` - -## 障害の連絡先情報の追加方法 - -障害ログの出力では、リクエストIDに1次切り分け担当者を特定するための情報として、業務コードなどを含めることを推奨している。 -しかし、プロジェクトによっては、リクエストIDに1次切り分け担当者を特定するための情報を含めることができないケースが考えられる。 -このため、障害ログの出力では、リクエストID毎に1次切り分け担当者の連絡先情報を指定する機能を提供する。 - -連絡先情報の追加は、プロパティファイルに指定する。キーにリクエストID、値に連絡先情報を指定する。 -キーに指定されたリクエストIDは、ThreadContextから取得したリクエストIDに対して、前方一致で検索する。 -このため、プロパティファイルの内容は読み込み後に、より限定的なリクエストIDから検索するように、キー名の長さの降順にソートする。 - -連絡先情報の追加例を下記に示す。 - -ます、プロパティファイルを準備する。 -"failure-log-contact.properties"というファイル名でクラスパス直下に配置しているものとする。 - -failure-log-contact.propertiesの設定例 - -```bash -# リクエストID=連絡先情報 -USERS=USRMGR999 -USERS003=USRMGR300 -USERS00301=USRMGR301 -USERS00302=USRMGR302 -USERS00303=USRMGR303 -``` - -上記プロパティファイルは、読み込み後下記の通りソートされ、上から順に検索に使用する。 - -```bash -# 上3つの並び順は、キー名の長さが等しいため、実行毎に変わる。 -USERS00301=USRMGR301 -USERS00302=USRMGR302 -USERS00303=USRMGR303 -USERS003=USRMGR300 -USERS=USRMGR999 -``` - -次に、障害ログのフォーマットで連絡先情報を表すプレースホルダ$contact$を指定する。 -さらに、プロパティファイルのパスを指定する。 - -app-log.propertiesの設定例 - -```bash -# FailureLogFormatterの設定 -failureLogFormatter.defaultFailureCode=ZZ999999 -failureLogFormatter.defaultMessage=an unexpected exception occurred. -failureLogFormatter.notificationFormat=[$failureCode$:$message$] <$contact$> -failureLogFormatter.analysisFormat=fail_code = [$failureCode$] $message$ <$contact$> -failureLogFormatter.contactFilePath=classpath:failure-log-contact.properties -``` - -上記の設定により、リクエストID毎に連絡先情報が出力される。 -リクエストIDが"USERS00302"の場合に発生した障害の出力例を下記に示す。 -$contact$を指定した箇所(<>で囲った部分)に"USRMGR"が出力される。 - -```bash -# 障害通知ログ -2011-02-15 15:09:57.691 -FATAL- [APUSRMGR0001201102151509320020009] R[USERS00302] U[0000000001] [ZZ999999:an unexpected exception occurred.] - -# 障害解析ログ -2011-02-15 15:09:57.707 -FATAL- [APUSRMGR0001201102151509320020009] R[USERS00302] U[0000000001] fail_code = [ZZ999999] an unexpected exception occurred. -# スタックトレースは省略。 -``` - -リクエストIDに対応する連絡先情報が見つからない場合はnullが出力される。 -連絡先情報が見つからない場合の障害通知ログの出力例を下記に示す。 - -```bash -# 障害通知ログ -# プロパティファイルにリクエストID"USERS00333"が定義されていないので連絡先情報はnullとなる。 -2011-02-15 15:09:57.691 -FATAL- [APUSRMGR0001201102151509320020009] R[USERS00333] U[0000000001] [ZZ999999:an unexpected exception occurred.] -``` - -## アプリケーションの障害コードの変更方法 - -アプリケーションでは、TransactionAbnormalEnd(ProcessAbnormalEnd)やFailureLogUtilを使用して障害ログの出力を行う。 -この場合、アプリケーションでは、ソースコード上に直接障害コードを書き込む(ハードコーディング)。 -障害ログの出力では、ソースコードに修正を加えることなく、アプリケーションの実行時にソースコード上にハードコードされた障害コードを変更することができる。 - -障害コードの変更は、プロパティファイルに指定する。 -プロパティファイルには、ソースコード上の障害コード毎に出力に使用する障害コードを指定する。 - -アプリケーションの障害コードの変更例を下記に示す。 -アプリケーションで下記のProcessAbnormalEndを送出していることを想定する。 -※TransactionAbnormalEndの使用方法は、ProcessAbnormalEndと全く同じであるためここでの説明は省略する。 - -```java -if (userId == null) { - throw new ProcessAbnormalEnd(100, "UM900003"); -} -``` - -ます、プロパティファイルを準備する。 -"failure-log-app-codes.properties"というファイル名でクラスパス直下に配置しているものとする。 - -failure-log-app-codes.propertiesの設定例 - -```bash -# ソース上の障害コード=出力に使用する障害コード -UM900003=MSG9003 -``` - -次に、FailureLogFormatterの設定でプロパティファイルのパスを指定する。 - -app-log.propertiesの設定例 - -```bash -# FailureLogFormatterの設定 -failureLogFormatter.defaultFailureCode=ZZ999999 -failureLogFormatter.defaultMessage=an unexpected exception occurred. -failureLogFormatter.notificationFormat=[$failureCode$:$message$] -failureLogFormatter.analysisFormat=fail_code = [$failureCode$] $message$ -failureLogFormatter.appFailureCodeFilePath=classpath:failure-log-app-codes.properties -``` - -上記の設定により、ソース上で指定された障害コード毎に出力に使用する障害コードが変更される。 -ProcessAbnormalEndが送出された場合の出力例を下記に示す。 -障害コードが"UM900003"から"MSG9003"に変更されて出力される。 - -```bash -# 障害通知ログ -2011-02-15 15:52:30.394 -FATAL- [APUSRMGR0001201102151552085470006] R[USERS00302] U[0000000001] [MSG9003:userId was invalid.] - -# 障害解析ログ -2011-02-15 15:52:30.394 -FATAL- [APUSRMGR0001201102151552085470006] R[USERS00302] U[0000000001] fail_code = [MSG9003] userId was invalid. -# スタックトレースは省略。 -``` - -ソース上で指定された障害コードに対応する出力に使用する障害コードが見つからない場合は、ソース上で指定された障害コードを使用する。 - -## フレームワークの障害コードの変更方法 - -フレームワークでは、想定しないエラーが発生した際にRuntimeException系の例外を送出している。 -その結果、フレームワークが送出した例外は、全てデフォルトの障害コードが使用されて障害ログが出力される。 -障害監視において、障害コードにより監視対象をフィルタリングしたいケースが考えられるため、 -障害ログの出力では、フレームワークの障害コードを指定する機能を提供する。 - -フレームワークの障害コードは、例外が送出されたクラス名毎に指定することができる。 -「例外が送出されたクラス」とは、スタックトレースのルート要素を指している。 -例えば、下記のスタックトレースであれば、nablarch.core.message.StringResourceHolderクラスとなる。 - -```bash -Stack Trace Information : -java.lang.RuntimeException: ValidateFor method invocation failed. targetClass = java.lang.Class, method = validateForRegisterUser - at nablarch.core.validation.ValidationManager.validateAndConvert(ValidationManager.java:202) - # 途中のスタックトレースは省略。 -Caused by: nablarch.core.message.MessageNotFoundException: message was not found. message id = MSG00010 - at nablarch.core.message.StringResourceHolder.get(StringResourceHolder.java:40) - # 以降のスタックトレースは省略。(以降Caused byは出現しない) -``` - -ただし、フレームワークのクラス毎に障害コードを設定するのは、分類が細かすぎるため現実的ではない。 -基本はパッケージ名単位に障害コードを指定することで、フレームワークのどの機能で例外が送出されたか判断することができる。 - -フレームワークの障害コードは、プロパティファイルに指定する。 -プロパティファイルでは、キーにフレームワークのパッケージ名、値に障害コードを指定する。 -キーに指定されたパッケージ名は、スタックトレースから取得した例外が送出されたクラスのFQCN(完全修飾クラス名)に対して、前方一致で検索する。 -このため、プロパティファイルの内容は読み込み後に、より限定的なパッケージ名から検索するように、キー名の長さの降順にソートする。 - -フレームワークの障害コードの変更例を下記に示す。 - -ます、プロパティファイルを準備する。 -"failure-log-fw-codes.properties"というファイル名でクラスパス直下に配置しているものとする。 -nablarchというパッケージ名を指定することで、個別に指定していない全てのパッケージに対して障害コードを指定できる。 - -failure-log-fw-codes.propertiesの設定例 - -```bash -# フレームワークのパッケージ名=障害コード -nablarch=FW999999 -nablarch.core.cache=FW020100 -nablarch.core.date=FW020200 -nablarch.core.db=FW020300 -nablarch.core.message=FW020400 -nablarch.core.repository=FW020500 -nablarch.core.transaction=FW020600 -``` - -上記プロパティファイルは、読み込み後下記の通りソートされ、上から順に検索に使用する。 - -```bash -nablarch.core.transaction=FW020600 -nablarch.core.repository=FW020500 -nablarch.core.message=FW020400 -nablarch.core.cache=FW020100 -nablarch.core.date=FW020200 -nablarch.core.db=FW020300 -nablarch=FW999999 -``` - -次に、FailureLogFormatterの設定でプロパティファイルのパスを指定する。 - -app-log.propertiesの設定例 - -```bash -# FailureLogFormatterの設定 -failureLogFormatter.defaultFailureCode=ZZ999999 -failureLogFormatter.defaultMessage=an unexpected exception occurred. -failureLogFormatter.notificationFormat=[$failureCode$:$message$] -failureLogFormatter.analysisFormat=fail_code = [$failureCode$] $message$ -failureLogFormatter.fwFailureCodeFilePath=classpath:failure-log-fw-codes.properties -``` - -上記の設定により、フレームワークの障害コードが変更される。 -障害通知ログでいくつか出力例を下記に示す。 - -nablarch.core.date.BasicBusinessDateProviderクラスで例外を送出した場合 - -```bash -# プロパティファイルのnablarch.core.date=FW020200が該当する。 -2011-02-15 16:48:54.993 -FATAL- [APUSRMGR0001201102151648315060002] R[LOGIN00102] U[9999999999] fail_code = [FW020200] segment was not found. segment:00. -Stack Trace Information : -java.lang.IllegalStateException: segment was not found. segment:00. - at nablarch.core.date.BasicBusinessDateProvider.getDate(BasicBusinessDateProvider.java:103) - # 以降のスタックトレースは省略。 -``` - -nablarch.core.message.StringResourceHolderクラスで例外を送出した場合 - -```bash -# プロパティファイルのnablarch.core.message=FW020400が該当する。 -2011-02-15 16:54:06.413 -FATAL- [APUSRMGR0001201102151653476260011] R[USERS00201] U[0000000001] fail_code = [FW020400] ValidateFor method invocation failed. targetClass = java.lang.Class, method = validateForRegisterUser -Stack Trace Information : -java.lang.RuntimeException: ValidateFor method invocation failed. targetClass = java.lang.Class, method = validateForRegisterUser - at nablarch.core.validation.ValidationManager.validateAndConvert(ValidationManager.java:202) - # 途中のスタックトレースは省略。 -Caused by: nablarch.core.message.MessageNotFoundException: message was not found. message id = MSG00010 - at nablarch.core.message.StringResourceHolder.get(StringResourceHolder.java:40) - # 以降のスタックトレースは省略。 -``` - -nablarch.common.authentication.PasswordAuthenticatorクラスで例外を送出した場合 - -```bash -# プロパティファイルのnablarch=FW999999が該当する。 -2011-02-15 16:59:03.076 -FATAL- [APUSRMGR0001201102151658551890017] R[LOGIN00102] U[9999999999] fail_code = [FW999999] authentication failed. -Stack Trace Information : -nablarch.common.authentication.AuthenticationFailedException - at nablarch.common.authentication.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:302) - # 以降のスタックトレースは省略。 -``` - -## 派生元実行時情報の出力方法 - -派生元実行時情報とは、例えば、画面処理からバッチ処理にデータ連携する場合であれば、 -画面処理を実行した時点の実行時情報がバッチ処理での派生元実行時情報となる。 -以降では、処理方式間でデータ連携した場合に、先に処理を行う側を前段処理、後に処理を行う側を後段処理と呼ぶ。 -後段処理における障害発生時に、前段処理の追跡作業を軽減するために派生元実行時情報を出力する。 - -派生元実行時情報の出力には、本機能のプレースホルダ「$data$」が使用できる。 -プレースホルダ「$data$」が指定された場合、データリーダを使用して読み込まれたデータが障害ログに出力される。 -この機能を使用して、前段処理において予め実行時情報をデータに含めておくことで、 -後段処理の障害発生時に処理対象データとして前段処理の実行時情報が出力されることになる。 - -前段処理における実行時情報の設定には、 [オブジェクトのフィールドの値のデータベースへの登録機能(オブジェクトのフィールド値を使用した検索機能)](../../component/libraries/libraries-04-ObjectSave.md#オブジェクトのフィールドの値のデータベースへの登録機能オブジェクトのフィールド値を使用した検索機能) を使用する。 -スレッドコンテキストに設定されたリクエストID、実行時ID、ユーザIDをオブジェクトに設定するアノテーションを提供している。 -アノテーションの詳細については、 [AutoPropertyHandlerの実装クラス](../../component/libraries/libraries-04-ObjectSave.md#nablarchcoredbstatementsqlconvertorパッケージ) を参照。 - -ここでは、データベースを使用したデータ連携における派生元実行時情報の出力例を示す。 -前段処理において下記のカラム名で実行時情報が設定されていることとする。 - -| 項目 | カラム名 | -|---|---| -| リクエストID | INSERT_REQUEST_ID | -| 実行時ID | INSERT_EXECUTION_ID | -| ユーザID | UPDATED_USER_ID | - -app-log.propertiesの設定例 - -```bash -# FailureLogFormatterの設定 -failureLogFormatter.defaultFailureCode=MSG99999 -failureLogFormatter.defaultMessage=an unexpected exception occurred. -failureLogFormatter.notificationFormat=fail_code = [$failureCode$] $message$ -# 処理対象データのプレースホルダ「data」を障害解析ログのフォーマットに指定する。 -failureLogFormatter.analysisFormat=fail_code = [$failureCode$] $message$\nInput Data :\n$data$ -``` - -障害解析ログの出力例 - -```bash -# 障害解析ログ -2011-09-26 21:06:35.745 -FATAL- root [EXECUTION_ID_0000000123456789] boot_proc = [] proc_sys = [] req_id = [RB11AC0160] usr_id = [batchuser1] fail_code = [NB11AA0107] ユーザ情報の登録に失敗しました。 -Input Data : -{MOBILE_PHONE_NUMBER_AREA_CODE=002, KANJI_NAME=山本太郎, USER_INFO_ID=00000000000000000113, INSERT_EXECUTION_ID=EXECUTION_ID_2000000123456789, MAIL_ADDRESS=yamamoto@sample.com, MOBILE_PHONE_NUMBER_CITY_CODE=0003, UPDATED_USER_ID=batch_user, MOBILE_PHONE_NUMBER_SBSCR_CODE=0004, KANA_NAME=ヤマモトタロウ, EXTENSION_NUMBER_BUILDING=13, LOGIN_ID=12345678901234567890, EXTENSION_NUMBER_PERSONAL=1235, INSERT_REQUEST_ID=RB11AC0140} -Stack Trace Information : -[100 TransactionAbnormalEnd] ユーザ情報の登録に失敗しました。 - at nablarch.sample.ss11AC.B11AC016Action.handle(B11AC016Action.java:73) - at nablarch.sample.ss11AC.B11AC016Action.handle(B11AC016Action.java:1) - at nablarch.fw.action.BatchAction.handle(BatchAction.java:1) - # 以降のスタックトレースは省略。 -``` - -処理対象データ(出力例の「Input Data :」)に下記の実行時情報が出力される。 - -```bash -INSERT_REQUEST_ID=RB11AC0140 -INSERT_EXECUTION_ID=EXECUTION_ID_2000000123456789 -UPDATED_USER_ID=batch_user -``` - -## プレースホルダのカスタマイズ方法 - -処理対象データ($data$)はデフォルトでtoStringメソッドにより全てのデータ項目が出力されるため、 -プロジェクトのセキュリティ要件で特定項目をマスクした出力が要求されるケースが考えられる。 -このように、プレースホルダに対する出力処理をカスタマイズしたい場合は、 -フォーマット処理を行うFailureLogFormatterの拡張と各項目の出力内容を提供するLogItemインタフェースの実装を行う。 - -ここでは、処理対象データ($data$)に対する出力処理のカスタマイズ例を示す。 - -まず、処理対象データ($data$)に対する出力内容を提供するクラスの実装例を示す。 -今回はフレームワークが提供するDataItemクラスを継承して作成し、 -処理対象データがMap型の場合のみマスク処理を行うように実装している。 - -処理対象データ($data$)に対する出力内容を提供するクラスの実装例 - -```java -// FailureLogFormatterの拡張クラスにインナークラスとして定義している。 -private static final class CustomDataItem extends DataItem { - - /** マスク文字 */ - private static final char MASKING_CHAR = '*'; - - /** マスク対象のパターン */ - private static final Pattern[] MASKING_PATTERNS - = new Pattern[] { Pattern.compile(".*MOBILE_PHONE_NUMBER.*"), - Pattern.compile(".*MAIL.*")}; - - /** - * マップの値をマスキングするエディタ。 - * フレームワークが提供するMap編集用のユーティリティ。 - */ - private MapValueEditor mapValueEditor = new MaskingMapValueEditor(MASKING_CHAR, MASKING_PATTERNS); - - @Override - @SuppressWarnings("unchecked") - public String get(FailureLogContext context) { - - // FailureLogContextのgetDataメソッドを呼び出し処理対象データを取得する。 - Object data = context.getData(); - - // Mapでない場合はフレームワークのデフォルト実装を呼び出す。 - if (!(data instanceof Map)) { - return super.get(context); - } - - // Mapをマスクした文字列を返す。 - Map editedMap = new TreeMap(); - for (Map.Entry entry : ((Map) data).entrySet()) { - String key = entry.getKey().toString(); - editedMap.put(key, mapValueEditor.edit(key, entry.getValue())); - } - return editedMap.toString(); - } -} -``` - -次にFailureLogFormatterのgetLogItemsメソッドをオーバライドし、 -プレースホルダ「$data$」に対して上記のCustomDataItemを設定する。 -FailureLogFormatterを拡張したクラスの実装例を下記に示す。 - -FailureLogFormatterを拡張したクラスの実装例 - -```java -public class CustomDataFailureLogFormatter extends FailureLogFormatter { - - @Override - protected Map> getLogItems(Map props) { - - Map> logItems = super.getLogItems(props); - - // CustomDataItemで$data$を上書き設定する。 - logItems.put("$data$", new CustomDataItem()); - - return logItems; - } - - private static final class CustomDataItem extends DataItem { - // 省略。 - } - } -``` - -障害ログのフォーマッタとしてCustomDataFailureLogFormatterを使用するようにapp-log.propertiesに設定を行う。 - -app-log.propertiesの設定例 - -```bash -# CustomDataFailureLogFormatterを指定する。 -failureLogFormatter.className=nablarch.core.log.app.CustomDataFailureLogFormatter -failureLogFormatter.defaultFailureCode=MSG99999 -failureLogFormatter.defaultMessage=an unexpected exception occurred. -failureLogFormatter.notificationFormat=fail_code = [$failureCode$] $message$ -failureLogFormatter.analysisFormat=fail_code = [$failureCode$] $message$\nInput Data :\n$data$ -``` - -障害解析ログの出力例を下記に示す。 -CustomDataItemクラスに定義したマスク対象のパターンにマッチするデータはマスクされて出力される。 - -```bash -# 障害解析ログ -2011-09-26 21:06:35.745 -FATAL- root [EXECUTION_ID_0000000123456789] boot_proc = [] proc_sys = [] req_id = [RB11AC0160] usr_id = [batchuser1] fail_code = [NB11AA0107] ユーザ情報の登録に失敗しました。 -Input Data : -{EXTENSION_NUMBER_BUILDING=13, EXTENSION_NUMBER_PERSONAL=1235, INSERT_EXECUTION_ID=EXECUTION_ID_2000000123456789, INSERT_REQUEST_ID=RB11AC0140, KANA_NAME=ヤマモトタロウ, KANJI_NAME=山本太郎, LOGIN_ID=12345678901234567890, MAIL_ADDRESS=********************, MOBILE_PHONE_NUMBER_AREA_CODE=***, MOBILE_PHONE_NUMBER_CITY_CODE=****, MOBILE_PHONE_NUMBER_SBSCR_CODE=****, UPDATED_USER_ID=batch_user, USER_INFO_ID=00000000000000000113} -Stack Trace Information : -[100 TransactionAbnormalEnd] ユーザ情報の登録に失敗しました。 - at nablarch.sample.ss11AC.B11AC016Action.handle(B11AC016Action.java:73) - at nablarch.sample.ss11AC.B11AC016Action.handle(B11AC016Action.java:1) - at nablarch.fw.action.BatchAction.handle(BatchAction.java:1) - # 以降のスタックトレースは省略。 -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-01-Log.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-01-Log.md deleted file mode 100644 index 2d7d35e74..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-01-Log.md +++ /dev/null @@ -1,1232 +0,0 @@ -# ログ出力 - -## 概要 - -フレームワーク、アプリケーションからログ出力を行う機能を提供する。 - -本機能を使用する際は、明示的な初期処理を必要としない。ただし、ログ出力に使用するリソースを解放するため、終了処理が必要となる。 -この終了処理は本フレームワークの他の機能で行う必要がある。 -例えば、Webアプリケーションでの終了処理は、 [Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md) の機能で行う。 - -アプリケーションプログラマは、個別アプリケーション毎のログ出力方針に基づいて、プログラム中でログ出力を行う。 -アプリケーションからログを出力する方法は、 [ログ出力](../../component/libraries/libraries-01-Log.md#ログ出力) に記述する。 - -## 特徴 - -### ログ出力機能の高い拡張性 - -本機能は、以下３つの処理から構成されており、それぞれの実装を差し替えることができる構造となっている。: - -``` -a) ログの書き込み処理 -b) ログのフォーマット処理 -c) アプリケーションからのログ出力要求受付処理 -``` - -個別アプリケーションのログ出力要件に応じて、aやbの単位で差し替えることもできるし、 -これらだけでは要件を満たせなければcを実装してほぼ全ての処理を差し替えることもできる。 -例えば、過去のプロジェクトで作成したログ出力ライブラリを使用したい場合などはcを差し替えればよい。 -尚、オープンソースで使用実績の多いLog4Jについては、専用のcを既に用意している。 -以降では、他のログ出力実装と区別するため、本フレームワークが提供する各実装を「フレームワーク実装」と呼ぶ。 - -### 各種ログの出力機能 - -本フレームワークでは、アプリケーションに共通で必要とされる各種ログの出力機能を予め提供している。 -本フレームワークが出力機能を提供す各種ログの一例を下記に示す。 - -* [障害通知ログ](../../component/libraries/libraries-01-FailureLog.md#障害ログの出力) -* [障害解析ログ](../../component/libraries/libraries-01-FailureLog.md#障害ログの出力) -* [SQLログ](../../component/libraries/libraries-02-SqlLog.md#sqlログの出力) -* [パフォーマンスログ](../../component/libraries/libraries-03-PerformanceLog.md#パフォーマンスログの出力) -* [HTTPアクセスログ](../../component/libraries/libraries-04-HttpAccessLog.md#httpアクセスログの出力) - -各種ログの出力機能では、ログのフォーマットを設定で変更できるので、個別アプリケーションのログ出力要件に応じてカスタマイズして使用できる。 - -## 要求 - -### 実装済み - -* ログ出力機能の実装を差し替えることができる。 -* ログ毎にログの出力有無を制御するログレベルと出力先を設定できる。 -* パッケージ単位やクラス単位で設定対象のログを絞り込める。 -* 1つのログを複数の出力先に出力できる。これにより、障害解析用と監視用など、1つのログを目的に応じて別々に収集できる。 -* ログの出力先を変更できる。 -* ログをファイルに出力できる。 -* ログファイルが指定サイズに達したら、出力ファイルを自動で切り替える（出力ファイルをバックアップした後、初期化する）ことができる。 -* ログのフォーマットを変更できる。 -* ログに出力するログレベルを表す文言を変更できる。 -* オブジェクト情報(クラス名とフィールドに保持している値)をログに出力できる。 -* エラー情報(例外クラスのエラーメッセージとスタックトレース)をログに出力できる。 -* ログのフォーマットを設定のみで変更できる。 -* 性能測定を目的としたログ集計ができる。 -* アクセスログを取得できる。 - - * アクセスログにリクエストパラメータを出力できる。 - * アクセスログに含まれるリクエストパラメータの特定項目をマスクできる。 - * アクションの処理結果(正常終了、業務精査エラー、システムエラー)をログに出力できる。 -* ログ監視ツールから監視可能なフォーマットでログを出力できる。 -* 複数プロセスから1つのログファイルに出力できる。 - -### 未実装 - -* データベースにログを出力できる。 -* 日付毎に出力ファイルを自動で切り替えることができる。 - -### 未検討 - -* リクエストID単位でログの出力有無を制御できる。（リクエストIDについては、 [リクエストの識別と業務処理の実行](../../about/about-nablarch/about-nablarch-architectural-pattern-concept.md#リクエストの識別と業務処理の実行) を参照） -* アプリケーションを停止することなく、設定の変更を反映できる。 -* ログファイルの改竄を防止できる。 -* ファイルへのログ出力で指定するファイルパスに置換文字を使用できる。 -* ログ出力用のスレッドを、業務処理を実行しているワーカスレッドから独立させることができる。 -* ログ出力機能の実装を部分的に差し替えることができる。（Log4Jのアペンダだけ使用したい場合など） -* 外部ツールからログの出力ファイルを切り替えることができる。 -* ログに出力するスタックトレース内のメッセージをマスクできる。 -* フレームワークが行う処理の実行時間を測定できる。 -* リクエスト処理の実行時間に対して上限値を指定し、上限値を超えた場合はアラートをログ出力できる。 -* 1トランザクションにおけるSQL文の発行回数の上限値を指定し、上限値を超えた場合はアラートをログ出力できる。 - -## ログ出力要求受付処理 - -はじめに、ログ出力要求受付処理について解説する。 - -### クラス図 - -![Log_ClassDiagram.jpg](../../../knowledge/assets/libraries-01-Log/Log_ClassDiagram.jpg) - -#### 各クラスの責務 - -##### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.log.Logger | ログを出力するインタフェース。 ログ出力機能の実装毎に本インタフェースの実装クラスを作成する。 Loggerインタフェースを実装したクラス及びインスタンスをロガーと呼ぶ。 | -| nablarch.core.log.LoggerFactory | ロガーを生成するインタフェース。 フレームワーク内部でログ出力機能の実装に対応するロガーを生成するために使用する。 ログ出力機能の実装毎に本インタフェースの実装クラスを作成する。 LoggerFactoryインタフェースを実装したクラス及びインスタンスをロガーファクトリと呼ぶ。 | - -##### クラス定義 - -a) ロガー - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.basic.BasicLogger | ロガーの基本実装クラス。 | -| nablarch.core.log.log4j.Log4JLogger | Log4Jを使用してログ出力を行うクラス。 | - -b) ロガーファクトリ - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.basic.BasicLoggerFactory | BasicLoggerを生成するロガーファクトリの基本実装クラス。 | -| nablarch.core.log.log4j.Log4JLoggerFactory | Log4JLoggerを生成するクラス。 | - -c) その他のクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.LoggerManager | ログ出力機能の全体を取りまとめるクラス。 設定で指定されたロガーファクトリを生成・保持する。 ログ出力機能の実装に依存する初期処理・終了処理・ロガーの生成はロガーファクトリに委譲する。 LoggerManagerクラスをロガーマネージャと呼ぶ。 | -| nablarch.core.log.LogSettings | ログ出力機能の設定をロードして保持するクラス。 | - -### ログレベルの定義 - -ログレベルは、Log4JやJava Logging APIといった実装毎に定義が異なるため、ここで本フレームワークにおけるログレベルを定義しておく。 - -本フレームワークにおけるログレベルは、FATAL>ERROR>WARN>INFO>DEBUG>TRACEの6段階とし、FATALからTRACEに向かって順にレベルが低くなる。 -レベルに応じた出力制御では、指定されたレベル以上のログを全て出力する。 -例えば、WARNレベルが指定された場合は、FATALレベル,ERRORレベル,WARNレベルで出力を指示しているログのみ出力する。 - -各ログレベルの意味を下記に示す。 - -| レベル | 意味 | -|---|---| -| FATAL | アプリケーションの継続が不可能になる深刻な問題が発生したことを示す。 監視が必須で即通報および即対応が必要となる。 | -| ERROR | アプリケーションの継続に支障をきたす問題が発生したことを示す。 監視が必須であるが、通報および対応にFATALレベルほどの緊急性がない。 | -| WARN | すぐには影響を与えないが、放置しておくとアプリケーションの継続に支障をきたす問題になる恐れがある事象が発生したことを示す。 できれば監視した方がよいが、ERRORレベルほどの緊急性がない。 | -| INFO | 本番運用時にアプリケーションの情報を出力するログレベル。 アクセスログや統計ログが該当する。 | -| DEBUG | 開発時にデバッグ情報を出力するログレベル。 SQLログや性能ログが該当する。 | -| TRACE | 開発時にデバッグ情報より、さらに細かい情報を出力したい場合に使用するログレベル。 | - -フレームワークが出力するログについては、 [フレームワークのログ出力方針](../../component/libraries/libraries-01-Log.md#フレームワークのログ出力方針) を参照すること。 - -> **Warning:** -> FATALレベル・ERRORレベル・WARNレベル・INFOレベル: - -> ``` -> 通常は、運用監視体制と密接に関わるため、個別アプリケーションではなくフレームワークで出力する。 -> 例外として、業務的には必要であるがフレームワークでは出力できないログ（バッチ処理における処理件数など）を出力したい場合などには、 -> プロジェクトの方針に従い、個別アプリケーションからもログ出力を行う。 -> ``` - -> DEBUGレベル・TRACEレベル: - -> ``` -> ログの出力量が増えることにより、性能劣化とログファイルのサイズが肥大化するため、通常の本番運用時には出力してはならない。 -> ``` - -> **Note:** -> 通常は、本番運用時にINFOレベルでログを出力する。ログファイルのサイズが肥大化しないよう各プロジェクトにて出力内容を規定すること。 - -### ログ出力 - -アプリケーションからログを出力するには、ロガーを使用する。このロガーはロガーマネージャから取得する。 -出力実装例を下記に示す。この例では、UserManagerクラスにおいて、DEBUGレベルのログを出力している。 - -```java -// ロガーの取得。クラス変数に保持する。 -private static final Logger LOGGER = LoggerManager.get(UserManager.class); -``` - -```java -// ログの出力有無を事前にチェックし、ログ出力を行う。 -if (LOGGER.isDebugEnabled()) { - String message = "userId[" + user.getId() + "],name[" + user.getName() + "]"; - LOGGER.logDebug(message); -} -``` - -ロガーの取得処理では、ロガー名を引数に指定する。ロガー名の指定方法は、ロガー名を直接指定する方法とクラスを指定する方法がある。 -クラスを指定した場合は、指定されたクラスのFQCNをロガー名として使用する。 - -このロガー名に、出力要求側（つまり出力要求を行うアプリケーション）のFQCNを指定しておくと、そのFQCN毎にログ出力設定を変更できる。 -例えば、出力要求を行うアプリケーションのクラス毎やパッケージ毎に設定を変更できる。 - -通常ロガー名には、SQLログや監視ログなど、特定の用途向けのログ出力を行う場合は、その用途を表す名前(SQLやMONITOR等）を指定し、 -それ以外はクラスのFQCNを指定する。アプリケーションプログラマは、個別アプリケーションのログ出力方針に基づき、ロガー名を指定すること。 - -メッセージの組み立て処理が必要な場合は、Logger#is<ログレベル>Enabledメソッドを使用して、事前に出力有無をチェックすること。 -ログの出力を行わない場合には、不必要なログ組み立て処理が実行されることによる性能劣化を防ぐためである。 - -> **Note:** -> 個別アプリケーションにおいて、常にログを出力することになっているレベルは、ソースコードの可読性が落ちるため、事前チェックをしなくてよい。 -> 例えば、本番運用時に出力するログレベルをINFOレベルにするのであれば、FATALレベルからINFOレベルまでは事前チェックしなくてよい。 - -### 初期処理と終了処理 - -ログの出力先によってはリソースの確保と解放が必要となるため、本機能ではロガーマネージャが初期処理と終了処理を行う。 - -初期処理は、始めてロガーの取得が行われるタイミングでロガーマネージャが内部的に実行するが、 -終了処理は、フレームワーク側で実行するタイミングを判断できない。 -そのため、個別アプリケーション毎にアプリケーションの終了時にLoggerManager#terminateメソッドを呼び出すこと。 - -> **Warning:** -> 本機能を使用する場合は、ロガーマネージャの終了処理の呼び出しをしないと、 -> アプリケーション終了後にメモリリークが発生する可能性があるため、必ず終了処理を呼び出すこと。 - -Webアプリケーションでの終了処理は、 [Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md) の機能で行う。 - -### ロガーファクトリの設定方法 - -個別アプリケーションにおいて使用する実装（フレームワーク実装やLog4Jなど）は、どのロガーファクトリを使用するかで決まる。 -使用するロガーファクトリは、プロパティファイルに「loggerFactory.className = LoggerFactoryインタフェースを実装したクラス」で設定する。 - -プロパティファイルの記述例を下記に示す。 - -```bash -# フレームワーク実装を使用する例 -loggerFactory.className=nablarch.core.log.basic.BasicLoggerFactory -``` - -```bash -# Log4Jを使用する例 -loggerFactory.className=nablarch.core.log.log4j.Log4JLoggerFactory -``` - -プロパティファイルのパスは、システムプロパティを使用して、"nablarch.log.filePath"をキーにファイルパスを指定する。 -このファイルパスは、クラスパスとファイルシステム上のパスのどちらを指定しても良い。 -ファイルパスの指定方法は、nablarch.core.util.FileUtil#getResource(String)のJavadocを参照すること。 -システムプロパティを指定しなかった場合は、クラスパス直下のlog.propertiesが使用される。 - -クラスパス上のパスを指定する例を下記に示す。 -javaコマンドのオプション-Dによる指定を用いて、下記のように実行時のオプションとしてシステムプロパティを設定する。 - -```bash ->java -Dnablarch.log.filePath=classpath:nablarch/core/log/log.properties ... -``` - -> **Note:** -> プロパティファイルが存在しない場合は、ロガーマネージャが例外を送出する。 - -## 書き込み処理とフォーマット処理 - -ここからは、ログの書き込み処理とフォーマット処理について解説する。 - -### クラス図 - -![Log_Basic_ClassDiagram.jpg](../../../knowledge/assets/libraries-01-Log/Log_Basic_ClassDiagram.jpg) - -#### 各クラスの責務 - -##### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.log.basic.LogWriter | ログを出力先に書き込むインタフェース。 出力先の媒体毎に本インタフェースの実装クラスを作成する。 LogWriterインタフェースを実装したクラス及びインスタンスをログライタと呼ぶ。 | -| nablarch.core.log.basic.LogFormatter | ログのフォーマットを行うインタフェース。 ログのフォーマットの種類毎に本インタフェースの実装クラスを作成する。 LogFormatterインタフェースを実装したクラス及びインスタンスをログフォーマッタと呼ぶ。 | - -##### クラス定義 - -a) ログライタ - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.basic.LogWriterSupport | ログライタの実装をサポートするクラス。 ログレベルに応じた出力制御とログフォーマッタを使用したログのフォーマットを行う。 サブクラスでは、フォーマット済みのログの書き込み処理を実装する。 | -| nablarch.core.log.basic.FileLogWriter | ファイルにログを書き込むクラス。 ファイルにログを出力するのであれば、基本的にはFileLogWriterを使用すれば良いが、 ファイルサイズや日付以外の条件でログファイルの自動切り替えを実現する必要がある場合には、 これを実装したクラスを作成して入れ替える。 > **Note:** > 本ログライタは、プロセス単位にログを出力する。 > 複数プロセスから単一のログファイルに出力したい場合には、後述の *SynchronousFileLogWriter* を使用すること。 | -| nablarch.core.log.basic.SynchronousFileLogWriter | 複数プロセスから単一のファイルにログを書き込むクラス。 本クラスを使用するとプロセスをまたがってログ出力処理を直列化できるので、 複数プロセスから単一のファイルにログ出力を行う場合でも確実にログを出力できる。 用途としては、障害通知ログのように出力頻度が低く、かつサーバ単位でログファイルを一元管理するほうが効率的なログの出力にのみ使用することを想定している。 頻繁にログの出力が行われる場面で本クラスを使用するとロック取得待ちによって性能が著しく劣化するので、 アプリケーションログやアクセスログのように出力頻度の高いログ出力での使用は推奨しない。 > **Note:** > 直列化の方法として、ロックファイルを使用してプロセス間の同期をとりログ出力を行う。 | -| nablarch.core.log.basic.StandardOutputLogWriter | 標準出力にログを書き込むクラス。 | - -b) ログフォーマッタ - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.basic.BasicLogFormatter | ログフォーマッタの基本実装クラス。 ログに最低限必要な情報（日時、ユーザID、リクエストIDなど）、 オブジェクトのフィールド情報、例外オブジェクトのスタックトレースなどをログ出力用にフォーマットする。 デバッグ情報やアクセスログ、障害解析用のログなど、多目的に使用できる。 | - -c) その他のクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.basic.LogContext | ログ出力に必要な情報を保持するクラス。 メッセージ、エラー情報、日時、ユーザID、リクエストIDなどを保持する。 ユーザID、リクエストIDは、ThreadContextから取得する。 | -| nablarch.core.log.basic.LogLevelLabelProvider | ログに出力するログレベルを表す文言を提供するクラス。 | - -##### 列挙型 - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.basic.LogLevel | ログレベルを表す列挙型。 | - -### フレームワーク実装の設定方法 - -フレームワーク実装の設定は、ロガーファクトリの設定と同じプロパティファイルに記述する。 -プロパティファイルのパスの指定方法については、 [ロガーファクトリの設定方法](../../component/libraries/libraries-01-Log.md#ロガーファクトリの設定方法) を参照すること。 - -プロパティファイルの記述例を下記に示す。 -記述ルールの詳細は、 [プロパティファイルの記述ルール](../../component/libraries/libraries-01-Log.md#プロパティファイルの記述ルール) に記述する。 - -```bash -# フレームワーク実装のロガーファクトリを指定する。 -loggerFactory.className=nablarch.core.log.basic.BasicLoggerFactory - -# 使用する全てのログライタの名称を指定する。 -# 「"writer." + <ここで指定した名称>」を使用してログライタ毎の設定を行う。 -writerNames=appFile,sqlFile,monitorFile,stdout - -# ログライタ毎の設定 -# <ログライタのプレフィックス>.classNameに使用するログライタのクラス名を指定する。 -# className以外のプロパティは、使用するログライタに応じて設定内容が変わるため、 -# ログライタのJavadocを参照すること。 - -# アプリケーション用のログファイルの設定例 -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=/var/log/app/app.log - -# SQL出力用のログファイルの設定例 -writer.sqlFile.className=nablarch.core.log.basic.FileLogWriter -writer.sqlFile.filePath=/var/log/app/sql.log - -# 監視用のログファイルの設定例 -writer.monitorFile.className=nablarch.core.log.basic.SynchronousFileLogWriter -writer.monitorFile.filePath=/var/log/app/monitoring.log -writer.monitorFile.lockFilePath=/var/log/lock/monitor.lock -writer.monitorFile.failureCodeCreateLockFile=MSG00101 -writer.monitorFile.failureCodeReleaseLockFile=MSG00102 -writer.monitorFile.failureCodeForceDeleteLockFile=MSG00103 -writer.monitorFile.failureCodeInterruptLockWait=MSG00104 - -# 標準出力の設定例 -writer.stdout.className=nablarch.core.log.basic.StandardOutputLogWriter - -# 全てのロガー設定の名称を指定する。 -# ロガー設定については、下記の「ロガー設定」にて解説する。 -# 「"loggers." + <ここで指定された名称>」を使用してロガー設定毎の設定を行う。 -# ここでの記述順は、意味があるので注意すること。下記の警告を参照。 -availableLoggersNamesOrder=sql,monitoring,access,validation,root - -# 全てのロガー名をログ出力の対象にする設定例 -# 全てのロガー取得を対象に、WARNレベル以上をappFileに出力する。 -loggers.root.nameRegex=.* -loggers.root.level=WARN -loggers.root.writerNames=appFile - -# 特定のロガー名をログ出力の対象にする設定例。 -# ロガー名に"MONITOR"を指定したロガー取得を対象に、 -# ERRORレベル以上をappFile,monitorFileに出力する。 -loggers.monitoring.nameRegex=MONITOR -loggers.monitoring.level=ERROR -loggers.monitoring.writerNames=appFile,monitorFile - -# 特定のロガー名をログ出力の対象にする設定例。 -# ロガー名に"SQL"を指定したロガー取得を対象に、 -# DEBUGレベル以上をsqlFileに出力する。 -loggers.sql.nameRegex=SQL -loggers.sql.level=DEBUG -loggers.sql.writerNames=sqlFile - -# 特定のクラスをログ出力の対象にする設定例。 -# ロガー名に"app.user.UserManager"を指定したロガー取得を対象に、 -# INFOレベル以上をappFileとstdoutに出力する。 -loggers.access.nameRegex=app\\.user\\.UserManager -loggers.access.level=INFO -loggers.access.writerNames=appFile,stdout - -# 特定のパッケージ以下をログ出力の対象にする設定例。 -# ロガー名に"nablarch.core.validation"から始まる名前を指定したロガー取得を対象に、 -# DEBUGレベル以上をstdoutに出力する。 -loggers.validation.nameRegex=nablarch\\.core\\.validation\\..* -loggers.validation.level=DEBUG -loggers.validation.writerNames=stdout -``` - -> **Warning:** -> availableLoggersNamesOrderプロパティは、記述順に意味があるので注意すること。 -> ロガーの取得では、ログ出力を行うクラスが指定したロガー名に対して、 -> ここに記述した順番でロガーのマッチングを行い、最初にマッチしたロガーを返す。 -> 例えば、上記の設定にあるavailableLoggersNamesOrderの記述順をavailableLoggersNamesOrder=root,sqlと記述した場合、 -> 全てのロガー取得がロガー設定「root」にマッチしてしまう。 -> その結果、ロガー名「SQL」でログ出力してもログライタ「sqlFile」に出力されず、 -> ロガー設定「root」に指定されたログライタ「appFile」に出力される。 -> したがって、availableLoggersNamesOrderプロパティは、より限定的な正規表現を指定したロガー設定から順に記述すること。 - -> **Warning:** -> availableLoggersNamesOrderとloggers.*で指定するロガー設定の名称は、必ず一致させる必要がある。 -> BasicLoggerFactoryの初期処理で一致しているかチェックを行い、一致しない場合は例外をスローする。 -> 例えば、上記の設定にあるavailableLoggersNamesOrderからaccessを取り除くと、例外がスローされる。 -> このチェックは、設定漏れの発生を防ぐために行っている。 -> 上記の設定にあるavailableLoggersNamesOrderからaccessを取り除いた場合は、明示的にloggers.access.*の設定も取り除く必要がある。 - -> **Note:** -> ロガー設定では、全てのログ出力にマッチするロガー設定を1つ用意し、availableLoggersNamesOrderの最後に指定することを推奨する。 -> 万が一設定が漏れた場合でも、重要なログの出力を逃してしまう事態を防ぐことができる。 - -> 設定例を以下に示す。 - -> ```bash -> availableLoggersNamesOrder=sql,app,root -> -> loggers.root.nameRegex=.* -> loggers.root.level=WARN -> loggers.root.writerNames=appFile -> ``` - -プロパティファイルの設定は、システムプロパティを使用して、プロパティファイルと同じキー名で値を指定することにより上書きすることができる。 -この機能を使用して、共通のプロパティファイルに記述し、プロセス毎にログ出力設定を変更したい場合には **-D** オプションで上書きを行うことが出来るようになる。 -例えば、上記の設定にあるロガー「root」のログレベルをWARNからINFOに変更したい場合は、javaコマンドのオプション **-D** による指定を用いて、 -下記のように実行時のオプションとしてシステムプロパティを設定する。 - -```bash ->java -Dloggers.root.level=INFO ... -``` - -BasicLoggerFactoryクラスは、初期処理完了後に、各ログライタに対してロガー設定の情報をINFOレベルで出力する。 -上記設定例のログライタ「appFile」に対する出力例を下記に示す。 - -```java -2012-04-18 11:11:04.525 -INFO- nablarch.core.log.basic.BasicLoggerFactory [null] boot_proc = [] proc_sys = [] req_id = [null] usr_id = [null] initialized. - LOGGER = [monitoring] NAME REGEX = [MONITOR] LEVEL = [ERROR] - LOGGER = [access] NAME REGEX = [app\.user\.UserManager] LEVEL = [INFO] - LOGGER = [root] NAME REGEX = [.*] LEVEL = [WARN] -``` - -#### ロガー設定 - -ロガー設定では、3つのプロパティを指定する。: - -``` -a) <ロガー設定のプレフィックス>.nameRegex : このロガー設定の対象となるロガーを絞り込むための正規表現 -b) <ロガー設定のプレフィックス>.level : ログの出力有無の基準とするログレベル -c) <ロガー設定のプレフィックス>.writerNames : 出力先とするログライタの名称（複数可） -``` - -aは、bとcと設定値の意味が異なる。 -aの正規表現は、ロガー設定(bとc)の対象となるロガーを絞り込むために使用する。 -ロガーの取得時に指定されたロガー名（つまりLoggerManager#getメソッドの引数に指定されたロガー名）に対してマッチングを行う。 -一方、bとcは、aで絞り込まれたロガーに対して設定される。 - -ロガー設定のイメージをつかむために例を示す。 - -例えば、下記3つのクラスのロガー取得に対する設定例を示す。 -LoggerManager#getメソッドでクラスを指定した場合は、FQCNがロガー名となる。 - -```java -// 説明のために変数名に番号を振っているが、実際の開発ではこのような実装を行わない。 - -// nablarch.core.validation.validator.NumberRangeValidator -private static final Logger LOGGER1 = LoggerManager.get(NumberRangeValidator.class); - -// nablarch.core.validation.validator.RequiredValidator -private static final Logger LOGGER2 = LoggerManager.get(RequiredValidator.class); - -// nablarch.core.validation.convertor.LongConvertor -private static final Logger LOGGER3 = LoggerManager.get(LongConvertor.class); -``` - -3つのロガーを対象とする設定例を示す。 -以降、ロガー設定の名称はsampleとする。 - -```bash -loggers.sample.nameRegex=nablarch\\.core\\.validation\\..* -loggers.sample.level=INFO -loggers.sample.writerNames=xxx,yyy,zzz -``` - -上記の設定により、LOGGER1,LOGGER2,LOGGER3のINFOレベル以上のログ出力がxxx,yyy,zzzのログライタに対して出力される。 - -RequiredValidatorのロガーのみを対象とする設定例を示す。 - -```bash -loggers.sample.nameRegex=nablarch\\.core\\.validation\\.validator\\.RequiredValidator -loggers.sample.level=DEBUG -loggers.sample.writerNames=aaa,bbb,ccc -``` - -上記の設定により、LOGGER2のDEBUGレベル以上のログ出力がaaa,bbb,cccのログライタに対して出力される。 - -#### ロガーのインスタンス構造 - -上記プロパティファイルの記述例を基に、ロガーのインスタンス構造を示す。 -一番左の列は、ログ出力を要求するクラスのインスタンスを示しており、ノートにロガー取得時のコードを示している。 - -* ロガーのインスタンスはロガー設定毎に生成され、複数のログ出力を要求するインスタンスから使用される。 -* ログライタのインスタンスはログライタの設定毎に生成され、複数のロガーから使用される。 - -![Log_Basic_InstanceImage.jpg](../../../knowledge/assets/libraries-01-Log/Log_Basic_InstanceImage.jpg) - -### ログライタの使用方法 - -フレームワーク実装が提供するログライタの使用方法を解説する。 - -#### FileLogWriter - -FileLogWriterクラスは、ファイルにログを書き込むログライタである。 - -FileLogWriterクラスの特徴を下記に示す。 - -* ログフォーマッタを設定で指定できる。 -* ログファイルが指定サイズに達したら、出力ファイルを自動で切り替える。 -* 初期処理と終了処理、ログファイルの切り替え時に、書き込み先のログファイルにINFOレベルでメッセージを出力する。 - -FileLogWriterクラスを使用する場合の設定例を下記に示す。 -記述ルールの詳細は、 [プロパティファイルの記述ルール](../../component/libraries/libraries-01-Log.md#プロパティファイルの記述ルール) を参照すること。 - -```bash -writerNames=appFile - -# FileLogWriterクラスを指定する。 -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -# 書き込み先のファイルパスを指定する。 -writer.appFile.filePath=/var/log/app/app.log -# 書き込み時に使用する文字エンコーディングを指定する。 -writer.appFile.encoding=UTF-8 -# 出力バッファのサイズを指定する。（単位はキロバイト。1000バイトを1キロバイトと換算する。指定しなければ8KB） -writer.appFile.outputBufferSize=8 -# 書き込み先ファイルの最大サイズを指定する。（単位はキロバイト。1000バイトを1キロバイトと換算する） -writer.appFile.maxFileSize=50000 -# ログフォーマッタのクラス名を指定する。 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -# LogLevel列挙型の名称を指定する。ここで指定したレベル以上のログを全て出力する。 -# この設定項目については、下記の「ログライタにおけるレベルに応じた出力制御」にて解説する。 -writer.appFile.level=INFO -``` - -上記設定例に対する初期処理後のログ出力例を下記に示す。 -初期処理の後は、ログライタの設定情報が出力される。 - -```java -2012-04-18 11:24:02.959 -INFO- nablarch.core.log.basic.FileLogWriter [null] boot_proc = [] proc_sys = [] req_id = [null] usr_id = [null] initialized. - WRITER NAME = [appFile] - WRITER CLASS = [nablarch.core.log.basic.FileLogWriter] - FORMATTER CLASS = [nablarch.core.log.basic.BasicLogFormatter] - LEVEL = [INFO] - FILE PATH = [/var/log/app/app.log] - ENCODING = [UTF-8] - OUTPUT BUFFER SIZE = [8000] - FILE AUTO CHANGE = [true] - MAX FILE SIZE = [50000000] - CURRENT FILE SIZE = [0] -``` - -上記の設定例では、ファイルの最大サイズを指定しているので、出力ファイルが自動で切り替わる。 -出力ファイルが自動で切り替わった後のファイル一覧の例を下記に示す。 -app.logファイルが現在の出力ファイルである。 -古いログファイルは、<通常のファイル名>.yyyyMMddHHmmssSSS.oldという命名ルールで同じディレクトリにバックアップされる。 - -```java -app.log -app.log.20120418112403395.old -app.log.20120418112403411.old -app.log.20120418112403489.old -``` - -ファイルの切り替え時に、切り替え元と切り替え先それぞれで出力されるログの例を下記に示す。 -切り替え元のファイルには、ファイル名を変更したメッセージが出力される。 -切り替え先のファイルには、ファイル名の変更に加えて、ログライタの設定情報が出力される。 - -```java -// 切り替え元 -2012-04-18 11:24:03.411 -INFO- nablarch.core.log.basic.FileLogWriter [null] boot_proc = [] proc_sys = [] req_id = [null] usr_id = [null] change [/var/log/app/app.log] -> [/var/log/app/app.log.20120418112403411.old] -``` - -```java -// 切り替え先 -2012-04-18 11:24:02.959 -INFO- nablarch.core.log.basic.FileLogWriter [null] boot_proc = [] proc_sys = [] req_id = [null] usr_id = [null] initialized. - WRITER NAME = [appFile] - WRITER CLASS = [nablarch.core.log.basic.FileLogWriter] - FORMATTER CLASS = [nablarch.core.log.basic.BasicLogFormatter] - LEVEL = [INFO] - FILE PATH = [./log/app.log] - ENCODING = [UTF-8] - OUTPUT BUFFER SIZE = [8000] - FILE AUTO CHANGE = [true] - MAX FILE SIZE = [50000000] - CURRENT FILE SIZE = [0] -``` - -終了処理後のログ出力例を下記に示す。 - -```java -2012-04-18 11:32:58.939 -INFO- nablarch.core.log.basic.FileLogWriter [null] boot_proc = [] proc_sys = [] req_id = [null] usr_id = [null] terminated. -``` - -#### SynchronousFileLogWriter - -SynchronousFileLogWriterクラスは、ロックファイルを用いて排他制御を行いながらファイルにログを書き込むログライタである。 -本クラスはFileLogWriterクラスを継承しており、FileLogWriterクラスの特徴に加え、以下の特徴を持つ。 - -* プロセスをまたがってログ出力処理を直列化できるので、複数プロセスから同一のファイルにログ出力を行う場合でも確実にログを出力できる。 - -ログ出力時の動作は、 [障害が発生した場合のログ出力](../../component/libraries/libraries-01-Log.md#synchronousfilelogwriter) を参照すること。 - -SynchronousFileLogWriterクラスを使用する場合の設定例を下記に示す。 -記述ルールの詳細は、 [プロパティファイルの記述ルール](../../component/libraries/libraries-01-Log.md#プロパティファイルの記述ルール) を参照すること。 - -```bash -writerNames=monitorFile - -# SynchronousFileLogWriterクラスを指定する。 -writer.monitorFile.className=nablarch.core.log.basic.SynchronousFileLogWriter -# 書き込み先のファイルパスを指定する。 -writer.monitorFile.filePath=/var/log/app/monitor.log -# 書き込み時に使用する文字エンコーディングを指定する。 -writer.monitorFile.encoding=UTF-8 -# 出力バッファのサイズを指定する。（単位はキロバイト。1000バイトを1キロバイトと換算する。指定しなければ8KB） -writer.monitorFile.outputBufferSize=8 -# 書き込み先ファイルの最大サイズを指定する。（単位はキロバイト。1000バイトを1キロバイトと換算する） -writer.monitorFile.maxFileSize=50000 -# ログフォーマッタのクラス名を指定する。 -writer.monitorFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -# LogLevel列挙型の名称を指定する。ここで指定したレベル以上のログを全て出力する。 -# この設定項目については、下記の「ログライタにおけるレベルに応じた出力制御」にて解説する。 -writer.monitorFile.level=ERROR -# ロックファイルのファイル名を指定する。 -writer.monitorFile.lockFilePath=/var/log/lock/monitor.lock -# ロック取得の再試行間隔（ミリ秒）を指定する。 -writer.monitorFile.lockRetryInterval=10 -# ロック取得の待機時間（ミリ秒）を指定する。 -writer.monitorFile.lockWaitTime=3000 -# ロックファイルが生成できない場合の障害通知コードを指定する。 -writer.monitorFile.failureCodeCreateLockFile=MSG00101 -# 生成したロックファイルを解放（削除）できない場合の障害通知コードを指定する。 -writer.monitorFile.failureCodeReleaseLockFile=MSG00102 -# 解放されないロックファイルを強制削除できない場合の障害通知コードを指定する。 -writer.monitorFile.failureCodeForceDeleteLockFile=MSG00103 -# ロック待ちでスレッドをスリープしている際に、割り込みが発生した場合の障害通知コードを指定する。 -writer.monitorFile.failureCodeInterruptLockWait=MSG00104 -``` - -上記設定例の場合。出力対象のログレベルが **ERROR** 以上なので初期処理後のログは出力されない。 -出力対象のログレベルに **INFO** レベルが含まれている場合は、以下のログが初期処理後に出力される。 - -```java -2012-04-18 11:56:27.137 -INFO- nablarch.core.log.basic.FileLogWriter [null] boot_proc = [] proc_sys = [] req_id = [null] usr_id = [null] initialized. - WRITER NAME = [monitorFile] - WRITER CLASS = [nablarch.core.log.basic.SynchronousFileLogWriter] - FORMATTER CLASS = [nablarch.core.log.basic.BasicLogFormatter] - LEVEL = [ERROR] - FILE PATH = [/var/log/app/monitor.log] - ENCODING = [UTF-8] - OUTPUT BUFFER SIZE = [8000] - FILE AUTO CHANGE = [true] - MAX FILE SIZE = [50000000] - CURRENT FILE SIZE = [0] - LOCK FILE PATH = [/var/log/lock/monitor.lock] - LOCK RETRY INTERVAL = [1] - LOCK WAIT TIME = [1800] - FAILURE CODE CREATE LOCK FILE = [MSG00101] - FAILURE CODE RELEASE LOCK FILE = [MSG00102] - FAILURE CODE FORCE DELETE LOCK FILE = [MSG00103] - FAILURE CODE INTERRUPT LOCK WAIT = [MSG00104] -``` - -**障害が発生した場合のログ出力** - -本ログライタは、ロック取得の待機時間を超えてもロックを取得できない場合、強制的にロックファイルを削除し、自身のスレッド用のロックファイルを生成してからログの出力を行う。 -もし強制的にロックファイルを削除できない場合は、ロックを取得していない状態で強制的にログの出力を行い、ログ出力処理を終了 [1] する。 -また、ロックファイルの生成に失敗した場合および、ロック取得待ちの際に割り込みが発生した場合も、ロックを取得していない状態で強制的にログの出力を行い、処理を終了 [1] する。 - -ロックを取得しない状態で強制的にログを出力する場合に、複数プロセスからのログ出力が競合するとログが正常に出力されない場合がある点に注意すること。 - -このような障害が発生した場合には、強制出力したログに加えて、同一のログファイルに障害のログを出力する。 -デフォルトでは本フレームワークが用意したログが出力されるが、本ログライタのプロパティに障害コードを設定することで、障害通知ログのフォーマット（障害コードを含む）でログを出力することができる。 -障害通知ログのフォーマットで出力することで通常の障害通知ログと同様の方法でログの監視が可能となるので、障害コードの設定を行うことを推奨する。 - -下表に障害ログの詳細を示す。障害時には、これら障害ログの内容に従って対応を行うこと。 - -| 障害の種類 | ログレベル | 障害コードを設定するプロパティの名前 | 障害コードに対応するメッセージの設定例（{0}にはロックファイルのパスが設定される） | 本フレームワークがデフォルトで出力するログ（障害コードなどは出力されない） | -|---|---|---|---|---| -| ロックファイルが生成できない | FATAL | failureCodeCreateLockFile | ロックファイルの生成に失敗しました。おそらくロックファイルのパスが間違っています。ロックファイルパス=[{0}]。 | failed to create lock file. perhaps lock file path was invalid. lock file path=[{0}]. | -| 生成したロックファイルを解放（削除）できない | FATAL | failureCodeReleaseLockFile | ロックファイルの削除に失敗しました。ロックファイルパス=[{0}]。 | failed to delete lock file. lock file path=[{0}]. | -| 解放されないロックファイルを強制削除できない | FATAL | failureCodeForceDeleteLockFile | ロックファイルの強制削除に失敗しました。ロックファイルが不正に開かれています。ロックファイルパス=[{0}]。 | failed to delete lock file forcedly. lock file was opened illegally. lock file path=[{0}]. | -| ロック取得待ちでスレッドをスリープしている際に、割り込みが発生 | FATAL | failureCodeInterruptLockWait | ロック取得中に割り込みが発生しました。 | interrupted while waiting for lock retry. | - -処理を終了とは、ログ出力処理を終了し呼び出し元に処理を正常に処理を戻すことを意味する。 - -> **Warning:** -> 障害コードを設定した場合、障害通知ログのフォーマットで同一のログファイルにログが出力されるが、障害解析ログは出力されない点に注意すること。 - -#### ログライタにおけるレベルに応じた出力制御 - -LogWriterSupportクラスを継承しているクラスでは、ログライタにおいてレベルに応じた出力制御を行うことができる。 - -レベルに応じた出力制御は、通常ロガー設定を指定することで行う。 -しかし、ロガー設定では、ロガー名毎の設定となるため、同じロガー名で異なるレベルで別々のファイルに出力することができない。 -例えば、本番運用時のログレベルがINFOレベルの場合、アプリケーションログは障害時の解析に使用するのでINFOレベルまで出力したいが、 -通知に使用するログはERRORレベル以上だけでよいといった場合がある。このような場合は、ロガー設定ではINFOレベルを指定しておき、 -通知に使用するログを書き込むログライタの設定でERRORレベルを指定することで対応できる。 - -設定例を下記に示す。説明に必要ない部分は省略している。 - -```bash -writerNames=appFile,monitorFile - -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=/var/log/app/app.log - -writer.monitorFile.className=nablarch.core.log.basic.SynchronousFileLogWriter -writer.monitorFile.filePath=/var/log/app/monitor.log -writer.monitorFile.level=ERROR -writer.monitorFile.lockFilePath=/var/log/lock/monitor.lock -writer.monitorFile.failureCodeCreateLockFile=MSG00101 -writer.monitorFile.failureCodeReleaseLockFile=MSG00102 -writer.monitorFile.failureCodeForceDeleteLockFile=MSG00103 -writer.monitorFile.failureCodeInterruptLockWait=MSG00104 - -availableLoggersNamesOrder=root - -loggers.root.nameRegex=.* -loggers.root.level=INFO -loggers.root.writerNames=appFile,monitorFile -``` - -ログライタ「appFile」は、ログレベルを指定していないので、ロガー設定で指定しているINFOレベル以上のログが出力される。 -一方、ログライタ「monitorFile」は、ログレベルを指定しているので、ログライタで指定しているERRORレベル以上のログのみ出力される。 - -#### StandardOutputLogWriter - -StandardOutputLogWriterクラスは、標準出力にログを書き込むログライタである。 - -開発時にコンソール上で出力されたログを確認する場合などに使用できる。 - -設定例を下記に示す。 - -```bash -writerNames=stdout - -# StandardOutputLogWriterクラスを指定する。 -writer.stdout.className=nablarch.core.log.basic.StandardOutputLogWriter -# ログフォーマッタのクラス名を指定する。 -writer.stdout.formatter.className=nablarch.core.log.basic.BasicLogFormatter -``` - -> **Warning:** -> 誤って開発時に使用したデバッグ設定のまま、本番運用時に使用しないこと。 - -### ログフォーマッタの使用方法 - -フレームワーク実装が提供するログフォーマッタの使用方法を解説する。 - -#### BasicLogFormatter - -BasicLogFormatterクラスは、汎用的に使用できるログフォーマッタである。 - -BasicLogFormatterクラスの特徴を下記に示す。 - -* ログに最低限必要な情報（日時、リクエストID、ユーザIDなど）を出力できる。 -* アプリケーションを起動しているプロセスを識別するために、システムプロパティで指定されたプロセス名をログに出力できる。 -* オブジェクトを指定してフィールド情報を出力できる。 -* 例外オブジェクトを指定してスタックトレースを出力できる。 -* フォーマットを設定のみで変更することができる。 - -BasicLogFormatterでは、出力されたログの状況を特定するために、リクエストIDの他に下記項目を出力できる。 -これらの出力項目について先に説明する。 - -* 起動プロセス -* 処理方式 -* 実行時ID - -##### 起動プロセス - -起動プロセスとは、アプリケーションを起動した実行環境を特定するために使用する名前である。 -起動プロセスにサーバ名とJOBIDなどの識別文字列を組み合わせた名前を使用することで、 -同一サーバの複数プロセスから出力されたログの実行環境を特定することができる。 -起動プロセスは、プロジェクト毎にID体系などで体系を規定することを想定している。 - -起動プロセスは、システムプロパティに"nablarch.bootProcess"というキーで指定する。 -システムプロパティの指定がない場合、起動プロセスはブランクとなる。 - -システムプロパティの設定例を下記に示す。 -javaコマンドのオプション-Dによる指定を用いて、下記のように実行時のオプションとしてシステムプロパティを設定する。 - -```bash ->java -Dnablarch.bootProcess=APP0001 ... -``` - -##### 処理方式 - -処理方式とは、画面オンライン処理、バッチ処理、ディレード処理などを意味する。 -アプリケーションの処理方式を識別したい場合に、プロジェクト毎に規定して使用する。 - -処理方式は、プロパティファイルに"nablarch.processingSystem"というキーで指定する。 -プロパティファイルのパスの指定方法については、 [ロガーファクトリの設定方法](../../component/libraries/libraries-01-Log.md#ロガーファクトリの設定方法) を参照。 -処理方式の設定例を下記に示す。 - -```bash -# 処理方式に"1"を指定している。 -nablarch.processingSystem=1 -``` - -プロパティの指定がない場合はブランクとなる。 - -##### 実行時ID - -実行時IDとは、リクエストIDに対するアプリケーションの個々の実行を識別するためにつけるIDである。 -1つのリクエストIDに対して実行された数だけ実行時IDが発行されるため、リクエストIDと実行時IDの関係は1対多となる。 -実行時IDは、複数のログを出力している場合に、出力された複数のログを紐付けるために使用する。 - -実行時IDは、各処理方式のThreadContextを初期化するタイミングで発行し、ThreadContextに設定される。 -実行時IDのID体系を下記に示す。 - -```bash -# 起動プロセスは指定された場合のみ付加する。 -起動プロセス＋システム日時(yyyyMMddHHmmssSSS)＋連番(4桁) -``` - -##### BasicLogFormatterのフォーマット指定 - -BasicLogFormatterは、プレースホルダを使用してフォーマットを指定する。 -フォーマットに指定可能なプレースホルダの一覧を下記に示す。 - -| プレースホルダ | 説明 | -|---|---| -| $date$ | このログ出力を要求した時点の日時。 | -| $logLevel$ | このログ出力のログレベル。 デフォルトはLogLevel列挙型の名称を文言に使用する。 文言はプロパティファイルの設定で変更することができる。 文言変更の詳細は、 [ログに出力するログレベルを表す文言の変更方法](../../component/libraries/libraries-01-Log.md#ログに出力するログレベルを表す文言の変更方法) を参照。 | -| $loggerName$ | このログ出力が対応するロガー設定の名称。 プロパティファイルでロガー設定を行う際に指定した名称となる。 | -| $bootProcess$ | [起動プロセス](../../component/libraries/libraries-01-Log.md#起動プロセス) を識別する名前。 | -| $processingSystem$ | [処理方式](../../component/libraries/libraries-01-Log.md#処理方式) を識別する名前。 | -| $requestId$ | このログ出力を要求した時点のリクエストID 。 | -| $executionId$ | このログ出力を要求した時点の [実行時ID](../../component/libraries/libraries-01-Log.md#実行時id) 。 | -| $userId$ | このログ出力を要求した時点のログインユーザのユーザID。 | -| $message$ | このログ出力のメッセージ。 指定がない場合はブランク。 | -| $information$ | オプション情報に指定されたオブジェクトのフィールド情報。 オブジェクトのフィールドに対して、Object#toString()メソッドを実行した結果を表示する。 オプション情報に指定されたオブジェクトが基本データ型のラッパクラス、CharSequenceインタフェース、 Dateクラスの場合は、オブジェクトに対してObject#toString()メソッドを実行した結果のみを表示する。 オブジェクト情報の指定がない場合は表示しない。 | -| $stackTrace$ | エラー情報に指定された例外オブジェクトのスタックトレース。 エラー情報の指定がない場合は表示しない。 | - -$information$と$stackTrace$は、出力内容が複数行になるため、先頭に改行コードを付加して出力する。 - -フォーマットに改行コードとタブ文字を含めたい場合は、下記に示すように、Javaと同様の記述を使用する。 -改行コードは、Java標準のシステムプロパティに含まれる"line.separator"から取得する。 -このため、システムプロパティの"line.separator"を変更しなければOSの改行コードが使用される。 -尚、BasicLogFormatterは"\n"と"\t"という文字列を出力することはできない。 - -| 含めたい文字 | 記述する文字列 | -|---|---| -| 改行コード | \\n | -| タブ文字 | \\t | - -フォーマットの指定がない場合に使用するデフォルトのフォーマットを下記に示す。 - -```bash -$date$ -$logLevel$- $loggerName$ [$executionId$] boot_proc = [$bootProcess$] proc_sys = [$processingSystem$] req_id = [$requestId$] usr_id = [$userId$] $message$$information$$stackTrace$ -``` - -##### BasicLogFormatterの出力例 - -デフォルトのフォーマットによるログの出力例を下記に示す。 - -システムプロパティの設定例 - -```bash -# システムプロパティで起動パラメータと処理方式を指定する。 ->java -Dnablarch.bootProcess=APP0001 -``` - -log.propertiesの設定例 - -```bash -# 処理方式に"1"を指定している。 -nablarch.processingSystem=1 -``` - -ログの出力を依頼するコードの実装例 - -```java -// ThreadContextは下記の値が設定されているものとする。 -// ユーザID=0000000001 -// リクエストID=USERS00302 -// 実行時ID=APP001201102041542175080001 - -User user = new User(null, "山田太郎", 28); -String userId = null; -String name = "山田花子"; -long price = 2000000; - -try { - doSomething(); // new IllegalArgumentException("error test.")が送出される。 -} catch (IllegalArgumentException e) { - // メッセージ、エラー情報、オプション情報(userからpriceまで)を指定している。 - LOGGER.logInfo("テストメッセージ", e, user, userId, name, price); - throw e; -} -``` - -ログの出力例 - -```bash -2011-02-14 16:01:37.578 -INFO- root [APP001201102041542175080001] boot_proc = [APP001] proc_sys = [1] req_id = [USERS00302] usr_id = [0000000001] テストメッセージ -Object Information[0]: Class Name = [nablarch.core.log.basic.User] - id = [null] - name = [山田太郎] - age = [28] - toString() = [nablarch.core.log.basic.User@10b4199] -Object Information[1]: null -Object Information[2]: Class Name = [java.lang.String] - toString() = [山田花子] -Object Information[3]: Class Name = [java.lang.Long] - toString() = [2000000] -Stack Trace Information : -java.lang.IllegalArgumentException: error test. - at my.log.BasicLogFormatterSample.doSomething(BasicLogFormatterSample.java:50) - # 以降のスタックトレースは省略。 -``` - -次に、フォーマットを指定した場合のログの出力例を下記に示す。 -BasicLogFormatterのdatePatternプロパティを指定することで日時のフォーマットに使用するパターンを変更することもできる。 -ログの出力を指示するソースコードは、デフォルトのフォーマットによるログの出力例と同じとする。 - -```bash -# フォーマットの指定 - -# フォーマットを指定する場合はBasicLogFormatterクラスを明示的に指定する必要がある。 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter - -# 日時のフォーマットに使用するパターンを指定している。 -writer.appFile.formatter.datePattern=yyyy/MM/dd HH:mm:ss[SSS] - -# 実行時ID以降を改行して表示するようにフォーマットを指定している。 -writer.appFile.formatter.format=$date$ -$logLevel$- $loggerName$ [$executionId$]\n\tboot_proc = [$bootProcess$]\n\tproc_sys = [$processingSystem$]\n\treq_id = [$requestId$]\n\tusr_id = [$userId$]\n\t$message$$information$$stackTrace$ -``` - -```bash -# ログの出力例 - -2011/02/14 16:08:55[107] -INFO- root [APP001201102041542175080001] - boot_proc = [APP001] - proc_sys = [1] - req_id = [USERS00302] - usr_id = [0000000001] - テストメッセージ -# 以降のオプション情報とスタックトレースは、デフォルトのフォーマットによるログの出力例と同じため省略。 -``` - -#### ログに出力するログレベルを表す文言の変更方法 - -LogLevelLabelProviderクラスを使用することで、ログレベルを表す文言をプロパティファイルに設定できる。 -ログレベルを表す文言のデフォルトは、LogLevel列挙型の名称となる。 -BasicLogFormatterクラスは、LogLevelLabelProviderクラスを使用して、ログレベルを表す文言の変更をサポートしている。 - -まず、文言を変更する前の設定例と出力例を下記に示す。 -ロガー設定の名称（root）の後にデフォルトの文言（FATAL, ERRORなど）が表示されている。 - -```bash -writerNames=appFile - -writer.appFile.filePath=/var/log/app/app.log -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=$date$ -$logLevel$- $loggerName$ [$executionId$] boot_proc = [$bootProcess$] req_id = [$requestId$] usr_id = [$userId$] $message$ -``` - -```java -2011-02-28 12:32:26.366 -FATAL- root [null] boot_proc = [] req_id = [null] usr_id = [null] FATALメッセージ -2011-02-28 12:32:26.366 -ERROR- root [null] boot_proc = [] req_id = [null] usr_id = [null] ERRORメッセージ -2011-02-28 12:32:26.366 -WARN- root [null] boot_proc = [] req_id = [null] usr_id = [null] WARNメッセージ -2011-02-28 12:32:26.366 -INFO- root [null] boot_proc = [] req_id = [null] usr_id = [null] INFOメッセージ -2011-02-28 12:32:26.366 -DEBUG- root [null] boot_proc = [] req_id = [null] usr_id = [null] DEBUGメッセージ -2011-02-28 12:32:26.366 -TRACE- root [null] boot_proc = [] req_id = [null] usr_id = [null] TRACEメッセージ -``` - -次に、文言を変更した後の設定例と出力例を下記に示す。 -ロガー設定の名称（root）の後に指定した文言（F, Eなど）が表示される。 - -```bash -writerNames=appFile - -writer.appFile.filePath=/var/log/app/app.log -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=$date$ -$logLevel$- $loggerName$ [$executionId$] boot_proc = [$bootProcess$] req_id = [$requestId$] usr_id = [$userId$] $message$ -# <ログライタのプレフィックス>.formatter.label.に文言を指定する。 -writer.appFile.formatter.label.fatal=F -writer.appFile.formatter.label.error=E -writer.appFile.formatter.label.warn=W -writer.appFile.formatter.label.info=I -writer.appFile.formatter.label.debug=D -writer.appFile.formatter.label.trace=T -``` - -```java -2011-02-28 12:33:39.569 -F- root [null] boot_proc = [] req_id = [null] usr_id = [null] FATALメッセージ -2011-02-28 12:33:39.569 -E- root [null] boot_proc = [] req_id = [null] usr_id = [null] ERRORメッセージ -2011-02-28 12:33:39.569 -W- root [null] boot_proc = [] req_id = [null] usr_id = [null] WARNメッセージ -2011-02-28 12:33:39.569 -I- root [null] boot_proc = [] req_id = [null] usr_id = [null] INFOメッセージ -2011-02-28 12:33:39.569 -D- root [null] boot_proc = [] req_id = [null] usr_id = [null] DEBUGメッセージ -2011-02-28 12:33:39.569 -T- root [null] boot_proc = [] req_id = [null] usr_id = [null] TRACEメッセージ -``` - -### カスタマイズ方法 - -ログライタとログフォーマッタのカスタマイズ方法について説明する。 - -#### ログライタのカスタマイズ方法 - -新しいログライタを追加する場合は、LogWriterインタフェースを実装したクラスを作成する。 -ログフォーマッタを使用するログライタを作成する場合は、共通処理を提供するLogWriterSupportクラスを継承して作成できる。 - -#### ログフォーマッタのカスタマイズ方法 - -新しいログフォーマッタを追加する場合は、LogFormatterインタフェースを実装したクラスを作成する。 -ログレベルを表す文言を設定で変更可能にしたい場合は、LogLevelLabelProviderクラスを使用する。 - -新しいログフォーマッタの追加に伴い、ログ出力時に指定するパラメータを増やし、ログフォーマッタで増やしたパラメータを受け取りたいことがある。 -本機能では、ログ出力時に指定するパラメータを増やす目的で、Loggerインタフェースのログ出力メソッドにObject型の可変長引数optionsを設けている。 -シグネチャの例としてLogger#logInfoメソッドを下記に示す。 - -```java -// Logger#logInfoメソッドのシグネチャ -public void logInfo(String message, Object... options) -public void logInfo(String message, Throwable cause, Object... options) -``` - -ログ出力時のパラメータを増やしたい場合は、options引数を規定して使用すること。 - -##### ログ出力項目の変更方法 - -BasicLogFormatterは、LogItemインタフェースを使用して各プレースホルダに対応する出力項目を取得する。 -既存プレースホルダの出力内容の変更や新規にプレースホルダを追加したい場合は、 -LogItemを実装したクラスとBasicLogFormatterを継承したクラスを作成することで実現できる。 - -ログフォーマッタの設定から起動プロセスを取得するように変更する場合の例を示す。 -ログフォーマッタの設定は、下記を想定する。 - -```bash -# ログフォーマッタの設定例(ログライタの設定は省略) -writer.appFile.className=＜ログライタのクラス名＞ -# カスタムのログフォーマッタを指定する。 -writer.appFile.formatter.className=nablarch.core.log.basic.CustomLogFormatter -# フォーマットを指定する。 -writer.appFile.formatter.format=$logLevel$ $loggerName$ [$bootProcess$] -# ログフォーマッタの設定で起動プロセスを指定する。 -# ここで指定した起動プロセスを$bootProcess$に出力する。 -writer.appFile.formatter.bootProcess=CUSTOM_PROCESS -``` - -まず、LogItemを実装したクラス(CustomBootProcessItem)を作成し、ログフォーマッタの設定から起動プロセスを取得する。 -CustomBootProcessItemの実装例を下記に示す。 - -```java -// カスタムの起動プロセスを取得するクラス。 -public class CustomBootProcessItem implements LogItem { - private String bootProcess; - public CustomBootProcessItem(ObjectSettings settings) { - // ログフォーマッタの設定から起動プロセスを取得する。 - bootProcess = settings.getProp("bootProcess"); - } - public String get(LogContext context) { - // 設定から取得した起動プロセスを返す。 - return bootProcess; - } -} -``` - -次に、BasicLogFormatterを継承し、作成したCustomBootProcessItemを追加する。実装例を下記に示す。 -BasicLogFormatterのgetLogItemsメソッドをオーバーライドしてCustomBootProcessItemを追加する。 - -```java -public class CustomLogFormatter extends BasicLogFormatter { - - // フォーマット対象のログ出力項目を取得するメソッドをオーバーライドする。 - protected Map> getLogItems(ObjectSettings settings) { - - // 起動プロセスのプレースホルダを上書きで設定する。 - Map> logItems = super.getLogItems(settings); - logItems.put("$bootProcess$", new CustomBootProcessItem(settings)); - return logItems; - } -} -``` - -ログフォーマッタの設定例に示した設定値によるログの出力例を下記に示す。 -ログフォーマッタの設定で指定した起動プロセスが出力される。 - -```bash -# ロブレベル、ロガー名、起動プロセスが出力される。 -INFO ROO [CUSTOM_PROCESS] -``` - -## プロパティファイルの記述ルール - -### ロガーファクトリの設定 - -| プロパティ名 | 設定値 | -|---|---| -| loggerFactory.className | 生成するロガーファクトリのクラス名。 LoggerFactoryを実装したクラスのFQCNを指定する。 | - -### フレームワーク実装の設定 - -#### ログライタの設定 - -| プロパティ名 | 設定値 | -|---|---| -| writerNames | 使用する全てのログライタの名称。必須。 複数指定する場合はカンマ区切り。 「"writer." + <ここで指定したログライタの名称>」をキーのプレフィックスにして、ログライタ毎の設定を行う。 | -| writer.<ログライタの名称>.className | ログライタのクラス名。必須。 LogWriterを実装したクラスのFQCNを指定する。 | -| writer.<ログライタの名称>.<プロパティ名> | ログライタ毎のプロパティに設定する値。 設定内容は、使用するログライタのJavadocを参照すること。 | - -#### ロガーの設定 - -| プロパティ名 | 設定値 | -|---|---| -| availableLoggersNamesOrder | 使用する全てのロガー設定の名称。必須。 複数指定する場合はカンマ区切り。 「"loggers." + <ここで指定されたロガー設定の名称>」をキーのプレフィックスに使用して、ロガー設定毎の設定を行う。 | -| loggers.<ロガー設定の名称>.nameRegex | ロガー名とのマッチングに使用する正規表現。必須。 正規表現は、ロガー設定の対象となるロガーを絞り込むために使用する。 ロガーの取得時に指定されたロガー名（つまりLoggerManager#getメソッドの引数に指定されたロガー名）に対してマッチングを行う。 | -| loggers.<ロガー設定の名称>.level | ログレベルの名称。必須。 LogLevel列挙型の名称を指定する。 ここで指定したレベル以上のログを全て出力する。 | -| loggers.<ロガー設定の名称>.writerNames | 出力先とするログライタの名称。必須。 複数指定する場合はカンマ区切り。 ここで指定した全てのログライタに対してログの書き込みを行う。 | - -#### FileLogWriterの設定 - -| プロパティ名 | 設定値 | -|---|---| -| writer.<ログライタの名称>.level | ログレベルの名称。(必須) LogLevel列挙型の名称を指定する。 ここで指定したレベル以上のログを全て出力する。 指定がない場合はレベルに応じた出力制御を行わず、全てのレベルのログを出力する。 | -| writer.<ログライタの名称>.formatter.className | ログライタで使用するログフォーマッタのクラス名。 LogFormatterを実装したクラスのFQCNを指定する。 | -| writer.<ログライタの名称>.formatter.<プロパティ名> | ログフォーマッタ毎のプロパティに設定する値。 設定内容は、使用するログフォーマッタのJavadocを参照すること。 | -| writer.<ログライタの名称>.filePath | 書き込み先のファイルパス。(必須) | -| writer.<ログライタの名称>.encoding | 書き込み時に使用する文字エンコーディング。オプション。 指定しなければシステムプロパティ(file.encoding)から取得した文字エンコーディング。 指定できるエンコーディングは、「java.nio.charset.Charset#forName」に指定する形式と同じである。 | -| writer.<ログライタの名称>.outputBufferSize | 出力バッファのサイズ。オプション。 単位はキロバイト。1000バイトを1キロバイトと換算する。 １以上を指定する。指定しなければ8KB。 | -| writer.<ログライタの名称>.maxFileSize | 書き込み先ファイルの最大サイズ。オプション。 単位はキロバイト。1000バイトを1キロバイトと換算する。 指定しなければ自動切替なし。 指定値が解析可能な整数値(Long.parseLong)でない場合は自動切替なし。 指定値が０以下の場合は自動切替なし。 古いログファイル名は、<通常のファイル名>.yyyyMMddHHmmssSSS.old。 | - -#### SynchronousFileLogWriterの設定 - -SynchronousFileLogWriterは、 [FileLogWriterの設定](../../component/libraries/libraries-01-Log.md#filelogwriterの設定) で記載したプロパティに加えて以下のプロパティを持つ。 - -| プロパティ名 | 設定値 | -|---|---| -| writer.<ログライタの名称>.lockFilePath | ロックファイルのパス。(必須) | -| writer.<ログライタの名称>.lockRetryInterval | ロック取得失敗時の再試行間隔（ミリ秒）。 指定しなければ1ミリ秒間隔で再試行が行われる。 | -| writer.<ログライタの名称>.lockWaitTime | ロック取得の待機時間（ミリ秒）。 ここで設定した時間を超えてもロックを取得できなかった場合、例外をスローする。 指定しなければ1800ミリ秒までロック取得待ちが行われる。 | -| writer.<ログライタの名称>.failureCodeCreateLockFile | ロックファイルが生成できない場合のログ出力に使用する障害通知コード。 指定しなければ以下のログが出力される。（{0}にはロックファイルのパスが設定される） "failed to create lock file. perhaps lock file path was invalid. lock file path=[{0}]." | -| writer.<ログライタの名称>.failureCodeReleaseLockFile | 生成したロックファイルを解放（削除）できない場合のログ出力に使用する障害通知コード。 指定しなければ以下のログが出力される。（{0}にはロックファイルのパスが設定される） "failed to delete lock file. lock file path=[{0}]." | -| writer.<ログライタの名称>.failureCodeForceDeleteLockFile | 解放されないロックファイルを強制削除できない場合のログ出力に使用する障害通知コード。 指定しなければ以下のログが出力される。（{0}にはロックファイルのパスが設定される） "failed to delete lock file forcedly. lock file was opened illegally. lock file path=[{0}]." | -| writer.<ログライタの名称>.failureCodeInterruptLockWait | ロック待ちでスレッドをスリープしている際に割り込みが発生した場合のログ出力に使用する障害通知コード。 指定しなければ以下のログが出力される。 "interrupted while waiting for lock retry." | - -#### BasicLogFormatterの設定 - -| プロパティ名 | 設定値 | -|---|---| -| writer.<ログライタの名称>.formatter.format | フォーマット文字列(オプション) | -| writer.<ログライタの名称>.formatter.datePattern | 日時のフォーマットに使用するパターン(オプション) 指定しなければはyyyy-MM-dd HH:mm:ss.SSS | -| writer.<ログライタの名称>.formatter.label. | ログレベルを表す文言(オプション) 指定しなければLogLevel列挙型の名称を使用する。 | - -## 各種ログの出力 - -本フレームワークでは、アプリケーションに共通で必要とされるログの種類を定義し、ログの種類毎に出力機能を提供する。 - -### ログの種類 - -本フレームワークで出力機能を提供しているログの種類を下記に示す。 - -| ログの種類 | 説明 | -|---|---| -| [障害通知ログ](../../component/libraries/libraries-01-FailureLog.md#障害ログの出力) | 障害発生時に1次切り分け担当者を特定するのに必要な情報を出力する。 | -| [障害解析ログ](../../component/libraries/libraries-01-FailureLog.md#障害ログの出力) | 障害原因の特定に必要な情報を出力する。 | -| [SQLログ](../../component/libraries/libraries-02-SqlLog.md#sqlログの出力) | 深刻なパフォーマンス劣化の要因となりやすいSQL文の実行について、パフォーマンスチューニングに使用するために、 SQL文の実行時間とSQL文を出力する。 | -| [パフォーマンスログ](../../component/libraries/libraries-03-PerformanceLog.md#パフォーマンスログの出力) | 任意の処理について、パフォーマンスチューニングに使用するために実行時間とメモリ使用量を出力する。 | -| [HTTPアクセスログ](../../component/libraries/libraries-04-HttpAccessLog.md#httpアクセスログの出力) | 画面オンライン処理において、アプリケーションの実行状況を把握するための情報を出力する。 アプリケーションの性能測定に必要な情報、アプリケーションの負荷測定に必要な情報の出力も含む。 さらに、アプリケーションの不正使用を検知するために、全てのリクエスト及びレスポンス情報を出力する証跡ログとしても使用する。 | - -本フレームワークでは、障害通知ログと障害解析ログを合わせて障害ログと呼ぶ。 -ここでは、各種ログの共通項目のフォーマットと各種ログの設定について説明する。 -各種ログの詳細は下記を参照。 - -01/01_FailureLog -01/02_SqlLog -01/03_PerformanceLog -01/04_HttpAccessLog - -### 各種ログの共通項目のフォーマット - -各種ログの出力は、 [ログ出力要求受付処理](../../component/libraries/libraries-01-Log.md#ログ出力要求受付処理) を使用してログ出力を行う。 -このため、各種ログの共通項目は、使用するログ出力実装に依存する。 -各種ログの出力では、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) の出力項目を共通項目とする。 -したがって、各種ログの出力にフレームワーク以外のログ出力実装を使用する場合は、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) と同等の出力項目を出力できるように実装が必要となる。 -以降では、各種ログの出力にフレームワーク実装を使用することを想定して説明する。 - -各種ログのフォーマットは、下記2つのフォーマットから構成される。 - -a) 各種ログの共通項目のフォーマット( [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) のフォーマット) -b) 各種ログの個別項目のフォーマット - -これら2つのフォーマットは、各種ログの個別項目をフォーマットした結果を、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) のプレースホルダ$message$に指定することで組み合わせる。 -HTTPアクセスログを例にフォーマット指定のイメージを下記に示す。 - -```bash -# 共通項目のフォーマット(BasicLogFormatterのフォーマット) -$date$ req_id = [$requestId$] <$message$> usr_id = [$userId$] - -# $message$以外の共通項目をフォーマットした結果 -2011-02-07 19:07:30.970 req_id = [USERS00302] <$message$> usr_id = [0000000001] -``` - -```bash -# 個別項目のフォーマット(HTTPアクセスログのフォーマット) -# $url$: リクエストURL、$port$: ポート番号、$method$: HTTPメソッドが入るプレースホルダとする。 -url:$url$ port:$port$ method:$method$ - -# 個別項目をフォーマットした結果 -url:/action/management/user/UserRegisterAction/USERS00302 port:8090 method:POST -``` - -上記フォーマット指定におけるHTTPアクセスログの出力例を下記に示す。 -BasicLogFormatterの$message$部分に、HTTPアクセスログの個別項目をフォーマットした結果が入る。 - -```bash -# アクセスログの出力例 -2011-02-07 19:07:30.970 req_id = [USERS00302] usr_id = [0000000001] -``` - -### 各種ログの設定 - -各種ログの出力では、フォーマットなどの設定をプロパティファイルに指定する。 -プロパティファイルは、クラスパス直下に"app-log.properties"というファイル名で配置する。 -配置場所を変更したい場合は、"nablarch.appLog.filePath"というキー名でシステムプロパティを指定する。 -プロパティファイル内の設定値は、プロパティ名と同じキー名でシステムプロパティを指定することで実行時に変更できる。 - -システムプロパティの設定例を下記に示す。 -javaコマンドのオプション-Dによる指定を用いて、下記のように実行時のオプションとしてシステムプロパティを設定する。 - -```bash ->java -Dnablarch.appLog.filePath=/var/log/app/app-log.properties ... -``` - -## フレームワークのログ出力方針 - -本フレームワークでは、下記の出力方針に基づきログ出力を行う。 - -| ログレベル | 出力方針 | -|---|---| -| FATAL / ERROR | [障害ログ](../../component/libraries/libraries-01-FailureLog.md#障害ログの出力) は、障害監視の対象であり、障害発生時の一時切り分けの起点ともなる為、 原則として1件の障害に対して、1件の障害ログを出力する方針としている。 このため、 [実行制御基盤](../../about/about-nablarch/about-nablarch-fw.md#目次) では単一のハンドラ(例外を処理するハンドラ)により障害通知ログを出力する方針としている。 なお、出力するレベル及び出力方針は、各実行制御基板のハンドラ構成及び例外を処理するハンドラの仕様に依存するため、 詳細は [実行制御基盤](../../about/about-nablarch/about-nablarch-fw.md#目次) のハンドラ構成及び例外を処理するハンドラの仕様を参照すること。 | -| WARN | 障害発生時に連鎖して例外が発生した場合など、障害ログとして出力できない例外をWARNレベルで出力する。 例えば、業務処理とトランザクションの終了処理の2つで例外が発生した場合は、 業務処理の例外を障害ログに出力し、トランザクションの終了処理の例外をWARNレベルで出力する。 | -| INFO | アプリケーションの実行状況に関連するエラーを検知した場合にINFOレベルで出力する。 例えば、URLパラメータの改竄エラーや認可エラーが発生した場合にINFOレベルで出力する。 | -| DEBUG | アプリケーション開発時に使用するデバッグ情報を出力する。 アプリケーション開発時は、DEBUGレベルを設定することで開発に必要な情報が出力されるよう考慮している。 | -| TRACE | フレームワーク開発時に使用するデバッグ情報を出力する。 アプリケーション開発での使用は想定していない。 | diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-01-Repository-config.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-01-Repository-config.md deleted file mode 100644 index c2441bb92..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-01-Repository-config.md +++ /dev/null @@ -1,1055 +0,0 @@ -## 設定ファイルの種類とフレームワークが行うリポジトリの初期化 - -リポジトリの設定は、文字列による設定値をプロパティファイルに似た形式で記述する、 **環境設定ファイル** -とリポジトリに保持するインスタンスを設定する **コンポーネント設定ファイル** [1] の2種類の設定ファイルで行う。 - -Web フレームワークやバッチフレームワーク上のアプリケーションでは、設定を読み込む処理を特別に意識する必要はなく、 -単純に設定ファイルを記述するだけでリポジトリが使用できる。 -これは、これらのフレームワークが起動する際にリポジトリの初期化を自動的に実行しているためである。 - -以下にこれらフレームワークが行うリポジトリの初期化処理の実装方法と、設定ファイルの記述方法について記述する。 - -「コンポーネント設定ファイル」は本章で登場する「環境設定ファイル」と区別するために -使用する用語であり、他の章では単に「設定ファイル」と記述する。 - -## 環境設定ファイルからの読み込み - -リポジトリの内部に保持するオブジェクトはObjectLoaderで読み込む必要がある。 -ObjectLoaderからリポジトリにオブジェクトを読み込む処理には、SystemRepositoryのloadメソッドを呼び出す。 - -ConfigFileLoaderを使用して環境設定ファイルに記述した設定を読み込み、リポジトリから設定値を取得する実装例を下記に示す。 - -> **Warning:** -> 以降の実装例では、 ConfigFileLoader 、 XmlComponentDefinitionLoader 、 SystemRepository 等の使用形態を明確にするために -> これらクラスを使用した初期化処理を示している。 - -> しかし通常のアプリケーションでは、初期化処理は Web およびバッチフレームワークのブートストラップの処理内で行われるため、 -> これらブートストラップの処理の実装者以外はこのような処理の実装は必要ない。 - -> ここではあくまでこれらのフレームワーク外で使用する際の仕様方法を記載していることに留意すること。 - -### 読み込む環境設定ファイル(sample.config)の記述例 - -```bash -sample.value1=example-setting -sample.value2=true -``` - -> **Note:** -> 環境設定ファイルの記述ルールの詳細については、 [環境設定ファイル記述ルール](../../component/libraries/libraries-02-01-Repository-config.md#環境設定ファイル記述ルール) を参照。 - -### 環境設定ファイルの読み込み (通常フレームワークの責務) - -```java -// ******** 注意 ******** -// 直下のコードはブートストラップ処理で行うべき処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -ConfigFileLoader loader = new ConfigFileLoader("sample.config"); -// 環境設定ファイルの内容をロード -SystemRepository.load(loader); -// 設定値を取得("example-setting"が取得できる) -``` - -### 環境設定の取得 - -環境設定の取得には、 SystemRepository クラスの getString または getBoolean メソッドを使用する。 - -下記に実装例を示す。 - -```java -String value1 = SystemRepository.getString("sample.value1"); -// 設定値を取得(trueが取得できる) -boolean value2 = SystemRepository.getBoolean("sample.value2"); -``` - -> **Warning:** -> 環境設定値を取得する際に指定するキー値には、ユーザ入力値やデータベースから取得した値を使用しないこと。 -> この様なキー値を使用した場合、環境設定値が取得できないことにより、障害が発生する可能性が高くなる。 -> また、設定値が取得できずに障害が発生した場合も、キー値が可変では障害解析の難易度が上がる。 - -> キー値を常に固定値としていた場合、仮に設定値が取得出来なかった場合でも障害発生箇所を元にしておけば、 -> キー値を割り出すことが容易であるため、上記のような問題は発生しない。 - -## リポジトリに保持するインスタンスの生成(DIコンテナ) - -リポジトリに保持するインスタンスは、DIコンテナで生成する。 -DIコンテナは以下の責務を持つ。 - -* コンポーネントをインスタンス化する。 -* インスタンスのプロパティに、コンポーネント設定ファイルに記述した値を設定する。 -* コンポーネント間を関連付ける。 - -DIコンテナはコンポーネント設定ファイルを読み込み、コンポーネントの生成、登録を行う。 -コンポーネントとして登録されるクラスは、下記2つの条件を満たしていればよい。 - -* クラスにデフォルトコンストラクタを持つこと -* クラスのプロパティに対応したセッタメソッドを持つこと。 - -画面に Hello メッセージを表示する単純な例で使用方法を説明する。 -この例では、 HelloMessageProvider クラス HelloComponent クラスの2つをそれぞれコンポーネントとして登録し、これらのコンポーネントを関連付ける。 -この例で使用する HelloMessageProvider クラスは、単にメッセージの文字列を保持するだけの責務を持ち、 -getHelloMessage メソッドで保持したメッセージを返す。 -HelloComponent クラスは、 HelloMessageProvider クラスを保持しており、 HelloMessageProvider クラスの -getHelloMessage メソッドで取得したメッセージをコンソールに画面を表示する責務を持つ。 - -以下に登録するクラスのソースコードを示す。 - -### 登録するクラスのソースコード(HelloMessageProvider) - -```java -public class HelloMessageProvider { - private String helloMessage; - - public void setHelloMessage(String hello) { - this.helloMessage = hello; - } - - public String getHelloMessage() { - return helloMessage; - } -} -``` - -### 登録するクラスのソースコード(HelloComponent) - -```java -public class HelloComponent { - - private HelloMessageProvider helloMessageProvider; - - public void setHelloMessageProvider(HelloMessageProvider helloProvider) { - this.helloMessageProvider = helloProvider; - } - - public void printHello() { - System.out.println(helloMessageProvider.getHelloMessage()); - } -} -``` - -### コンポーネント設定ファイルの記述(hello.xml) - -DIコンテナはコンポーネント設定ファイルを元にしてコンポーネントの生成を行う。 -コンポーネント設定ファイルは、登録するコンポーネントを component 要素、コンポーネントのプロパティに関する設定を property 要素で記述する。 - -例えば、上記の HelloMessageProvider と HelloComponent の2つのクラスをコンポーネントとして登録し、 -コンポーネント間を関連付ける場合、下記のようにコンポーネント設定ファイルを記述する。 - -```xml - - - - - - - - - - - - -``` - -コンポーネント設定ファイルの要素、属性については [コンポーネント設定ファイル 要素 リファレンス](../../component/libraries/libraries-02-01-Repository-config.md#コンポーネント設定ファイル-要素-リファレンス) に詳細を記述する。 - -なお、eclipse等のIDEでは、 [component-configuration.xsd ファイル](../../../knowledge/assets/libraries-02-01-Repository-config/component-configuration.xsd) -をコンポーネント設定ファイルと同一ディレクトリに配置し、 component-configuration 要素の xsi:schemaLocation -属性を上記のように適切に設定することで、下記図のようにxsdの定義に書かれたコメントを確認しながらXMLファイルを編集できる。 -この他にもXMLのバリデーションや入力補完等のメリットが得られるため、IDEを使用する際は必ず xsi:schemaLocation を -適切に設定することを推奨する。 - -![eclipse-xml-editing.jpg](../../../knowledge/assets/libraries-02-01-Repository-config/eclipse-xml-editing.jpg) - -> **Note:** -> リポジトリは、フレームワークが提供するクラスのみをコンポーネントとして保持することを前提に設計しており、 -> Spring Framework や Seasar2 といった他のDIコンテナのようにビジネスロジックやデータアクセスを行うオブジェクトを登録することを想定していない。 -> この前提により、リポジトリはこれらDIコンテナが持つレイジーロードの機能を持っていない。 -> このため、DIコンテナにビジネスロジックやデータアクセスを行うオブジェクトを登録する使用方法を行うと、 -> アプリケーションの起動が遅くなり、ユニットテストやローカルでの画面テストの効率が悪化する。 -> このような使用方法を行う際は、このデメリットが許容範囲にあるか十分に検討すること。 - -### 値を取得する実装例 - -記述したコンポーネント設定ファイルを元にしてDIコンテナを使用する手順は下記のようになる。 - -1. コンポーネント設定ファイル名を指定して XmlComponentDefinitionLoader のインスタンスを生成する。 -2. 生成した XmlComponentDefinitionLoader のインスタンスを引数にして、DIコンテナのインスタンスを生成する。 -3. 生成したDIコンテナのインスタンスからコンポーネントを取得する。 - -上記手順の実装例を下記に示す。 - -```java -// ******** 注意 ******** -// 直下のコードでは、DIコンテナの動作を説明するために、DIコンテナを直接使用してコンポーネントを取得している。 -// しかし通常、コンポーネントの取得は以下で説明するSystemRepository からコンポーネントを取得する方法で実装する。 -// 従って、本フレームワークを使用する場合、このような実装は行わない。 - -XmlComponentDefinitionLoader loader - = new XmlComponentDefinitionLoader("nablarch/core/repository/di/example/hello/hello.xml"); -DiContainer container = new DiContainer(loader); - -// DIコンテナで"helloComponent"と名付けたコンポーネントを取得 -HelloComponent helloComponent = (HelloComponent) container.getComponentByName("helloComponent"); - -// HelloMessageProviderに設定した"hello"がコンソールに表示される -helloComponent.printHello(); -``` - -## DIコンテナを ObjectLoader として使用する - -前述の通り、 DiContainer は、 ConfigFileLoader と同様に ObjectLoader として使用することで、登録したコンポーネントを SystemReporitory に登録できる。 -以下にDIコンテナを使用した SystemRepository の初期化処理と、リポジトリからコンポーネントを取得する実装例を示す。 - -### SystemRepository の初期化処理 - -```java -// ******** 注意 ******** -// 直下のコードはブートストラップ処理で行うべき処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -XmlComponentDefinitionLoader loader - = new XmlComponentDefinitionLoader("nablarch/core/repository/di/example/hello/hello.xml"); -DiContainer container = new DiContainer(loader); -SystemRepository.load(container); -``` - -### SystemRepository からのコンポーネント取得 - -```java -// SystemRepositoryから"helloComponent"と名付けたコンポーネントを取得 -HelloComponent helloComponent = (HelloComponent) SystemRepository.getObject("helloComponent"); -// HelloMessageProviderに設定した"hello"がコンソールに表示される -helloComponent.printHello(); -``` - -## property 要素の value 属性で設定できる型 - -property 要素の value 属性で指定する値は、文字列の他にも、文字列による表現で値を設定できる。 -この機能をプロパティの簡易設定機能と呼ぶ。 - -プロパティの簡易設定機能を使用して設定できるプロパティの型は下記の通り。 - -1. java.lang.String -2. boolean -3. java.lang.Boolean -4. int -5. java.lang.Integer -6. long -7. java.lang.Long -8. java.lang.String[] -9. int[] -10. java.lang.Integer[] - -下記に使用例を示す。 - -### インジェクション対象のクラス - -```java -public class PrimitiveValueHolder { - private String stringValue; - private boolean boolValue; - private Boolean boolWrapperValue; - private int intValue; - private Integer intWrapperValue; - private long longValue; - private Long longWrapperValue; - private String[] stringArrayValue; - private int[] intArrayValue; - private Integer[] integerArrayValue; - - // setter、getter省略 -} -``` - -### コンポーネント設定ファイル - -```xml - - - - - - - - - - - - - - -``` - -上記設定により、値が設定された PrimitiveValueHolder のインスタンスが SystemRepository から取得できる。 - -### コンポーネントを取得する実装例 - -```java -// DIコンテナで"primitiveValueHolder"と名付けたコンポーネントを取得 -PrimitiveValueHolder primitiveValueHolder - = (PrimitiveValueHolder) SystemRepository.getObject("primitiveValueHolder"); - -// 設定した"string value"が取得できる -System.out.println(primitiveValueHolder.getStringValue()); - -// 設定したtrueが取得できる -System.out.println(primitiveValueHolder.isBoolValue()); - -// 設定したfalseが取得できる -System.out.println(primitiveValueHolder.getBoolWrapperValue()); - -// 設定した2が取得できる -System.out.println(primitiveValueHolder.getIntValue()); - -// 設定した3が取得できる -System.out.println(primitiveValueHolder.getIntWrapperValue()); - -// 設定した5が取得できる -System.out.println(primitiveValueHolder.getLongValue()); - -// 設定した6が取得できる -System.out.println(primitiveValueHolder.getLongWrapperValue()); - -// 設定した["abc","def","ghi"]が取得できる -for (String val : primitiveValueHolder.getStringArrayValue()) { - System.out.println(val); -} - -// 設定した[1, 2, 3]が取得できる -for (int val : primitiveValueHolder.getIntArrayValue()) { - System.out.println(val); -} - -// 設定した[4, 5, 6]が取得できる -for (Integer val : primitiveValueHolder.getIntegerArrayValue()) { - System.out.println(val); -} -``` - -## List と Map をコンポーネントとして登録する - -リポジトリに登録するコンポーネントの一部には、List や Map のプロパティを持たせたいことがある。 -これらのプロパティに値を設定できるよう、コンポーネント設定ファイルでは List および Map をコンポーネントとして登録できる要素を提供している。 - -List をコンポーネントとして登録するには、 list 要素、 Map をコンポーネントとして登録するには、 map 要素を使用する。 -設定の記述方法は [list 要素](../../component/libraries/libraries-02-01-Repository-config.md#list-要素) および [map 要素](../../component/libraries/libraries-02-01-Repository-config.md#map-要素) を参照。 - -以下にそれぞれの要素の使用方法について記述する。 - -### list 要素の使用方法 - -component-configuration 要素の子要素に記述する例を以下に示す。 - -```xml - - - - - - - - - - - - - - - - - - - - String value - - -``` - -上記設定により、設定した List が取得できる。 - -```java -ComponentA compA = (ComponentA) SystemRepository.getObject("compA"); -List list = compA.getListProperty(); -ComponentB compB_0 = (ComponentB) list.get(0); -// "compB_0" が取得できる -System.out.println(compB_0.getName()); - -ComponentB compB_1 = (ComponentB) list.get(1); -// "compB_1" が取得できる -System.out.println(compB_1.getName()); - -String stringValue = (String) list.get(2); -// 文字列 "String value" が取得できる -System.out.println(stringValue); -``` - -### map 要素の使用方法 - -map 要素を component-configuration 要素の内部に記述する例を以下に示す。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -上記設定により、下記のように設定した Map が取得できる。 - -```java -ComponentA compA = (ComponentA) SystemRepository.getObject("compA"); -Map map = compA.getMapProperty(); - -ComponentB compB_0 = (ComponentB) map.get("compB_0"); -// "compB_0" が取得できる -System.out.println(compB_0.getName()); - -ComponentB compB_2 = (ComponentB) map.get("compB_2"); -// "compB_2" が取得できる -System.out.println(compB_2.getName()); - -String stringValue = (String) map.get("stringKey"); -// "String value" が取得できる -System.out.println(stringValue); - -KeyComponent key = new KeyComponent(); -key.setId("00001"); -key.setLang("ja"); -ComponentB compB_3 = (ComponentB) map.get(key); -// "compB_3" が取得できる -System.out.println(compB_3.getName()); -``` - -## コンポーネント設定ファイルからの環境設定ファイル読み込み - -コンポーネント設定ファイルには、環境設定ファイルに記述した設定値の読み込みを指定できる機能がある。 -環境設定ファイルの読み込みには、 config-file 要素を使用する。 - -以下に例を示す。 - -### 読み込む環境設定ファイル(hello.config) - -```bash -hello.message = This is Hello Message!! -``` - -### コンポーネント設定ファイル - -```xml - - - - - -``` - -### 設定した値を取得する実装例 - -```java -// hello.configに設定した "This is Hello Message!!" が取得できる。 -String helloMessage = SystemRepository.getString("hello.message"); -``` - -## 複数のコンポーネント設定ファイルの読み込み - -コンポーネント設定ファイルにimport要素を記述することで、他のコンポーネント設定ファイルを読み込むことができる。 - -以下に2つの設定ファイルを読み込む設定ファイルの記述例を示す。 - -### 読み込まれるコンポーネント設定ファイル(imported1.xml) - -```xml - - - - - -``` - -### 読み込まれるコンポーネント設定ファイル(imported2.xml) - -```xml - - - - - -``` - -### imported1.xmlとimported2.xmlを読み込むコンポーネント設定ファイル - -```xml - - - - -``` - -### 設定した値を取得する実装例 - -```java -// ******** 注意 ******** -// 直下のコードはブートストラップ処理で行うべき処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -// 最もrootに近い設定ファイルを読み込み -XmlComponentDefinitionLoader loader = new XmlComponentDefinitionLoader("nablarch/core/repository/di/example/imp/import.xml"); -DiContainer container = new DiContainer(loader); -SystemRepository.load(container); - -// imported1.xml に記述したクラスの読み込み -HelloImport helloImport1 = (HelloImport) SystemRepository.getObject("helloImport1"); -// "imported1" が取得できる。 -System.out.println(helloImport1.getValue()); - -// imported2.xml に記述したクラスの読み込み -HelloImport helloImport2 = (HelloImport) SystemRepository.getObject("helloImport2"); -// "imported2" が取得できる。 -System.out.println(helloImport2.getValue()); -``` - -## 環境設定ファイルに記述した値をコンポーネント設定ファイルで使用する - -コンポーネントのプロパティには、環境設定ファイルに記述した値も設定できる。 -データベースへの接続設定など、環境依存する項目を、環境設定ファイルに記述することで、xmlによる設定と分離できる。 - -プロパティの簡易設定機能を使用するには、下記2種類の設定が必要となる。 - -1. 読み込む環境設定ファイルを作成する。 -2. コンポーネント設定ファイルの property 要素の value 属性に指定する文字列に "${hello.message}" のように環境設定ファイルに記述したキーを${}で囲う文字列を設定する。 - -以下に [リポジトリに保持するインスタンスの生成(DIコンテナ)](../../component/libraries/libraries-02-01-Repository-config.md#リポジトリに保持するインスタンスの生成diコンテナ) で示した HelloMessageProvider に設定するメッセージを外部ファイルに持たせる場合の設定例を示す。 - -### 読み込む環境設定ファイル(hello.config) - -```bash -hello.message = This is Hello Message!! -``` - -### コンポーネント設定ファイル - -```xml - - - - - - - - - - - - - - -``` - -### 設定した値を取得する実装例 - -```java -HelloComponent helloComponent = (HelloComponent) SystemRepository.getObject("helloComponent"); -// XMLファイルに書いた"${hello.message}"ではなく、環境設定ファイルに設定した"This is Hello Message!!"が出力される。 -helloComponent.printHello(); -``` - -### 使用できる項目 - -この設定方法は、コンポーネント設定ファイルの下記に示す箇所で使用できる。 - -* property 要素の value 属性 ([参照](../../component/libraries/libraries-02-01-Repository-config.md#property-要素)) -* entry 要素の key 属性 ([参照](../../component/libraries/libraries-02-01-Repository-config.md#entry-要素)) -* entry 要素の value 属性 ([参照](../../component/libraries/libraries-02-01-Repository-config.md#entry-要素)) -* value 要素の内容 ([参照](../../component/libraries/libraries-02-01-Repository-config.md#value-要素)) - -entry 要素および list 要素での使用例を下記に示す。 - -```xml - - - - - [${any.key05}] - -``` - -## ディレクトリに配置された設定ファイルの読み込み - -import 要素および config-file 要素では、 dir 属性を設定することでディレクトリに配置されたファイルを一括して読み込める。 - -dir 属性には、コンポーネント設定ファイルが配置されているディレクトリからの相対パスを指定すること。 -たとえば、コンポーネント設定ファイルが /opt/component.xml のパスに配置されている場合に、 -/opt/environment_config ディレクトリ以下にある設定ファイルを一括して読み込む場合は、 -dir 属性に "./environment_config" と設定する。 - -以下に設定ファイルの例を示す。 - -### コンポーネント設定ファイル - -```xml - - - - - - - -``` - -この機能を使用することで、複数拠点からリリースされた設定ファイルを1つのディレクトリに配置し、一括で読み込むことが可能となる。 -例えば、個別のファイル名を指定して読み込む際、ファイル名を直接指定する設定方法を用いると、設定ファイルの増減やファイル名の変更が発生した際に都度 import タグや config-file タグを書き直す必要が出てきてしまう。 -このように読み込むファイルが頻繁に変更される場合、上記例のようにディレクトリ指定で読み込む機能を使用することで、個別のファイルの読み込み設定を変更する手間が抑制できる。 - -また、 [設定値の上書きの対象](../../component/libraries/libraries-02-04-Repository-override.md#設定値の上書きの対象) に記述した方法で、本番用とテスト用で異なる設定を特定のディレクトリに配置して、本番環境とテスト環境の差異を吸収するといった使い方もできる。 - -なお、別々の設定ファイルに記述された同名の設定は [import 要素および config-file 要素による外部ファイル読み込み時の優先順位](../../component/libraries/libraries-02-04-Repository-override.md#import-要素および-config-file-要素による外部ファイル読み込み時の優先順位) -および [dir 属性を使用した読み込み時の優先順位](../../component/libraries/libraries-02-04-Repository-override.md#dir-属性を使用した読み込み時の優先順位) に記述した優先順位で評価される。 - -## 自動インジェクション - -DIコンテナは、 [リポジトリに保持するインスタンスの生成(DIコンテナ)](../../component/libraries/libraries-02-01-Repository-config.md#リポジトリに保持するインスタンスの生成diコンテナ) で記述したref属性の設定によるインジェクションの他に、クラスの型を判定して -自動的にインジェクションを実行する、自動インジェクションの機能を持つ。 -この機能により、システムで1つしか必要としないコンポーネントについては property 要素によるインジェクションの設定が不要となる。 - -[リポジトリに保持するインスタンスの生成(DIコンテナ)](../../component/libraries/libraries-02-01-Repository-config.md#リポジトリに保持するインスタンスの生成diコンテナ) で示したサンプルの HelloMessageProvider をインタフェースと実装を下記のように分離した例を使用して、設定例を説明する。 - -### Helloメッセージを取得するインタフェース - -```java -public interface HelloMessageProvider { - public String getHelloMessage(); -} -``` - -### Helloメッセージを取得するインタフェースを実装したクラス - -```java -public class BasicHelloMessageProvider implements HelloMessageProvider { - - public String getHelloMessage() { - return "Hello autowire!!"; - } -} -``` - -### Helloメッセージを取得するインタフェースを使用するクラス - -```java -public class HelloComponent { - - private HelloMessageProvider helloMessageProvider; - - public void setHelloMessageProvider(HelloMessageProvider helloProvider) { - this.helloMessageProvider = helloProvider; - } - - public void printHello() { - System.out.println(helloMessageProvider.getHelloMessage()); - } -} -``` - -HelloMessageProvider インタフェースを実装した BasicHelloMessageProvider クラスと、 HelloMessageProvider インタフェース -を使用する HelloComponent クラスは、インタフェースを介して互いに疎結合(クラス間の参照関係がない)な関係にある。 -これらのクラスを下記設定を行うことで、DIコンテナにより動的に結合して使用できる。(※) - -※互いに疎結合な状態のまま結合できるという利点は、DIコンテナの持つ特性であり、 -自動インジェクションを使用しない場合でもDIコンテナを使用することでこのメリットは享受できる。 - -以下に自動インジェクションの設定例を示す。 - -### 設定例 - -```xml - - - - - - - - -``` - -上記設定例からわかる通り、自動インジェクションを使用することで、コンポーネント設定ファイルのproperty要素の記述が不要となり、 -設定作業が簡略化できる。 - -### 設定したコンポーネントの取得例 - -この設定により、下記のように SystemRepository から取得した HelloComponent には、 -下記のように自動的に HelloMessageProvider インタフェースを実装した BasicHelloMessageProvider が設定される。 - -```java -// DIコンテナで"helloComponent"と名付けたコンポーネントを取得 -// HelloComponentにはHelloMessageProviderインタフェースのセッタが存在する -HelloComponent helloComponent = (HelloComponent) container.getComponentByName("helloComponent"); -// 自動インジェクションされたBasicHelloMessageProviderが返す "Hello autowire!!"が表示される -helloComponent.printHello(); -``` - -## ネストするコンポーネントの設定 - -コンポーネント設定ファイルの property 要素は、 component 要素をネストして記述できる。 -この記述方法により、1つのコンポーネントからのみ使用されるコンポーネントを簡潔に記述できる。 - -ネストしたコンポーネントのコンポーネント名は、親となるコンポーネントの名称とコンポーネント定義の名称を"."で繋いだ名称となる。 - -以下に [自動インジェクション](../../component/libraries/libraries-02-01-Repository-config.md#自動インジェクション) で示した例の設定を、ネストした形式で記述するコンポーネント設定ファイルの例を示す。 - -### コンポーネント設定ファイル - -```xml - - - - - - - -``` - -### 設定したコンポーネントの取得例 - -```java -// DIコンテナで"helloComponent"と名付けたコンポーネントを取得 -HelloComponent helloComponent = (HelloComponent) SystemRepository - .getObject("helloComponent"); -// HelloMessageProviderに設定した"hello"がコンソールに表示される -helloComponent.printHello(); - -// helloComponent.helloMessageProvider というコンポーネント名でhelloComponentに -// ネストしたhelloMessageProviderコンポーネントが取得できる。 -HelloMessageProvider helloMessageProvider = (HelloMessageProvider) SystemRepository - .getObject("helloComponent.helloMessageProvider"); - -// 直接 HelloMessageProvider.getHelloMessageメソッドを呼び出す。 -System.out.println(helloMessageProvider.getHelloMessage()); -``` - -## 環境設定ファイル記述ルール - -環境設定ファイルは、基本的にキーと値を '=' で対応付けて記述する。 - -設定の記述には、キーと値以外にコメントを記述するためや、設定値を読み易くするために特殊な意味を持つ文字を使用する。 -これら特殊な意味を持つ文字について、以下に記述する。 - -### デリミタ文字（'='） - -デリミタ文字は'='のみで、空白（タブを含む）や":"も文字列の一部とみなす。 (いわゆるpropertiesファイルとは異なる。） 但し、キー及び値はそれぞれ前後の空白（タブを含む）をトリミングする。 (" A B "(スペースAスペースBスペース)という文字列は "A B"(AスペースB)となる。キーの'A'と'a'は区別される。) デリミタ文字'='で区切られた３つめ以降のトークンは無視する。 -'='をキーまたは値に含めたい場合は前に'\'を付加する。 - -### コメント文字（'#'） - -コメント文字'#'を使用するとその行の以降の文字列はコメントとみなす。 '#'によるコメントを除去する処理は行連結の前に行われるので、 継続行中でも使用可能（下記「使用例」参照）。 -'#'をキーまたは値に含めたい場合は前に'\'を付加する。 - -### 改行文字（'\'） - -キーと値のセットは行末に'\'を指定することによって行をまたがることが可能。 その場合'\'を除いた文字列と次の行の先頭の空白（タブを含む）を除いた 文字列を連結する。（'\'を除いた文字列の後方の空白は維持する。） -キーまたは値の行末に'\'を含めたい場合は前に'\'を付加する。 - -### エスケープ文字（'\'） - -'\'を記述すると次の１文字を特殊文字ではなく一般文字として扱う。 -'\'をキーまたは値に含めたい場合は前に''を付加する。 - -読み込むファイルの記述例： - -```bash -# キー＝"key"、値＝"value"の場合 -key = value # commnet -key = value = commnet - -# キー＝"key"、値＝"value1 = value2"の場合 -key = value1 \= value2 #comment -key = \ - value1 \= value2 - -# キー＝"key"、値＝"value1,value2,value3"の場合 -key = value1,value2,value3 # comment -key = value1,\ - value2,\ - value3 # comment -key = value1,\ # comment - value2,\ # comment - value3 # comment -``` - -> **Note:** -> 下記のように改行文字の前にコメントを入れた場合、設定は正しく動作しないため、注意すること。 - -> ```bash -> # 下記はNG。 -> key = value1, # comment \ -> value2, # comment \ -> value3 # comment -> ``` - -## コンポーネント設定ファイル 要素 リファレンス - -コンポーネント設定ファイルで使用できるそれぞれの要素について、以下に記述する。 - -### component-configuration 要素 - -コンポーネント設定ファイルのルート要素 - -この要素が持つ子要素を下記表に示す。 - -| 要素名 | 出現回数 | 説明 | -|---|---|---| -| [import](../../component/libraries/libraries-02-01-Repository-config.md#import-要素) | 0..* | 他のコンポーネント設定ファイルの読み込みを指定する。 | -| [config-file](../../component/libraries/libraries-02-01-Repository-config.md#config-file-要素) | 0..* | 環境設定ファイルの読み込みを指定する。 | -| [component](../../component/libraries/libraries-02-01-Repository-config.md#component-要素) | 0..* | Java Beans 形式のクラスをコンポーネントとして定義する。 | -| [list](../../component/libraries/libraries-02-01-Repository-config.md#list-要素) | 0..* | List をコンポートとして定義する。 List のエントリには、他のコンポーネントや文字列を含めることができる。 | -| [map](../../component/libraries/libraries-02-01-Repository-config.md#map-要素) | 0..* | Map をコンポーネントとして定義する。 Map のエントリのキーと値には、他のコンポーネントや文字列を含めることができる。 | - -この要素は属性を持たない。 - -### import 要素 - -他のコンポーネント設定ファイルの読み込みを指定する。 - -この要素は子要素を持たない。 - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| file(必須) | インポートするファイル名を指定する。 単純にパスを記述した場合、クラスパスにあるファイルをインポートする。 "[file://](file://)" から始まるパスの場合、ローカルファイルシステム上のファイルをインポートする。 また、 dir を指定した場合には "*" を使用してワイルドカードを使用した複数ファイルのインポートが行える。 | -| dir | インポート対象のディレクトリを、本属性が記述されているコンポーネント設定ファイルからの相対パスで指定する。 この指定を行った場合、指定したディレクトリ直下のファイルがインポートされる。 | - -### config-file 要素 - -環境設定ファイルの読み込みを指定する。 - -この要素は子要素を持たない。 - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| file(必須) | 読み込むファイル名を指定する。 単純にパスを記述した場合、クラスパスにあるファイルを読み込む。 "[file://](file://)" から始まるパスの場合、ローカルファイルシステム上のファイルを読み込む。 また、 dir を指定した場合には "*" を使用してワイルドカードを使用した複数ファイルの読み込みが行える。 | -| dir | 読み込むファイルのディレクトリを、本属性が記述されているコンポーネント設定ファイルからの相対パスで指定する。 この指定を行った場合、指定したディレクトリ直下のファイルが読み込まれる。 | -| encoding | 環境設定ファイルの文字エンコーディングを指定する。 省略した場合、UTF-8エンコーディングが使用される。 | - -### component 要素 - -コンポーネントを定義する。 - -この要素が持つ子要素を下記表に示す。 - -| 要素名 | 出現回数 | 説明 | -|---|---|---| -| [property](../../component/libraries/libraries-02-01-Repository-config.md#property-要素) | 0..* | コンポーネントのプロパティに設定する値を指定する。 | - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| name | コンポーネント名を指定する。 | -| class(必須) | コンポーネントのクラス名を指定する。 | -| autowireType | コンポーネントに対する自動インジェクションの方法を指定する。 指定できる値は下記いずれか。 * ByType: 型による自動インジェクションを行う。 * ByName: 名前による自動インジェクションを行う。 * None: 自動インジェクションを行わない。 省略した場合、ByType。 | - -### property 要素 - -コンポーネントのプロパティを設定する。 - -この要素が持つ子要素を下記表に示す。 - -| 要素名 | 出現回数 | 説明 | -|---|---|---| -| [component](../../component/libraries/libraries-02-01-Repository-config.md#component-要素) | 0..1 | プロパティに設定するコンポーネントを指定する。 | -| [list](../../component/libraries/libraries-02-01-Repository-config.md#list-要素) | 0..1 | プロパティに設定する List を指定する。 | -| [map](../../component/libraries/libraries-02-01-Repository-config.md#map-要素) | 0..1 | プロパティに設定する Map を指定する。 | - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| name | プロパティ名を指定する。 | -| value | プロパティに設定する値を直接指定する。 | -| ref | プロパティに設定するコンポーネントの、コンポーネント名を指定する。 | - -### list 要素 - -List をコンポーネントとして定義する。 - -この要素が持つ子要素を下記表に示す。 - -| 要素名 | 出現回数 | 説明 | -|---|---|---| -| [component](../../component/libraries/libraries-02-01-Repository-config.md#component-要素) | 0..* | List の要素とするコンポーネントを直接記述する。 | -| [component-ref](../../component/libraries/libraries-02-01-Repository-config.md#component-ref-要素) | 0..* | List の要素とする、この要素の外で定義したコンポーネントを指定する。 | -| [value](../../component/libraries/libraries-02-01-Repository-config.md#value-要素) | 0..* | List の要素とする文字列を指定する。 | - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| name | 登録する List のコンポーネント名。 | - -### component-ref 要素 - -List の要素となる、他に定義したコンポーネントを指定する。 - -この要素は子要素を持たない。 - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| name | List の要素とする、この要素の外で定義したコンポーネントのコンポーネント名を指定する。 | - -### value 要素 - -List の要素となる文字列を指定する。 -この要素に指定した内容が、そのまま List の要素となる。 - -文字列には、環境設定ファイルに記述した値の埋め込み機能が使用できる。 -埋め込みの方法は [環境設定ファイルに記述した値をコンポーネント設定ファイルで使用する](../../component/libraries/libraries-02-01-Repository-config.md#環境設定ファイルに記述した値をコンポーネント設定ファイルで使用する) を参照。 - -この要素は属性を持たない。 - -### map 要素 - -Map をコンポーネントとして定義する。 - -この要素が持つ子要素を下記表に示す。 - -| 要素名 | 出現回数 | 説明 | -|---|---|---| -| [entry](../../component/libraries/libraries-02-01-Repository-config.md#entry-要素) | 0..* | Map に含まれる Entry を定義する。 | - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| name | 登録する Map のコンポーネント名。 | - -### entry 要素 - -Map の Entry を定義する。 - -この要素には、 key属性、key-name属性、key-component要素、 のいずれか1つと value属性、value-name属性、value-component要素 のいずれか1つを必ず指定する。 - -この要素が持つ子要素を下記表に示す。 - -| 要素名 | 出現回数 | 説明 | -|---|---|---| -| [key-component](../../component/libraries/libraries-02-01-Repository-config.md#key-component-要素) | 0..1 | Entry のキーとなるコンポーネントを直接記述する。 | -| [value-component](../../component/libraries/libraries-02-01-Repository-config.md#value-component-要素) | 0..1 | Entry の値となるコンポーネントを直接記述する。 | - -この要素が持つ属性を下記表に示す。 - -| 属性名 | 説明 | -|---|---| -| key | Entry のキーとなる文字列を直接記述する。 文字列には、環境設定ファイルに記述した値の埋め込み機能が使用できる。 埋め込みの方法は [環境設定ファイルに記述した値をコンポーネント設定ファイルで使用する](../../component/libraries/libraries-02-01-Repository-config.md#環境設定ファイルに記述した値をコンポーネント設定ファイルで使用する) を参照。 | -| key-name | 要素の外で定義したコンポーネントのコンポーネント名を設定し、 そのコンポーネントを Entry のキーとして指定する。 | -| value | Entry の値となる文字列を直接記述する。 文字列には、環境設定ファイルに記述した値の埋め込み機能が使用できる。 埋め込みの方法は [環境設定ファイルに記述した値をコンポーネント設定ファイルで使用する](../../component/libraries/libraries-02-01-Repository-config.md#環境設定ファイルに記述した値をコンポーネント設定ファイルで使用する) を参照。 | -| value-name | 要素の外で定義したコンポーネントのコンポーネント名を設定し、 そのコンポーネントを Entry の値として指定する。 | - -### key-component 要素 - -Map の Entry のキーとなるコンポーネントを定義する。 - -この要素は、 [component](../../component/libraries/libraries-02-01-Repository-config.md#component-要素) と同じ子要素、属性を持つ。 - -### value-component 要素 - -Map の Entry の値となるコンポーネントを定義する。 - -この要素は、 [component](../../component/libraries/libraries-02-01-Repository-config.md#component-要素) と同じ子要素、属性を持つ。 diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-02-Repository-initialize.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-02-Repository-initialize.md deleted file mode 100644 index 90072fca4..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-02-Repository-initialize.md +++ /dev/null @@ -1,70 +0,0 @@ -## 初期化処理の使用手順 - -初期化処理を行うために必要な条件は下記の通りである。 - -1. Initializable インタフェースに定義された initialize メソッドに初期化時の処理を実装する。 -2. 1で作成したクラスをコンポーネントとしてDIコンテナに設定する。 -3. BasicApplicationInitializer のプロパティ initializeList に2で設定したコンポーネントを加える。 - -以下に使用方法の例を示す。 - -## 初期化対象クラスの定義 - -初期化対象クラスは、 Initializable インタフェースに定義された initialize メソッドを実装する。 -initializeメソッドには、コンポーネントに必要な初期化処理を実装する。 - -```java -// ******** 注意 ******** -// 下記のコードはプロジェクトのアーキテクトが作成するものである。 -// 通常、各アプリケーション・プログラマはこのような実装を行わない。 - -public class Message implements Initializable { - - // Initializableで定義されているinitializeメソッドを実装する。 - // 必要な初期化処理を本メソッド内ですべて実装する。 - public void initialize() { - - // 初期化処理を実行する。 - - } -} -``` - -## コンポーネント設定ファイルの定義 - -```xml - - - - - - - - - - - -``` - -## 設定項目 - -BasicApplicationInitializerの設定 - -| property名 | 設定内容 | -|---|---| -| initializeList | 初期化が必要となるコンポーネントのリスト。 BasicApplicationInitializer はこのリストの順序に従い初期化を実行する。 | - -> **Note:** -> コンポーネント名 Initializer として登録するコンポーネントは、 ApplicationInitializer インタフェースを -> 実装したクラスであれば、 BasicApplicationInitializer 以外のクラスでも初期化処理を実行できる。 -> BasicApplicationInitializer では対処できない初期化処理が必要となった場合、 ApplicationInitializer インタフェースを -> 実装したクラスを作成し、必要な初期化処理を実装すること。 diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-03-Repository-factory.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-03-Repository-factory.md deleted file mode 100644 index 5544fcf2d..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-03-Repository-factory.md +++ /dev/null @@ -1,48 +0,0 @@ -## ファクトリーインジェクションの使用手順 - -ファクトリーインジェクションを使用する際の手順は下記の通り。 - -1. ComponentFactory インタフェースを実装したクラス(ファクトリークラス)を作成する。 -2. 作成したファクトリークラスを通常のコンポーネントと同様にDIコンテナに登録する。 - -ComponentFactory インタフェースを実装したクラスをコンポーネントとしてコンポーネント設定ファイルに記述した場合、DIコンテナは -この設定を特別に扱い、 ComponentFactory インタフェースに定義された createObject メソッドで返されたオブジェクト -をコンポーネントとする。 - -実装例を下記に示す。 - -## ファクトリークラスの実装例 - -```java -// ******** 注意 ******** -// 下記のコードはプロジェクトのアーキテクトが作成するものである。 -// 通常、各アプリケーション・プログラマはこのような実装を行わない。 - -public class SampleComponentFactory implements ComponentFactory { - public SampleComponent createObject() { - // コンポーネントを生成する。 - // この例では単にクラスをnewして返しているが、フレームワーク外のソフトウェアに - // 含まれるクラスの場合は、クラスに必要な初期化処理をハードコーディングする。 - return new SampleComponent(); - } -} -``` - -## コンポーネント設定ファイル - -```xml - - - - - -``` - -## 使用例 - -```java -// "sampleComponent" を指定した場合、 SampleComponentFactory ではなく、 -// SampleComponent が取得できる。 -SampleComponent comp = (SampleComponent) SystemRepository.getObject("sampleComponent"); -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-04-Repository-override.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-04-Repository-override.md deleted file mode 100644 index d7e093049..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-04-Repository-override.md +++ /dev/null @@ -1,349 +0,0 @@ -## 設定値の上書きの対象 - -設定の上書きは、下記対象に対して実施できる。 - -1. 環境設定ファイルに記述した文字列の設定値 -2. コンポーネントのプロパティ -3. コンポーネントのクラス - -それぞれの設定値は、 XmlComponentDefinitionLoader クラスのコンストラクタに渡すコンポーネント設定ファイルを起点として、より後に記述した設定が優先される。 - -以下にそれぞれの対象ごとの設定方法と例を示す。 - -## 環境設定ファイルに記述した文字列の設定値の上書き - -環境設定ファイルに記述した設定値は、同じ設定名を2回以上設定ファイルに記述した場合に後に記述した設定で上書きされる。 -これは、単に同一設定ファイル内に記述した場合だけでなく、コンポーネント設定ファイルの config-file 要素で環境設定ファイルを読み込んだ場合でも同様の動作となる。 - -下記の test1.conf と test2.conf の2種類の環境設定ファイルをコンポーネント設定ファイルで読み込む場合を考える。 - -### 環境設定ファイル(test1.conf) - -```bash -test.message=test1 -``` - -### 環境設定ファイル(test2.conf) - -```bash -test.message=test2 -``` - -これら2つのファイルを下記のコンポーネント設定ファイルで読み込んだ場合、リポジトリから "test.message" をキーにして取得した設定値は test2.conf に記述した "test2" となる。 - -### コンポーネント設定ファイルを読み込む - -```xml - - - - -``` - -### 設定値の取得例 - -```java -// より後に設定が記述された test2.conf ファイルの設定値 "test2" が取得できる。 -String testMessage = SystemRepository.getString("test.message"); -``` - -## コンポーネントのプロパティの上書き - -同じコンポーネント名で別々にコンポーネントの定義を記述した場合、コンポーネント設定ファイルでより後に記述した設定が有効になる。 -これはベースとなる設定値を別のファイルで記述した設定で上書きするという用途を意図している。 -ただし、この動作が意図しないものであった場合を考慮し、上書きが発生した際はワーニングレベルのログ出力を行う。 - -上書き設定を行った場合のコンポーネント設定ファイルと実装例を下記に示す。 - -> **Note:** -> この例では説明のために上書きされる設定と上書きする設定を続けて記述しているが、 -> 本来設定上書きの機能は別のファイルに設定を記述して状況に応じてコンポーネント設定ファイルを -> 切り替えて使用する用途を想定している。 - -### 使用するクラス - -```java -public class OverrideExample { - - private String str1; - private String str2; - private String str3; - - // setter,getter は省略 -} -``` - -### コンポーネント設定ファイルの例 - -```xml - - - - - - - - - - - - - - -``` - -### 設定したコンポーネントの取得例 - -```java -// コンポーネントを取得 -OverrideExample overrideExample = (OverrideExample) SystemRepository.getObject("overrideExample"); - -// 上書きする前の "base value1" が出力される -System.out.println(overrideExample.getStr1()); -// 上書きされた "override value2" が出力される -System.out.println(overrideExample.getStr2()); -// 上書き設定で設定された "override value3" が出力される -System.out.println(overrideExample.getStr3()); -``` - -## コンポーネントのクラスの上書き - -コンポーネント設定ファイルに、同一のコンポーネント名で異なるクラスを登録した場合、より後に設定したクラスの設定が優先される。 -この上書きは、フレームワークがテスト時に使用するクラスを、実際のアプリケーションで使用するものからスタブに変更したい場合などに使用する。 - -スタブを用いたテストは、外部システム連携を行うクラスでしばしば必要になる。 -外部連携を行う RealConnectionService クラスをスタブによるテスト時のみ MockConnectionService クラスに置き換えるような用途であれば、 -下記のように読み込み元の設定ファイルとテスト用の設定ファイルを用意し、テスト時のみテスト用の設定ファイルが読み込まれるように配置すればよい。 - -### 読み込み元の設定ファイル - -```xml - - - - - - - - -``` - -### テスト用の設定ファイル(/opt/testconfig/testconfig.xml) - -```xml - - - - - - - -``` - -> **Note:** -> コンポーネントのクラスの上書きを行った場合、先に設定されたコンポーネントに設定したプロパティは上書きしたクラスのプロパティに反映されないため、注意すること。 -> これは、先に設定されたコンポーネントが持つプロパティを上書きしたクラスが持っていない可能性があるために発生した制約である。 - -## import 要素および config-file 要素による外部ファイル読み込み時の優先順位 - -import 要素や config-file 要素を使用して他のファイルの読み込みを行った場合、その属性の箇所にインポートしたファイルに記述した設定をそのまま展開した場合と同じ順序で設定の優先順位が決定する。 - -例えば下記の import-example1.xml と import-example2.xml は、onefile-example.xml と同様の順序で評価され、コンポーネント helloImport1 の value プロパティには -import-example2.xml に設定した "imported2" が設定される。 - -### import-example1.xml - -```xml - - - - - - - - -``` - -### import-example2.xml - -```xml - - - - - - - -``` - -### onefile-example.xml(import-example1.xml、import-example2.xmlと等価) - -```xml - - - - - - - - - - - - -``` - -## dir 属性を使用した読み込み時の優先順位 - -import 要素、config-file 要素の dir 属性を使用した読み込み [1] を使用した場合は、インポートするファイル名を java の文字列としてソートした順序で読み込まれる。 - -[ディレクトリに配置された設定ファイルの読み込み](../../component/libraries/libraries-02-01-Repository-config.md#ディレクトリに配置された設定ファイルの読み込み) を参照 - -例えば、 /opt/config/ ディレクトリ以下に下記のファイルが存在していた場合を考える。 - -/opt/config/ ディレクトリに存在するファイル - -* test1.xml -* test2.xml -* test3.xml -* environment.config - -この場合、下記2つの設定は等価となる。 - -```xml - - - - -``` - -```xml - - - - - - -``` - -## 設定値の上書き時の動作設定 - -設定値の上書きは、テストに便利であるなど利点がある反面、使用者が誤って行った設定値の上書きの検出が煩雑となる問題がある。 -このような場合を考慮し、DIコンテナは設定値の上書きが発生した際の動作を変更できる機能を持つ。 - -設定値の上書きを行った際の動作は、下記2通りを指定できる。 - -| 名称 | 説明 | -|---|---| -| OVERRIDE | 設定値を後に記述したもので上書きする。指定がない場合のデフォルト動作。 | -| DENY | 重複した設定を検出した際に例外を発生させる。 | - -通常この動作の変更は、 Web フレームワークやバッチフレームワークの起動時に行われるブートストラップ処理の設定で行う。 - -もしこれらブートストラップの処理以外で動作を変更したい場合、 XmlComponentDefinitionLoader のコンストラクタ2番目の引数を指定する。 - -例えば設定値の重複があった際に例外を発生には下記のように実装する。 - -### 設定をロードする際の実装例(通常フレームワークのブートストラップ処理で行う) - -```java -// ******** 注意 ******** -// 直下のコードはブートストラップ処理で行うべき処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -// XmlComponentDefinitionLoader のコンストラクタ第2引数に DuplicateDefinitionPolicy.DENY を指定 -XmlComponentDefinitionLoader loader = new XmlComponentDefinitionLoader( - "nablarch/core/repository/di/example/override/hello-override.xml", - DuplicateDefinitionPolicy.DENY); -try { - DiContainer container = new DiContainer(loader); - -} catch (ConfigurationLoadException e) { - // 重複した設定を行なった場合、例外が発生する。 - throw new RuntimeException("コンポーネント設定ファイルの読み込みに失敗しました。", e); -} -``` - -## システムプロパティによる設定値の上書き - -環境設定ファイルに記述する設定値は、前述の環境設定ファイルによる上書きの他に、 -java.lang.System.getProperties() メソッドで取得できるシステムプロパティによって上書きできる。 -システムプロパティによる上書きは、環境設定ファイルよりも優先されるため、実行時に環境設定ファイルを変更することなく動作を変更する際に使用できる。 - -以下に使用例を示す。 - -### 環境設定ファイル(hello-system-property.config) - -```bash -# この設定はシステムプロパティより優先されない -hello.message = This is property file hello message!! -``` - -### コンポーネント設定ファイル(hello-system-property.xml) - -```xml - - - - - - - - - - - - -``` - -### 設定値のロードの実装例 - -```java -// ******** 注意 ******** -// 直下のコードはブートストラップ処理で行うべき処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -// システムプロパティにキー"hello.message"でメッセージを設定 -System.setProperty("hello.message", "This is system property hello message!!"); - -XmlComponentDefinitionLoader loader = new XmlComponentDefinitionLoader( - "nablarch/core/repository/di/example/override/hello-system-property.xml"); -DiContainer container = new DiContainer(loader); -SystemRepository.load(container); -``` - -> **Note:** -> 例では説明のために java.lang.System.setProperty() を使用した方法を示しているが、実際に使用する際はjavaコマンドのオプション-Dによる -> 指定を用いて下記のように実行時のオプションとしてシステムプロパティを設定できる。 -> 環境設定ファイルを変更せずに動作確認を行う際は、通常この方法を使用する。 - -> ```bash -> > java -Dhello.message="value in system property" ... -> ``` - -### 設定したコンポーネントを取得する実装例 - -```java -// DIコンテナで "helloComponent" と名付けたコンポーネントを取得 -HelloComponent helloComponent = (HelloComponent) SystemRepository.getObject("helloComponent"); -// 環境設定ファイルに設定した "This is property file hello message!!" ではなく、 -// システムプロパティに設定を記述した "This is system property hello message!!" がコンソールに表示される -helloComponent.printHello(); -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-CodeManager.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-CodeManager.md deleted file mode 100644 index 64e069a52..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-CodeManager.md +++ /dev/null @@ -1,472 +0,0 @@ -# コード管理 - -## 概要 - -アプリケーションで使用するコード値、コード名称を管理する機能を提供する。 - -本機能では、例えば性別区分(1:男性、2:女性)や年代区分(01:10歳未満、02:10代、03:20代、04:30代、05:40代以上)のようなコードの値(コード値)とその意味を表わす文字列(コード名称)を容易に扱うための機能を提供する。 -性別区分や年代区分といったコードの種別は、コードIDと呼ぶIDを設定し、コードID毎に別々に定義する。 - -なお、一般にコードという名称には「商品コード」や「企業コード」といった、コード値に紐付く値が動的に変化する数多くのデータのキー値も含まれる。 -しかし本機能では、これらのコードは対象としない。これらのコードはアプリケーションでマスタ用のテーブルを作成し、対処する。 -また、本機能を使用する場合、コードの名称を持つテーブルとコード値を持つテーブルにRDBMSの参照整合性制約を設定できない。 -このような制約のチェックには [コード値の有効性をチェックするバリデーション](../../component/libraries/libraries-02-CodeManager.md#コード値の有効性をチェックするバリデーション) を使用すること。 - -本機能は、あくまで先に示した性別区分や年代区分など、コードに含まれるコード値とコード名称の関係が静的なコードのみに使用すること。 - -本機能は、リポジトリに登録して使用する。 -このため、本機能に必要な初期化処理は [リポジトリ](../../component/libraries/libraries-02-Repository.md#リポジトリ) が実行する。 - -アプリケーションプログラマは、本機能を画面表示に使用するコード名称の取得と、コード値の取得に使用する。 - -## 特徴 - -### 国際化 - -国際化対応が必要なアプリケーションでは、言語ごとに異なる名称が取得できる。 - -### パターン指定によるコード値の取得 - -アプリケーションで使用するコード値のうち、一部のコード値のみを取得するパターン指定によるコード値の取得ができる。 -この機能によって、コード値の入力チェックや特定のコード値のみを表示するコンボボックスを容易に作成できる。 - -### 高速なコードへのアクセス - -本機能では、コード値とコード名称を [静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md#静的データのキャッシュ) の機能を使用してキャッシュする。 -このため、データベース上に保持しているコード値のデータを何度もロードすることがなく、アプリケーションの動作を高速化できる。 - -また、 [静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md#静的データのキャッシュ) の機能を使用しているため、 -キャッシュにデータをロードするタイミングを設定変更のみで変更できる。 -この機能により、下記例のようにアプリケーションの特性に合わせてキャッシュにデータをロードするタイミングを選択できる。 - -キャッシュをロードするタイミングの選択例 - -| アプリケーションの種類 | キャッシュにデータをロードするタイミング | -|---|---| -| Web アプリケーション | 一括ロードを使用 ※アプリケーション起動中にほぼ全てのコードが使用されるため | -| バッチアプリケーション | オンデマンドロードを使用 ※処理過程で全てのコードを使用しないため | - -> **Note:** -> [概要](../../component/libraries/libraries-02-CodeManager.md#概要) で述べた通り、本機能は「コード値とコード名称の関係が静的なコード」を前提として設計、実装している。 - -> この前提では、コード値の意味が変更された際には、アプリケーションにもなんらかの修正が必要となると想定されるため、 -> 本機能ではアプリケーションを再起動せずにコードのキャッシュをリロードすることが想定されていない。 - -> しかし、 [静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md#静的データのキャッシュ) にはキャッシュをリロードする機能が実装されており、実際にはキャッシュのリロードが可能である。 -> このリロードの使用は、プロジェクトの責任で行うこと。 - -## 要求 - -### 実装済み - -* 国際化ができる。 -* コード値に対応するコード名称が取得できる。 -* 1つのコード値に対して、複数のコード名称が取得できる。 -* コードIDに対応するコード値を全て取得できる。 -* 文字列がコード値として妥当であるかチェックできる。 -* コードが使われるパターンに応じて、そのパターンで使用できるコードを取得する、パターン指定によるコード値の取得ができる。 -* コード値がパターンに含まれるかチェックできる。 - -### 未検討 - -* 外部システム用にコード変換できる。(自システムのコード値⇔外部システムのコード値ができる機能) -* コード値の有効期限を管理できる。 - -## 構造 - -### クラス図 - -![02_CodeManager_ClassDiagram.jpg](../../../knowledge/assets/libraries-02-CodeManager/02_CodeManager_ClassDiagram.jpg) - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.common.code.CodeManager | コードの値と名称を取り扱うインタフェース。 コード値、コード名称を取得するメソッドとコード値の存在チェックを行うメソッドを持つ。 | -| nablarch.common.code.Code | 単一のコードデータ(コードIDに紐づくデータ)にアクセスするインタフェース。 | - -#### クラス定義 - -| クラス名 | 概要 | -|---|---| -| nablarch.common.code.BasicCodeManager | コードの値と名称を取り扱うクラス。 | -| nablarch.common.code.BasicCodeLoader | データベースからコードをロードするクラス。 | -| nablarch.common.code.BasicCode | Codeの基本実装クラス。 BasicCodeLoaderの内部クラスとして実現する。 | -| nablarch.common.code.CodeUtil | コードの値と名称の取り扱いに使用するユーティリティクラス。 | - -### テーブル定義 - -本機能では、コード値と名称のマスタはデータベースのテーブル上に持つ。 -データベースのテーブルは、コードの値とパターンを持つコードパターンテーブルとコード名称を持つコード名称テーブルから成る。 -これらテーブルのテーブル名およびカラム名には制約はなく、設定により任意の名称が使用できる。 - -#### コードパターンテーブルの定義 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| コードID | java.lang.String | ユニークキー | -| コード値 | java.lang.String | ユニークキー | -| パターン [1] | java.lang.String | パターンに含める場合 "1" 、含めない場合 "0" を設定する。 | - -パターンに使用するカラム名は任意に設定可能であり、プロジェクトで必要な数だけパターンを定義できる。 -複数のパターンを使用する場合、パターンの数だけ別々のカラム名でパターンカラムをテーブルに持たせることになる。 - -#### コード名称テーブルの定義 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| コードID | java.lang.String | ユニークキー | -| コード値 | java.lang.String | ユニークキー | -| 言語 | java.lang.String | ユニークキー | -| ソート順 | java.lang.String | | -| 名称 | java.lang.String | コードの名称 | -| 略称 | java.lang.String | コードの略称 | -| オプション名称 [2] | java.lang.String | コードのオプション名称 | - -コードのオプション名称は、1つのコード値に対して複数持つことができる。 -1つのコード値に対して持つことのできるオプション名称の数は、任意に設定できる。 -また、オプション名称を設定するカラムの名称も任意のカラム名が使用できる。 - -#### テーブル定義の例 - -以下にテーブル定義の例を示す。 - -この例では、1つのコードIDごとに取得できるパターンの数を3種類設定している。 -コード名称には、名称を NAME 、略称 を SHORT_NAME のカラムに持ち、さらにコード名称にコード値を含めた NAME_WITH_VALUE というオプション名称のカラムを持つ。 - -![02_CodeManager_DatabaseDiagram.jpg](../../../knowledge/assets/libraries-02-CodeManager/02_CodeManager_DatabaseDiagram.jpg) - -## コード値とコード名称のデータ - -以下にコード値とコード名称のデータ保持の例を示す。 - -例えば、性別の区分(性別区分)を表すコードID "0001" のコードと、バッチの処理状態を表すコードID "0002" のコードを考える。 - -これら2つのコードを [テーブル定義の例](../../component/libraries/libraries-02-CodeManager.md#テーブル定義の例) で示したテーブルで保持する場合、下記のようにデータを作成する。 - -CODE_PATTERN テーブルのデータ例 - -| ID | VALUE | PATTERN1 | PATTERN2 | PATTERN3 | -|---|---|---|---|---| -| 0001 | 1 | 1 | 0 | 0 | -| 0001 | 2 | 1 | 0 | 0 | -| 0001 | 9 | 0 | 0 | 0 | -| 0002 | 01 | 1 | 0 | 0 | -| 0002 | 02 | 1 | 0 | 0 | -| 0002 | 03 | 0 | 1 | 0 | -| 0002 | 04 | 0 | 1 | 0 | -| 0002 | 05 | 1 | 0 | 0 | - -CODE_NAME テーブルのデータ例 - -| ID | VALUE | SORT_ORDER | LANG | NAME | SHORT_NAME | NAME_WITH_VALUE | -|---|---|---|---|---|---|---| -| 0001 | 1 | 1 | ja | 男性 | 男 | 1:男性 | -| 0001 | 2 | 2 | ja | 女性 | 女 | 2:女性 | -| 0001 | 9 | 3 | ja | 不明 | 不 | 9:不明 | -| 0002 | 01 | 1 | ja | 初期状態 | 初期 | | -| 0002 | 02 | 2 | ja | 処理開始待ち | 待ち | | -| 0002 | 03 | 3 | ja | 処理実行中 | 実行 | | -| 0002 | 04 | 4 | ja | 処理実行完了 | 完了 | | -| 0002 | 05 | 5 | ja | 処理結果確認完了 | 確認 | | -| 0001 | 1 | 2 | en | Male | M | 1:Male | -| 0001 | 2 | 1 | en | Female | F | 2:Female | -| 0001 | 9 | 3 | en | Unknown | U | 9:Unknown | -| 0002 | 01 | 1 | en | Initial State | Initial | | -| 0002 | 02 | 2 | en | Waiting For Batch Start | Waiting | | -| 0002 | 03 | 3 | en | Batch Running | Running | | -| 0002 | 04 | 4 | en | Batch Execute Completed Checked | Completed | | -| 0002 | 05 | 5 | en | Batch Result Checked | Checked | | - -以降の実装例では、上記データがテーブルに入っていることを前提にして説明する。 - -## コード名称の取得 - -コード名称は、CodeUtilのgetNameメソッドで取得できる。 - -例えば [コード値とコード名称のデータ](../../component/libraries/libraries-02-CodeManager.md#コード値とコード名称のデータ) で設定した性別区分に対応するコード名称を取得する場合、下記のように実装する。 - -```java -// 性別区分(コードID:0001)、コード値 "1"に対応する文字列を取得する。 -// ThreadContextに持つ言語によって、 "男性" または "Male" が取得できる。 -String maleDisplayName = CodeUtil.getName("0001", "1"); - -// 言語を指定して 性別区分(コードID:0001)のコード値 "1"に対応する文字列を取得する。 -// "男性" が取得できる。 -String japaneseMaleDisplayName = CodeUtil.getName("0001", "1", Locale.JAPANESE); -``` - -コード名称を画面表示する際は、詳細画面では完全な名称、一覧画面では略称で表示することがある。 - -このように使用する箇所に応じてコード値の表示を変更するために、本機能では1つのコード値に対して複数のコード名称を持たせることができる。 -これらのコード名称の別名を取得するため、 CodeUtil には getName 以外にコードの略称を取得するメソッドとコードのオプション名称を取得するメソッドを持つ。 -これらメソッドの使用例を下記に示す。 - -```java -// コード略称を取得する。 -// ThreadContextに持つ言語によって、 "男" または "M" が取得できる。 -String shortMaleDisplayName = CodeUtil.getShortName("0001", "1"); - -// コードのオプション名称を取得する。 -// ThreadContextに持つ言語によって、 "1:男性" または "1:Male" が取得できる。 -String shortMaleDisplayName = CodeUtil.getOptionalName("0001", "1", "NAME_WITH_VALUE"); -``` - -名称を取得するメソッドの一覧は下記の通り。 - -| メソッド名 | 説明 | -|---|---| -| getName | コード名称を取得する。 | -| getShortName | コードの略称を取得する。 | -| getOptionalName | コードのオプション名称を取得する。 取得するオプション名称のカラムは、このメソッドの第3引数で指定する。 | - -## コード値の取得 - -コードが取り得る全てのコード値は、CodeUtilの下記メソッドで取得できる。 - -* getValues(String codeId) -* getValues(String codeId, Locale locale) - -上記メソッドで取得したコード値の配列は、コード名称テーブルのソート順カラムとして設定したカラム(この例では SORT_ORDER カラム) -の昇順でソートされた順序で取得できる。 -ソート順をコード名称テーブルに持つため、例えば言語ごとのコード名称の表示名にあわせてソートを行うことができる。 -この機能を使用することで、例えば国名を選択する場面で、日本語では「アメリカ」「カナダ」「日本」とアイウエオ順で表示し、 -英語では「Canada」「Japan」「United States」のようにアルファベット順に表示するという表示の変更ができる。 - -例えば [コード値とコード名称のデータ](../../component/libraries/libraries-02-CodeManager.md#コード値とコード名称のデータ) で設定した性別区分とバッチの処理状態を意味するコード値を取得する場合、下記のように実装する。 - -```java -// 性別区分(コードID:0001) に対応するコード値を全て取得する。 -// ThreadContextに持つ言語によって、{"1", "2", "9" } または {"2", "1", "9"} の文字列のリストが取得できる。 -List genderCodeValues = CodeUtil.getValues("0001"); - -// バッチの処理状態(コードID:0002) に対応するコード値を全て取得する。 -// "01" 、 "02" 、 "03" 、 "04" 、 "05" の文字列のリストが取得できる。 -List executionStateCodeValues = CodeUtil.getValues("0002"); -``` - -## コード値の有効性チェック - -画面やバッチ処理におけるファイルからの入力では、コード値として有効であるかチェックする必要がある。 -このようなチェックは CodeUtil の contains メソッドで行える。 - -例えば [コード値とコード名称のデータ](../../component/libraries/libraries-02-CodeManager.md#コード値とコード名称のデータ) で設定した性別区分として有効であるかチェックする場合、下記のようにコードが有効であるかチェックできる。 - -```java -// 性別区分(コードID:0001) のコード値として有効であるかどうかチェックする - -// 性別区分として、 "1" は有効であるため、true -CodeUtil.contains("0001", "1"); - -// 性別区分として、 "3" は有効でないため、false -CodeUtil.contains("0001", "3"); -``` - -## コード値のパターン - -[コード値とコード名称のデータ](../../component/libraries/libraries-02-CodeManager.md#コード値とコード名称のデータ) のデータの例で示した、コードID 0001 の性別区分のうち、コード値 "9" -(不明)は外部システムから入力したデータに性別区分がなかった場合に使用する特殊なコード値を表わしている。 -このコード値は、画面から入力してほしくない。 - -本機能では、このようなケースのために、コード値の集合に「パターン」を設定し、パターンに含まれるコード値の集合のみを取得する機能を持つ。 -例えば上記の性別区分の例では、全てのコード値（1:男性、2:女性、9:不明） のうち、画面入力に使用するコード値のみを集めたパターン1(1:男性、2:女性) を用意している。 - -パターンに含まれるコード値のみを取得するには、 CodeUtilの下記メソッドを使用する。 -pattern引数には、使用するパターンのカラム名を指定する。 - -* getValues(String codeId, String pattern) -* getValues(String codeId, String pattern, Locale locale) - -下記に実装例を示す。 - -```java -// 性別区分(コードID:0001) のコード値のうち、 "PATTERN1" に対応するコード値を取得する。 -// ThreadContextに持つ言語によって、 {"1" , "2"} または {"2" , "1"} の文字列のリストが取得できる。 -List executionStateCodeValues = CodeUtil.getValues("0001", "PATTERN1"); -``` - -また、パターンに対して有効であるかチェックするために、containsメソッドにもパターンが指定できる。 -下記に例を示す。 - -```java -// 性別区分(コードID:0001) のコード値として有効であるかどうかチェックする - -// 性別区分のうち、 "1" は "PATTERN1" で有効であるため、 true が取得できる。 -CodeUtil.contains("0001", "1", "PATTERN1"); - -// 性別区分として、 "3" は "PATTERN1" で有効でないため、 false が取得できる。 -CodeUtil.contains("0001", "3", "PATTERN1"); -``` - -## 設定方法 - -### 設定ファイル例 - -コード管理を使用する際は、リポジトリに "codeManager" というコンポーネント名で CodeManager インタフェースを実装したクラスを登録する必要がある。 - -以下に CodeManager インタフェースのデフォルト実装である、BasicCodeManagerクラスを使用した設定例を示す。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -### 設定内容詳細 - -#### nablarch.common.code.BasicCodeManager の設定 - -| property名 | 設定内容 | -|---|---| -| codeDefinitionCache(必須) | Code インタフェースを実装したクラスを保持する StaticDataCache を設定する。 | - -#### nablarch.core.cache.BasicStaticDataCache クラスの設定 - -[静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md) を参照。 - -> **Warning:** -> このプロパティに設定する StaticDataLoader は、 BasicCodeLoader クラスのように、 StaticDataLoader を実装すること。 - -#### nablarch.common.code.BasicCodeLoader クラスの設定 - -| property名 | 設定内容 | -|---|---| -| dbManager(必須) | コードのロード時に使用する SimpleDbTransactionManager クラスを指定する。 | -| codePatternSchema(必須) | コードパターンテーブルのスキーマ情報。 CodePatternSchema クラスのインスタンス。 | -| codeNameSchema(必須) | コード名称テーブルのスキーマ情報。 CodeNameSchema クラスのインスタンス。 | - -#### nablarch.common.code.schema.CodePatternSchema クラスの設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| idColumnName(必須) | コードIDカラムの名前。 | -| valueColumnName(必須) | コード値カラムの名前。 | -| patternColumnNames | パターンに使用するカラム名の文字列を配列で設定する。 パターン機能を使用する場合、設定必須。 | - -#### nablarch.common.code.schema.CodeNameSchema クラスの設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| idColumnName(必須) | コードIDカラムの名前。 | -| valueColumnName(必須) | コード値カラムの名前。 | -| langColumnName(必須) | 言語カラムの名前。 | -| sortOrderColumnName(必須) | ソート順カラムの名前。 | -| nameColumnName(必須) | 名称カラムの名前。 | -| shortNameColumnName(必須) | 略称カラムの名前。 | -| optionNameColumnNames | コードのオプション名称に使用するカラム名の文字列を配列で設定する。 指定しなかった場合、オプション名称が取得ができない。 | - -## コード値の有効性をチェックするバリデーション - -性別区分等、データベース上に永続化するコード値は、通常の文字列による画面入力値と同様にバリデーションを行う必要がある。 -本機能では [バリデーションの機能](../../component/libraries/libraries-core-library-validation.md#入力値のバリデーション) を使用して、コード値が有効であるか(つまり contains メソッドの戻り値が true であるか)をチェックする機能を持つ。 - -### エンティティの実装 - -バリデーションは、通常のバリデーション同様にEntityのプロパティに対してアノテーションを付けることで実現できる。 - -例えば、コードID "0001"、パターン "PATTERN1" に含まれる文字列のみを受けつけるプロパティ gender を持つエンティティは下記のように実装する。 -pattern属性には、使用するパターンのカラム名を指定する。 - -```java -public class Customer { - - // その他のプロパティは省略 - private String gender; - - @PropertyName("性別") - @CodeValue(codeId="0001", pattern="PATTERN1") - public String setGender(String gender) { - this.gender = gender; - } -} -``` - -上記実装を行った上で、 [バリデーションの実行と入力値の変換](../../component/libraries/libraries-08-02-validation-usage.md#バリデーションの実行と入力値の変換) で記述した方法で ValidationUtil クラスの validateAndConvertRequest メソッドを呼び出すことで、 gender に "1", -"2"以外の文字を設定した際のバリデーション結果はエラーになる。 - -なお、上記例はパターンに含まれるかまでをチェックするバリデーションであるため、 @CodeValue アノテーションの pattern 属性を指定しているが、 pattern 属性の指定を省略することで、 -コード値として有効であるかのみチェックするバリデーションも実装できる。 - -### Validatorの設定 - -@CodeValue アノテーションで指定されたコード値のチェックは、 CodeValueValidator クラス が行う。 - -CodeValueValidator クラス は、 [バリデーションの設定](../../component/libraries/libraries-08-01-validation-architecture.md#設定例) で記述した他のバリデータと同様に ValidationManager クラスの validators プロパティに追加することで使用できる。 -設定例を以下に示す。 - -```xml - - - - - - - - - - - - -``` - -### 設定内容詳細 - -CodeValueValidator の設定値の意味は下記の通り。 - -| property名 | 設定内容 | -|---|---| -| messageId(必須) | コード値のパターンに含まれない文字列が入力された場合のデフォルトのエラーメッセージのメッセージIDを設定する。 メッセージに使用できる置き換え文字は下記の通り。 * 0 : 設定するプロパティの名称 * 1 : 使用できるコード値の一覧 メッセージの例 : "{0}には'{'{1}'}'のいずれかの値を指定してください。" フォーマット後のメッセージの例 : "性別には{"01" , "02"}のいずれかの値を指定してください。" ※本メッセージはコンボボックスで入力するコードをを改竄した場合と、テキストボックスでコード値を入力する場合 (コードの性質上、テキストで入力することは非常にまれである) という特殊なケースでのみ使用される。 メッセージはこの使用状況を考慮して設計すること。 | diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-Repository.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-Repository.md deleted file mode 100644 index e470633c3..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-Repository.md +++ /dev/null @@ -1,142 +0,0 @@ -# リポジトリ - -## 概要 - -本フレームワークでは、設定値や、フレームワークで提供しているクラスのインスタンスなど、 -アプリケーションを実装する際に様々な箇所で使用されるオブジェクトを保持する入れ物をリポジトリと呼ぶ。 - -本フレームワークでは、適用されるプロジェクトや環境毎に異なる可能性のあるロジック（生成されるクラス、フィールドの値）を、 -本機能を使用して外部ファイルに記述した設定通りにセットアップする。 - -リポジトリを使用すれば、リポジトリに保持した設定値やコンポーネントが提供する機能を、アプリケーションのあらゆる箇所で使用できる。 - -コンポーネントは通常、単独のオブジェクトとしてリポジトリに登録されるのではなく、特定の目的を果すために複数の -コンポーネント間で関連を持つ必要がある。 -このコンポーネント間の関連を構築するため、リポジトリはDIコンテナの機能を持つ。 - -本機能を使用する際は初期化処理の呼び出しが必要となる。 -この初期化処理は、フレームワークの他の機能が行う。 -Web アプリケーションでは、 [Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md#nablarchサーブレットコンテキスト初期化リスナ) により初期化が行われる。 - -アプリケーションプログラマは、本機能を環境設定の取得に使用する。 -環境設定の取得方法は、 [環境設定の取得](../../component/libraries/libraries-02-01-Repository-config.md#環境設定の取得) に記述する。 - -## 特徴 - -### DIコンテナによるコンポーネントの構築 - -本機能では、コンポーネント間の関連を構築するために、下記DIコンテナの機能を使用できる。 - -* セッタインジェクションおよびフィールドインジェクション -* 環境依存する設定項目の集約 -* 下記プロパティの簡易設定 - - * 文字列 - * boolean型 - * int型、long型の数値 - * 文字列配列 -* インタフェースによる自動インジェクション -* プロパティ名による自動インジェクション - -### リポジトリとDIコンテナの分離 - -SpringFrameworkのような他のDIコンテナの実装を使用した場合にも、本フレームワークおよびリポジトリの機能を使用できるよう、DIコンテナの機能とリポジトリの機能を分離して実装している。 - -### DIコンテナに登録したコンポーネントの初期化機能 - -DIコンテナは、コンポーネントに必要なプロパティを設定する機能を提供している。 -しかし、コンポーネントによってはプロパティ設定後に独自の初期化処理が必要となる。 -本機能では、これらのコンポーネントの初期化処理を行う機能を提供する。 - -また、コンポーネントの依存関係によって、初期化処理に順序の制約が発生することを考慮し、 -初期化機能はコンポーネントの初期化順序を指定できるよう考慮している。 - -初期化機能の詳細は、 [初期化処理の使用手順](../../component/libraries/libraries-02-02-Repository-initialize.md#初期化処理の使用手順) に記述する。 - -## 要求 - -### 実装済み - -* ビジネスロジックのあらゆる箇所で設定値およびコンポーネントを取得できる。 -* ファイルから設定値を読み込める。 -* ディレクトリを指定して、そのディレクトリ以下にあるファイルをまとめて読み込める。 -* 設定値を機能あるいは方式ごとに複数ファイルに分割して定義できる。 -* 環境依存項目を設定ファイル(環境設定ファイル)に記述できる。 -* 設定値をJava起動オプション(-Dオプション）の値で上書きできる。 -* コンポーネント設定ファイルに記述した定義を元に、インスタンス間の関連を生成するDIが使用できる。 -* DIの実行時、プロパティに一致する型のインスタンスを自動的に設定できる。 -* OSSやサードパーティ製品のクラスをDIコンテナ上に作成するため、ファクトリインジェクションの機能を提供する。 -* 複数のコンポーネント設定ファイルに設定を記述する際、同じ設定名を使用することで設定値を上書きできる。 -* 設定名が重複した際、例外を送出するかワーニングログを出力するかの振る舞いを選択できる。 -* DIコンテナに登録したクラスの初期化処理が実行できる。 -* DIコンテナを変更できる。 - -### 未検討 - -* アプリケーションを停止することなく、設定の変更を反映できる。 -* バイナリデータを設定できる。 - - 暗号化鍵のようなバイナリデータを設定できる。 - -## 構成 - -### クラス図 - -![02_Repository_ClassDiagram.jpg](../../../knowledge/assets/libraries-02-Repository/02_Repository_ClassDiagram.jpg) - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.repository.ObjectLoader | SystemRepositoryに保持するオブジェクトを読み込むインタフェース。 | -| nablarch.core.repository.di.ComponentDefinitionLoader | コンポーネントの定義を読み込むインタフェース。 | -| nablarch.core.repository.initialization.ApplicationInitializer | コンポーネントの初期化を行うインタフェース。 | -| nablarch.core.repository.initialization.Initializable | 初期化処理を行うインタフェース。 | -| nablarch.core.repository.initialization.ComponentFactory | コンポーネントの作成を行うインタフェース。 FactoryInjectionの機能で使用する。 | - -#### クラス定義 - -| クラス名 | 概要 | -|---|---| -| nablarch.core.repository.SystemRepository | 設定値およびコンポーネントを保持するクラス。 | -| nablarch.core.repository.ConfigFileLoader | 環境設定ファイルから文字列の設定値を読み込むクラス。 | -| nablarch.core.repository.di.DiContainer | DIコンテナの機能を実現するクラス。 コンポーネントを生成する責務を持つ。 また、他のObjectLoaderが読み出した設定値を読み込む機能も持つ。 | -| nablarch.core.repository.di.ComponentDefinition | DiContainerがコンポーネントの生成に使用する定義を保持するクラス。 | -| nablarch.core.repository.di.config.xml.XmlComponentDefinitionLoader | XMLファイルからコンポーネントの定義を読み込むクラス。 | -| nablarch.core.repository.initialization.BasicApplicationInitializer | Initializableを実装したコンポーネントを指定した順序で初期化するクラス。 | - -## リポジトリの設定方法と使用方法 - -基本的にリポジトリは、設定ファイルに記載した内容を元にフレームワークが初期化を行うことで使用できるようになる。 -これら設定ファイルの記述方法と、リポジトリから設定値またはコンポーネントを取得する方法について下記に記述する。 - -02/02_01_Repository_config - -## コンポーネント初期化機能 - -[DIコンテナに登録したコンポーネントの初期化機能](../../component/libraries/libraries-02-Repository.md#diコンテナに登録したコンポーネントの初期化機能) で述べた通り、DIコンテナは、コンポーネントに必要な初期化処理を行うコンポーネント初期化機能を提供する。 - -コンポーネント初期化機能の詳細について下記に記述する。 - -02/02_02_Repository_initialize - -## ファクトリインジェクション - -フレームワーク外のソフトウェアに含まれるクラスを、コンポーネントとして使用したいことがある。 -これらのクラスが Java Beans として実装されていない場合、通常のリポジトリの設定では使用できない。 - -このような場合でも、ファクトリインジェクションを使用することで、これらのクラスをコンポーネントとして取り扱うことができる。 - -ファクトリインジェクションの詳細について、下記に記述する。 - -02/02_03_Repository_factory - -## 設定の上書き - -作成したアプリケーションをテストする際には、一部機能をスタブにして実行するなど、 -本番環境向けの設定の一部を変更してテストを実施したいことがある。 -このような場合を考慮し、本機能では一部設定のみを上書きしてテストを実行する機能を提供している。 - -設定の上書き方法について、下記に記述する。 - -02/02_04_Repository_override diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-SqlLog.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-SqlLog.md deleted file mode 100644 index 3cd4c2821..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-02-SqlLog.md +++ /dev/null @@ -1,479 +0,0 @@ -# SQLログの出力 - -SQLログは、パフォーマンスチューニングに使用するために、SQL文の実行時間やSQL文を出力する。 -アプリケーションでは、ログ出力の設定を行うことにより出力する。 - -## SQLログの出力方針 - -SQLログで想定している出力方針を下記に示す。 -SQLログは、開発時の使用を想定しているためDEBUGレベル以下で出力する。 - -| ログレベル | ロガー名 | -|---|---| -| DEBUG、TRACE | SQL | - -ログレベルと出力内容を下記に示す。 - -| ログレベル | 出力内容 | -|---|---| -| DEBUG | SQL文、実行時間、 件数(検索件数や更新件数など)、 トランザクションの処理結果(コミット又はロールバック) | -| TRACE | SQLパラメータ(バインド変数の値) | - -上記出力方針に対するログ出力の設定例を下記に示す。 - -log.propertiesの設定例 - -```bash -# SQL -loggers.SQL.nameRegex=SQL -loggers.SQL.level=TRACE -loggers.SQL.writerNames=<出力先のログライタ> -``` - -## SQLログの出力項目 - -SQLログの個別項目を下記に示す。 -SQLログは、SQL文を発行する方法に応じて出力項目が異なる。 - -ここでは、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) の設定で指定できる共通項目については省略する。 -共通項目と個別項目を組み合わせたフォーマットについては、 [各種ログの共通項目のフォーマット](../../component/libraries/libraries-01-Log.md#各種ログの共通項目のフォーマット) を参照。 - -### SqlPStatement#retrieveメソッドの検索開始時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| SQL文 | SQL文。 | -| 取得開始位置 | 検索結果のデータ取得を開始する行数。 | -| 取得最大件数 | 検索結果に含める最大行数。 | -| タイムアウト時間 | 検索のタイムアウト時間。 | -| フェッチする行数 | データ取得時のフェッチ件数。 | -| 付加情報 | BasicSqlPStatementの設定で指定された付加情報。 | - -### SqlPStatement#retrieveメソッドの検索終了時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| 実行時間 | 実行時間。 | -| データ取得時間 | 検索後のデータ取得に要した時間。 | -| 検索件数 | 検索結果の件数。 | - -### SqlPStatement#executeメソッドの実行開始時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| SQL文 | SQL文。 | -| 付加情報 | BasicSqlPStatementの設定で指定された付加情報。 | - -### SqlPStatement#executeメソッドの実行終了時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| 実行時間 | 実行時間。 | - -### SqlPStatement#executeQueryメソッドの検索開始時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| SQL文 | SQL文。 | -| 付加情報 | BasicSqlPStatementの設定で指定された付加情報。 | - -### SqlPStatement#executeQueryメソッドの検索終了時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| 実行時間 | 検索の実行時間。 | - -### SqlPStatement#executeUpdateメソッドの更新開始時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| SQL文 | SQL文。 | -| 付加情報 | BasicSqlPStatementの設定で指定された付加情報。 | - -### SqlPStatement#executeUpdateメソッドの更新終了時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| 実行時間 | 実行時間。 | -| 更新件数 | 更新件数。 | - -### SqlPStatement#executeBatchメソッドの更新開始時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| SQL文 | SQL文。 | -| 付加情報 | BasicSqlPStatementの設定で指定された付加情報。 | - -### SqlPStatement#executeBatchメソッドの更新終了時 - -出力項目 - -| 項目名 | 説明 | -|---|---| -| メソッド名 | クラス名#メソッド名形式。 | -| 実行時間 | 実行時間。 | -| バッチ件数 | バッチ件数。 | - -## SQLログの出力方法 - -SQLログの出力に使用するクラスを下記に示す。 - -![Log_SqlLog_ClassDiagram.jpg](../../../knowledge/assets/libraries-02-SqlLog/Log_SqlLog_ClassDiagram.jpg) - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statement.SqlLogUtil | SQLログのフォーマットを助けるクラス。 | -| nablarch.core.db.statement.SqlLogFormatter | SQLログの個別項目をフォーマットするクラス。 | - -BasicSqlPStatementは、SQL文、実行時間、件数のフォーマットにSqlLogUtilを使用する。 -トランザクションの処理結果とSQLパラメータの出力では、SqlLogUtilを使用せずに直接Loggerを使用して出力する。 - -SQLログは、ログ出力の設定でロガー名にSQLを指定することで出力される。 -ログ出力の設定を下記に示す。 - -log.propertiesの設定例 - -```bash -# SQL -loggers.SQL.nameRegex=SQL -loggers.SQL.level=TRACE -loggers.SQL.writerNames=<出力先のログライタ> -``` - -SQLログの出力例を下記に示す。SQLログの個別項目は、デフォルトのフォーマットを使用した場合の出力例である。 - -log.propertiesの設定例 - -```bash -writerNames=appFile - -# appFile -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=./app.log -writer.appFile.encoding=UTF-8 -writer.appFile.maxFileSize=10000 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=$date$ -$logLevel$- R[$requestId$] U[$userId$] E[$executionId$] $message$ - -availableLoggersNamesOrder=SQL - -# SQL -loggers.SQL.nameRegex=SQL -loggers.SQL.level=TRACE -loggers.SQL.writerNames=appFile -``` - -ログの出力例 - -```bash -2011-02-08 23:07:25.182 -DEBUG- R[LOGIN00102] U[9999999999] E[AP01201102082307249470003] nablarch.core.db.statement.BasicSqlPStatement#retrieve - SQL = [SELECT BIZ_DATE FROM BUSINESS_DATE WHERE SEGMENT = ?] - start_position = [1] size = [0] - query_timeout = [0] fetch_size = [500] - additional_info: -2011-02-08 23:07:25.182 -TRACE- R[LOGIN00102] U[9999999999] E[AP01201102082307249470003] nablarch.core.db.statement.BasicSqlPStatement#Parameters - 01 = [00] -2011-02-08 23:07:25.182 -DEBUG- R[LOGIN00102] U[9999999999] E[AP01201102082307249470003] nablarch.core.db.statement.BasicSqlPStatement#retrieve - execute_time(ms) = [0] retrieve_time(ms) = [0] count = [1] -``` - -SqlLogUtilは、プロパティファイル(app-log.properties)を読み込み、 -SqlLogFormatterオブジェクトを生成して、個別項目のフォーマット処理を委譲する。 -プロパティファイルのパス指定や実行時の変更方法は、 [各種ログの設定](../../component/libraries/libraries-01-Log.md#各種ログの設定) を参照。 - -SQLログの設定例を下記に示す。 - -app-log.propertiesの設定例 - -```bash -# SqlLogFormatter -sqlLogFormatter.className=nablarch.core.db.statement.SqlLogFormatter -sqlLogFormatter.startRetrieveFormat=$methodName$\n\tSQL:$sql$\n\tstart:$startPosition$ size:$size$\n\tadditional_info:\n\t$additionalInfo$ -sqlLogFormatter.endRetrieveFormat=$methodName$\n\texe:$executeTime$ms ret:$retrieveTime$ms count:$count$ -sqlLogFormatter.startExecuteFormat=$methodName$\n\tSQL:$sql$\n\tadditional_info:\n\t$additionalInfo$ -sqlLogFormatter.endExecuteFormat=$methodName$\n\texe:$executeTime$ms -sqlLogFormatter.startExecuteQueryFormat=$methodName$\n\tSQL:$sql$\n\tadditional_info:\n\t$additionalInfo$ -sqlLogFormatter.endExecuteQueryFormat=$methodName$\n\texe:$executeTime$ms -sqlLogFormatter.startExecuteUpdateFormat=$methodName$\n\tSQL:$sql$\n\tadditional_info:\n\t$additionalInfo$ -sqlLogFormatter.endExecuteUpdateFormat=$methodName$\n\texe:$executeTime$ms count:$updateCount$ -sqlLogFormatter.startExecuteBatchFormat=$methodName$\n\tSQL:$sql$\n\tadditional_info:\n\t$additionalInfo$ -sqlLogFormatter.endExecuteBatchFormat=$methodName$\n\texe:$executeTime$ms count:$updateCount$ -``` - -プロパティの説明を下記に示す。 - -| プロパティ名 | 設定値 | -|---|---| -| sqlLogFormatter.className | SqlLogFormatterのクラス名。 SqlLogFormatterクラスを差し替える場合に指定する。 | -| sqlLogFormatter.startRetrieveFormat | SqlPStatement#retrieveメソッドの検索開始時に使用するフォーマット。 | -| sqlLogFormatter.endRetrieveFormat | SqlPStatement#retrieveメソッドの検索終了時に使用するフォーマット。 | -| sqlLogFormatter.startExecuteFormat | SqlPStatement#executeメソッドの実行開始時に使用するフォーマット。 | -| sqlLogFormatter.endExecuteFormat | SqlPStatement#executeメソッドの実行終了時に使用するフォーマット。 | -| sqlLogFormatter.startExecuteQueryFormat | SqlPStatement#executeQueryメソッドの検索開始時に使用するフォーマット。 | -| sqlLogFormatter.endExecuteQueryFormat | SqlPStatement#executeQueryメソッドの検索終了時に使用するフォーマット。 | -| sqlLogFormatter.startExecuteUpdateFormat | SqlPStatement#executeUpdateメソッドの更新開始時に使用するフォーマット。 | -| sqlLogFormatter.endExecuteUpdateFormat | SqlPStatement#executeUpdateメソッドの更新終了時に使用するフォーマット。 | -| sqlLogFormatter.startExecuteBatchFormat | SqlPStatement#executeBatchメソッドの更新開始時に使用するフォーマット。 | -| sqlLogFormatter.endExecuteBatchFormat | SqlPStatement#executeBatchメソッドの更新終了時に使用するフォーマット。 | - -フォーマットに指定可能なプレースホルダの一覧とデフォルトのフォーマットを下記に示す。 -デフォルトのフォーマットは、フォーマット内の改行位置で改行して表示する。 - -### SqlPStatement#retrieveメソッドの検索開始時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| SQL文 | $sql$ | -| 取得開始位置 | $startPosition$ | -| 取得最大件数 | $size$ | -| タイムアウト時間 | $queryTimeout$ | -| フェッチする行数 | $fetchSize$ | -| 付加情報 | $additionalInfo$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\tSQL = [$sql$] - \n\tstart_position = [$startPosition$] size = [$size$] - \n\tquery_timeout = [$queryTimeout$] fetch_size = [$fetchSize$] - \n\tadditional_info: - \n\t$additionalInfo$ -``` - -### SqlPStatement#retrieveメソッドの検索終了時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| 実行時間 | $executeTime$ | -| データ取得時間 | $retrieveTime$ | -| 検索件数 | $count$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\texecute_time(ms) = [$executeTime$] retrieve_time(ms) = [$retrieveTime$] count = [$count$] -``` - -### SqlPStatement#executeメソッドの実行開始時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| SQL文 | $sql$ | -| 付加情報 | $additionalInfo$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\tSQL = [$sql$] - \n\tadditional_info: - \n\t$additionalInfo$ -``` - -### SqlPStatement#executeメソッドの実行終了時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| 実行時間 | $executeTime$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\texecute_time(ms) = [$executeTime$] -``` - -### SqlPStatement#executeQueryメソッドの検索開始時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| SQL文 | $sql$ | -| 付加情報 | $additionalInfo$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\tSQL = [$sql$] - \n\tadditional_info: - \n\t$additionalInfo$ -``` - -### SqlPStatement#executeQueryメソッドの検索終了時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| 実行時間 | $executeTime$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\texecute_time(ms) = [$executeTime$] -``` - -### SqlPStatement#executeUpdateメソッドの更新開始時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| SQL文 | $sql$ | -| 付加情報 | $additionalInfo$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\tSQL = [$sql$] - \n\tadditional_info: - \n\t$additionalInfo$ -``` - -### SqlPStatement#executeUpdateメソッドの更新終了時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| 実行時間 | $executeTime$ | -| 更新件数 | $updateCount$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\texecute_time(ms) = [$executeTime$] update_count = [$updateCount$] -``` - -### SqlPStatement#executeBatchメソッドの更新開始時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| SQL文 | $sql$ | -| 付加情報 | $additionalInfo$ | - -デフォルトのフォーマット - -```bash -$methodName$ - \n\tSQL = [$sql$] - \n\tadditional_info: - \n\t$additionalInfo$ -``` - -### SqlPStatement#executeBatchメソッドの更新終了時 - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| メソッド名 | $methodName$ | -| 実行時間 | $executeTime$ | -| バッチ件数 | $batchCount$ | - -デフォルトのフォーマット - -```bash -$methodName$ - $\n\texecute_time(ms) = [$executeTime$] batch_count = [$updateCount$] -``` - -## SQLログの出力例 - -SQLログの出力例を下記に示す。 - -log.propertiesの設定例 - -```bash -writerNames=appFile - -# ログの出力先 -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=./app.log -writer.appFile.encoding=UTF-8 -writer.appFile.maxFileSize=10000 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=$date$ -$logLevel$- R[$requestId$] U[$userId$] E[$executionId$] $message$ - -availableLoggersNamesOrder=SQL - -# SQL -loggers.SQL.nameRegex=SQL -loggers.SQL.level=TRACE -loggers.SQL.writerNames=appFile -``` - -app-log.propertiesの設定例 - -```bash -# SqlLogFormatterの設定(個別項目のフォーマット) -sqlLogFormatter.startRetrieveFormat=$methodName$\n\tSQL:$sql$\n\tstart:$startPosition$ size:$size$\n\tadditional_info:\n\t$additionalInfo$ -sqlLogFormatter.endRetrieveFormat=$methodName$\n\texe:$executeTime$ms ret:$retrieveTime$ms count:$count$ -``` - -上記設定から出力した結果を下記に示す。 - -```bash -2011-02-15 18:06:05.952 -DEBUG- R[LOGIN00102] U[9999999999] E[APUSRMGR0001201102151806058420002] nablarch.core.db.statement.BasicSqlPStatement#retrieve - SQL:SELECT BIZ_DATE FROM BUSINESS_DATE WHERE SEGMENT = ? - start:1 size:0 - additional_info: -2011-02-15 18:06:05.952 -TRACE- R[LOGIN00102] U[9999999999] E[APUSRMGR0001201102151806058420002] nablarch.core.db.statement.BasicSqlPStatement#Parameters - 01 = [00] -2011-02-15 18:06:05.952 -DEBUG- R[LOGIN00102] U[9999999999] E[APUSRMGR0001201102151806058420002] nablarch.core.db.statement.BasicSqlPStatement#retrieve - exe:0ms ret:0ms count:1 -2011-02-15 18:06:05.952 -DEBUG- R[LOGIN00102] U[9999999999] E[APUSRMGR0001201102151806058420002] nablarch.core.db.transaction.JdbcTransaction#commit() -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-03-PerformanceLog.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-03-PerformanceLog.md deleted file mode 100644 index 0a1c289fe..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-03-PerformanceLog.md +++ /dev/null @@ -1,169 +0,0 @@ -# パフォーマンスログの出力 - -パフォーマンスログは、任意の処理範囲に対する実行時間とメモリ使用量を出力し、開発時のパフォーマンスチューニングに使用する。 -アプリケーションでは、ソースコード上でフレームワークが提供するAPIを呼び出し、計測対象の処理範囲を指定して出力する。 - -## パフォーマンスログの出力方針 - -パフォーマンスログで想定している出力方針を下記に示す。 -パフォーマンスログは、開発時の使用を想定しているためDEBUGレベルで出力する。 - -| ログレベル | ロガー名 | -|---|---| -| DEBUG | PERFORMANCE | - -上記出力方針に対するログ出力の設定例を下記に示す。 - -log.propertiesの設定例 - -```bash -# PERFORMANCE -loggers.PER.nameRegex=PERFORMANCE -loggers.PER.level=DEBUG -loggers.PER.writerNames=<出力先のログライタ> -``` - -## パフォーマンスログの出力項目 - -パフォーマンスログの個別項目を下記に示す。 - -ここでは、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) の設定で指定できる共通項目については省略する。 -共通項目と個別項目を組み合わせたフォーマットについては、 [各種ログの共通項目のフォーマット](../../component/libraries/libraries-01-Log.md#各種ログの共通項目のフォーマット) を参照。 - -| 項目名 | 説明 | -|---|---| -| ポイント | 測定対象を識別するID。 | -| 処理結果 | 処理結果を表す文字列。 | -| 開始日時 | 処理の開始日時。 | -| 終了日時 | 処理の終了日時。 | -| 実行時間 | 処理の実行時間（終了日時－開始日時）。 | -| 最大メモリ量 | 処理の開始時点のヒープサイズ。 | -| 開始時の空きメモリ量 | 処理の開始時点の空きヒープサイズ。 | -| 開始時の使用メモリ量 | 処理の開始時点の使用ヒープサイズ。 | -| 終了時の空きメモリ量 | 処理の開始時点の空きヒープサイズ。 | -| 終了時の使用メモリ量 | 処理の開始時点の使用ヒープサイズ。 | - -## パフォーマンスログの出力方法 - -パフォーマンスログの出力に使用するクラスを下記に示す。 - -![Log_PerformanceLog_ClassDiagram.jpg](../../../knowledge/assets/libraries-03-PerformanceLog/Log_PerformanceLog_ClassDiagram.jpg) - -| クラス名 | 概要 | -|---|---| -| nablarch.core.log.app.PerformanceLogUtil | パフォーマンスログを出力するクラス。 | -| nablarch.core.log.app.PerformanceLogFormatter | パフォーマンスログの個別項目をフォーマットするクラス。 | - -パフォーマンスログは、フレームワークが提供するPerformanceLogUtilクラスを使用して出力する。 -PerformanceLogUtilは、処理の開始時に呼び出すstartメソッドと終了時に呼び出すendメソッドを提供する。 -PerformanceLogUtilは、endメソッドが呼ばれた時点で、startメソッドで取得した日時とメモリ使用量を合わせて出力する。 -PerformanceLogUtilの使用例を下記に示す。 - -```java -// startメソッドでは、測定対象を識別するポイントを指定する。 -String point = "UserSearchAction#doUSERS00101"; -PerformanceLogUtil.start(point); - -// 検索実行 -UserSearchService searchService = new UserSearchService(); -SqlResultSet searchResult = searchService.selectByCondition(condition); - -// endメソッドでは、ポイント、処理結果を表す文字列、ログ出力のオプション情報を指定できる。 -// 以下ではログ出力のオプション情報は指定していない。 -PerformanceLogUtil.end(point, String.valueOf(searchResult.size())); -``` - -> **Warning:** -> PerformanceLogUtilは、測定対象を実行時ID＋ポイント名で一意に識別している。 -> このため、再帰呼び出しの中でPerformanceLogUtilを使用すると計測を実施出来ないため注意すること。 - -PerformanceLogUtilは、プロパティファイル(app-log.properties)を読み込み、 -PerformanceLogFormatterオブジェクトを生成して、個別項目のフォーマット処理を委譲する。 -プロパティファイルのパス指定や実行時の変更方法は、 [各種ログの設定](../../component/libraries/libraries-01-Log.md#各種ログの設定) を参照。 -パフォーマンスログの設定例を下記に示す。 - -app-log.propertiesの設定例 - -```bash -# PerformanceLogFormatter -performanceLogFormatter.className=nablarch.core.log.app.PerformanceLogFormatter -performanceLogFormatter.targetPoints=UserSearchAction#doUSERS00101 -performanceLogFormatter.datePattern=yyyy-MM-dd HH:mm:ss.SSS -performanceLogFormatter.format=point:$point$ result:$result$ exe_time:$executionTime$ms -``` - -プロパティの説明を下記に示す。 - -| プロパティ名 | 設定値 | -|---|---| -| performanceLogFormatter.className | PerformanceLogFormatterのクラス名。 PerformanceLogFormatterを差し替える場合に指定する。 | -| performanceLogFormatter.format | パフォーマンスログの個別項目のフォーマット。 フォーマットに指定可能なプレースホルダについては下記を参照。 | -| performanceLogFormatter.datePattern | 開始日時と終了日時に使用する日時パターン。 パターンには、java.text.SimpleDateFormatが規程している構文を指定する。 デフォルトは"yyyy-MM-dd HH:mm:ss.SSS"。 | -| performanceLogFormatter.targetPoints | 出力対象とするポイント名。 複数指定する場合はカンマ区切り。 パフォーマンスログは、誤設定による無駄な出力を防ぐため、この設定に基づき出力する。 | - -フォーマットに指定可能なプレースホルダの一覧を下記に示す。 - -| プレースホルダ | 説明 | -|---|---| -| $point$ | 測定対象を識別するID。 | -| $result$ | 処理結果を表す文字列。 | -| $startTime$ | 処理の開始日時。 | -| $endTime$ | 処理の終了日時。 | -| $executionTime$ | 処理の実行時間（終了日時－開始日時）。 | -| $maxMemory$ | 処理の開始時点のヒープサイズ。 | -| $startFreeMemory$ | 処理の開始時点の空きヒープサイズ。 | -| $startUsedMemory$ | 処理の開始時点の使用ヒープサイズ。 | -| $endFreeMemory$ | 処理の開始時点の空きヒープサイズ。 | -| $endUsedMemory$ | 処理の開始時点の使用ヒープサイズ。 | - -デフォルトのフォーマットを下記に示す。 -フォーマット内の改行位置で改行して表示する。 - -```bash -\n\tpoint = [$point$] result = [$result$] -\n\tstart_time = [$startTime$] end_time = [$endTime$] -\n\texecution_time = [$executionTime$] -\n\tmax_memory = [$maxMemory$] -\n\tstart_free_memory = [$startFreeMemory$] start_used_memory = [$startUsedMemory$] -\n\tend_free_memory = [$endFreeMemory$] end_used_memory = [$endUsedMemory$] -``` - -### パフォーマンスログの出力例 - -パフォーマンスログの出力例を下記に示す。 - -log.propertiesの設定例 - -```bash -writerNames=appFile - -# ログの出力先 -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=./app.log -writer.appFile.encoding=UTF-8 -writer.appFile.maxFileSize=10000 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=$date$ -$logLevel$- R[$requestId$] U[$userId$] E[$executionId$] $message$ - -availableLoggersNamesOrder=PER - -# PER -loggers.PER.nameRegex=PERFORMANCE -loggers.PER.level=DEBUG -loggers.PER.writerNames=appFile -``` - -app-log.propertiesの設定例 - -```bash -# PerformanceLogFormatterの設定(個別項目のフォーマット) -performanceLogFormatter.targetPoints=UserSearchAction#doUSERS00101 -performanceLogFormatter.format=point:$point$ result:$result$ exe_time:$executionTime$ms -``` - -上記設定から出力した結果を下記に示す。 -PerformanceLogUtilの使用例で示した検索処理の出力を示す。 - -```bash -2011-02-15 18:25:50.577 -DEBUG- R[USERS00101] U[0000000001] E[APUSRMGR0001201102151825504990004] point:UserSearchAction#doUSERS00101 result:17 exe_time:16ms -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-03-TransactionManager.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-03-TransactionManager.md deleted file mode 100644 index c323fc869..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-03-TransactionManager.md +++ /dev/null @@ -1,77 +0,0 @@ -# トランザクション管理 - -## 概要 - -様々なリソース（主にデータベースやメッセージキュー）に対するトランザクション管理機能を提供する。 - -本機能は、本フレームワークの他の機能から使用されることを想定している。 -Webアプリケーションでは、 [トランザクション制御ハンドラ](../../component/handlers/handlers-TransactionManagementHandler.md) の機能が使用する。 -このため、アプリケーションプログラマは、本機能を直接使用することはない。 - -## 特徴 - -### 任意のリソースに対するトランザクション制御を追加可能 - -トランザクション制御部品を追加することにより、任意のリソースに対するトランザクション制御を行うことが可能となっている。 - -### 分散トランザクション機能(未実装機能) - -Webコンテナが提供するトランザクションマネージャ(ユーザトランザクション)機能を使用して分散トランザクションを行う機能。 -分散トランザクションを使用するかどうかは、設定ファイルに記述するのみで実現可能となっている。 - -## 要求 - -### 実装済み - -* RDBMSのトランザクション管理ができる。 -* アイソレーションレベルが設定できる。 -* トランザクション開始時に任意のSQL文を実行できる。 -* トランザクションタイムアウト処理ができる。 - -### 未実装 - -* 分散トランザクションに対応できる。 -* トランザクションのリトライ(デッドロックやロック要求タイムアウト発生時のリトライ)ができる。 - データベースに対するトランザクション使用時に、特定のエラーの発生を検知しトランザクションを自動リトライする機能。 - リトライ対象のエラーは、SQLStateまたはベンダー依存のSQLエラーコードで設定が可能である。 - -## 構造 - -### クラス図 - -![TransactionManagerSpec_ClassDesign.jpg](../../../knowledge/assets/libraries-03-TransactionManager/TransactionManagerSpec_ClassDesign.jpg) - -#### 各クラスの責務 - -##### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.transaction.TransactionFactory | トランザクション制御オブジェクト(Transaction)を取得するインタフェース | -| nablarch.core.transaction.Transaction | トランザクション制御オブジェクト。 新たなトランザクション方式を追加する場合は、このインタフェースの実装クラスを新たに追加する必要がある。 | - -##### クラス定義 - -a) nablarch.core.transaction.TransactionFactoryの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.transaction.JdbcTransactionFactory | JdbcTransactionを生成するクラス。 トランザクションタイムアウトの設定は本クラスに行う。 設定内容の詳細は、 [トランザクションタイムアウトを使用するための設定](../../component/libraries/libraries-04-TransactionTimeout.md#トランザクションタイムアウトを使用するための設定) を参照。 | - -b) nablarch.core.transaction.Transactionの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.transaction.JdbcTransaction | JDBCで提供されるトランザクション機能を使用して、トランザクション制御を行うクラス。 | - -c) その他のクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.transaction.TransactionContext | ThreadLocal(スレッド内)にTransactionを保持するクラス。 保持するTransactionには、任意の名前(トランザクション名)を付加することができる。 トランザクション名の詳細は、 [データベースコネクション名とトランザクション名](../../component/libraries/libraries-04-Connection.md#nablarchcoredbconnectionパッケージ) を参照すること。 > **Warning:** > ThreadLocalでTransactionが管理されるため、アプリケーションのスレッドと同一のスレッドでTransactionを設定する必要がある。 > マルチスレッド環境では、各スレッドに対してTransactionを設定する必要があるため、注意が必要である。 | - -## 使用例 - -### データベースに対するトランザクション管理 - -詳細は、 [データベースアクセス(検索、更新、登録、削除)機能](../../component/libraries/libraries-04-DbAccessSpec.md) を参照。 diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Connection.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Connection.md deleted file mode 100644 index 79d1ad698..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Connection.md +++ /dev/null @@ -1,215 +0,0 @@ -# データベース接続部品の構造 - -本章では、データベース接続部分についての解説を行う。 - -本機能で提供する接続方式については、 [概要](../../component/libraries/libraries-04-DbAccessSpec.md#概要) を参照すること。 - -## クラス図 - -![DbAccessSpec_ConnectionClassDesign.jpg](../../../knowledge/assets/libraries-04-Connection/DbAccessSpec_ConnectionClassDesign.jpg) - -### 各クラスの責務 - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.db.connectionパッケージ | | -| ConnectionFactory | データベース接続を生成するインターフェース。 データベース接続方式を追加する場合や、 [実装クラス](../../component/libraries/libraries-04-Connection.md#クラス定義) で生成されるBasicDbConnectionを入れ替える場合には、 本インタフェースの実装クラスを追加する必要がある。 | -| AppDbConnection | データベース接続を保持したインタフェース。 アプリケーションでは、本インタフェースを使用して、SQL文実行用オブジェクトを取得する。 | -| TransactionManagerConnection | トランザクション制御を行うインタフェース(AppDbConnectionのサブインタフェース)。 本機能の特徴である [リソース解放機能](../../component/libraries/libraries-04-DbAccessSpec.md#頻繁に使用するデータベースリソースの自動解放機能) は、本インタフェースの実装クラスで提供される。 | - -#### クラス定義 - -a) nablarch.core.db.connection.ConnectionFactoryの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.connectionパッケージ | | -| ConnectionFactorySupport | ConnectionFactoryインタフェースを実装したクラスをサポートするクラス。 本クラスの実装は、サブクラスで必要となる共通設定を保持するのみである。 | -| BasicDbConnectionFactoryForJndi | JNDI経由でWebアプリケーションサーバ等からデータベース接続(java.sql.Connection)を取得し、 BasicDbConnectionを生成するクラス。 JNDI経由でデータベース接続を取得するための情報は、 [リポジトリ](../../component/libraries/libraries-02-Repository.md) を使用して本クラスに設定をする必要がある。 設定ファイルの記述方法は、 [設定ファイル例(JNDIを使用してデータベース接続を行う場合)](../../component/libraries/libraries-04-Connection.md#設定ファイル例jndiを使用してデータベース接続を行う場合) を参照すること。 | -| BasicDbConnectionFactoryForDataSource | javax.sql.DataSourceからデータベース接続(java.sql.Connection)を取得し、 BasicDbConnectionを生成するクラス。 javax.sql.DataSourceは、 [リポジトリ](../../component/libraries/libraries-02-Repository.md) を使用して本クラスに設定をする必要がある。 設定ファイルの記述方法は、 [設定ファイル例(DataSourceを使用してデータベース接続を行う場合)](../../component/libraries/libraries-04-Connection.md#設定ファイル例datasourceを使用してデータベース接続を行う場合) を参照すること。 | - -b) nablarch.core.db.connection.TransactionManagerConnectionの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.connectionパッケージ | | -| BasicDbConnection | TransactionManagerConnection(AppDbConnection)の基本実装クラス。 > **Note:** > 本クラスは、データベースベンダー非依存の実装となっている。 > 各プロジェクトにおいて、データベースベンダーに依存するような実装が出てきた場合には、 > TransactionManagerConnectionの実装クラスを新たに追加し、本クラスから差し替えて使用すること。 | - -c) その他のクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.transactionパッケージ | | -| SimpleDbTransactionManager | 簡易的にトランザクション制御を行うクラス。 本クラスを使用して、トランザクションを開始するとAppDbConnectionが生成され、DbConnectionContextに設定される。 | -| SimpleDbTransactionExecutor | SimpleDbTransactionManagerを使用してSQL文を実行するための抽象クラス。 本クラス経由でSQL文を実行することにより、全ての機能で統一的な例外処理を提供することが出来る。 | -| nablarch.core.db.connectionパッケージ | | -| DbConnectionContext | AppDbConnectionをThreadLocalで保持するクラス。 保持するAppDbConnectionには、任意の名前(データベースコネクション名)を付加することができる。 データベースコネクション名の詳細は、下記ドキュメントを参照 04_TransactionConnectionName > **Attention:** > ThreadLocalでAppDbConnectionが管理されるため、アプリケーションのスレッドと同一のスレッドでAppDbConnectionを設定する必要がある。 > マルチスレッド環境では、各スレッドに対してAppDbConnectionを設定する必要があるため、注意が必要である。 | - -## トランザクション制御、データベースアクセスの使用例 - -### 処理シーケンス - -![DbAccessSpec_ConnectionSequence.jpg](../../../knowledge/assets/libraries-04-Connection/DbAccessSpec_ConnectionSequence.jpg) - -### Javaの実装例 - -```java -// ******** 注意 ******** -// SimpleDbTransactionManagerは、フレームワーク専用のトランザクション制御クラスである。 -// このため、アプリケーションプログラマがSimpleDbTransactionManagerや、 -// SimpleDbTransactionExecutorを参照する下記のような実装を行うことはない。 - -// リポジトリからSimpleDbTransactionManagerを取得する。 -// （SimpleDbTransactionManagerは、setterインジェクションでインジェクションを行うか本サンプルのようにリポジトリから取得する。) -SimpleDbTransactionManager transactionManager = (SimpleDbTransactionManager) SystemRepository.getObject("transactionManager"); - -// SimpleDbTransactionExecutorを継承し、executeメソッドを実装する。 -// executeメソッドでは、パラメータのデータベース接続を使用してSQL文を実行する。 -SqlResultSet resultSet = new SimpleDbTransactionExecutor( - transactionManager) { - @Override - public SqlResultSet execute(AppDbConnection connection) { - SqlPStatement prepared = connection.prepareStatement(query); - int parameterIndex = 1; - prepared.setString(parameterIndex++, requestId); - prepared.setString(parameterIndex, - requestTableServiceAvailableOkStatus); - return prepared.retrieve(); - } -// SimpleDbTransactionExecutorを実装したクラスのdoTransactionを実行する。 -// これにより、上記で説明したexecuteメソッドがコールバックされSQL文を簡易的に実行することが可能となる。 -}.doTransaction(); -``` - -> **Attention:** -> SimpleDbTransactionExecutorを使用してSQL文を実行するのは、既に開始されている業務トランザクション以外のトランザクションを使用してSQL文を実行する場合である。 -> 主に、Webアプリケーションの認証機能や開閉局チェック機能のように、ビジネスロジックとは異なる独立したトランザクションが必要となるコンポーネントで使用する。 - -## 設定ファイル例(DataSourceを使用してデータベース接続を行う場合) - -本設定ファイルは、 DataSourceからデータベース接続を取得する場合の 設定例となっている。 -JNDI経由でデータベース接続を取得する場合 は、 [設定ファイル例(JNDIを使用してデータベース接続を行う場合)](../../component/libraries/libraries-04-Connection.md#設定ファイル例jndiを使用してデータベース接続を行う場合) を参照すること。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'yyyy-mm-dd hh24:mi:ss.ff' - - - - - - -``` - -### 設定内容詳細 - -a) SimpleDbTransactionManagerの設定 - -| property名 | 設定内容 | -|---|---| -| connectionFactory(必須) | nablarch.core.db.connection.ConnectionFactoryを実装したクラスの設定を行う。 本サンプルでは、「nablarch.core.db.connection.BasicDbConnectionFactoryForDataSource」を設定している。 | -| transactionFactory(必須) | nablarch.core.transaction.TransactionFactoryを実装したクラスの設定を行う。 本サンプルでは、「nablarch.core.db.connection.BasicDbConnectionFactoryForDataSource」を設定している。 | -| dbTransactionName | データベーストランザクション名を任意の値で設定する。 設定を行わない場合、デフォルトのデータベーストランザクション名が本プロパティに自動的に設定される。 | - -b) nablarch.core.db.connection.BasicDbConnectionFactoryForDataSourceの設定 - -| property名 | 設定内容 | -|---|---| -| statementReuse(必須) | Statementをキャッシュするか否かの設定を、trueまたはfalseで設定する。 trueを設定すると、BasicDbConnectionのインスタンス単位でStatementオブジェクトがキャッシュされる。 > **Note:** > キャッシュを有効にした場合は、同一のSQLを複数回実行した場合、 > 2回目以降はキャッシュされたStatementオブジェクトが使用される。 > このため、複数回同一のSQL文を実行した場合はオブジェクトの生成コストを削減でき性能改善が期待できる。 > 特に1処理で同一のSQL文を多数実行する可能性のあるバッチ処理(バッチ処理では、大量データを繰り返し実行するので、 > 同一のSQL文を複数回実行する。)では効果が期待できる。 > 逆に、画面処理では1処理で同一のSQL文を繰り返し実行する事が少く、 > キャッシュが有効に使用されない可能性が高いため、本機能を使用するメリットはあまりない。 | -| dataSource(必須) | javax.sql.DataSourceを実装したクラスを設定する。 本サンプルでは、「oracle.jdbc.pool.OracleDataSource」を設定し、OracleDataSourceのproperyに必要な情報を設定している。 > **Note:** > 本propertyに設定する値は、各データベースベンダーのJDBC関連ドキュメントを参照し設定すること。 | -| statementFactory(必須) | nablarch.core.statement.StatementFactoryを実装したクラスを設定する。 本サンプルでは、「nablarch.core.db.statement.BasicStatementFactory」を設定している。 > **Note:** > statementFactoryの設定は、後述の [SQL文実行部品の構造とその使用方法](../../component/libraries/libraries-04-Statement.md#sql文実行部品の構造とその使用方法) を参照 | - -c) nablarch.core.db.transaction.JdbcTransactionFactoryへの設定 - -| property名 | 設定内容 | -|---|---| -| isolationLevel | アイソレーションレベルを設定する。 設定可能なアイソレーションレベル * READ_COMMITTED(java.sql.Connection#TRANSACTION_READ_COMMITTED) * READ_UNCOMMITTED(java.sql.Connection#TRANSACTION_READ_UNCOMMITTED) * REPEATABLE_READ(java.sql.Connection#TRANSACTION_REPEATABLE_READ) * SERIALIZABLE(java.sql.Connection#TRANSACTION_SERIALIZABLE) 本設定を記述しない場合は、デフォルトでREAD_COMMITTEDが設定される。 > **Note:** > データベースによっては、使用できるアイソレーションレベルが限られている。 > データベースベンダーのマニュアルを参照し、適切なアイソレーションレベルを設定すること。 | -| initSqlList | トランザクション開始時に実行したいSQL文をlist形式で設定する。 SQL文を実行する必要がない場合には、設定は不要である。 | - -## 設定ファイル例(JNDIを使用してデータベース接続を行う場合) - -本設定例は、JNDI経由でデータベース接続を取得する際に必要となる箇所のみを記載している。 -JNDIに関連のない設定については、 [設定ファイル例(DataSourceを使用してデータベース接続を行う場合)](../../component/libraries/libraries-04-Connection.md#設定ファイル例datasourceを使用してデータベース接続を行う場合) を参照し、必要な設定を行うこと。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -### 設定内容詳細 - -| property名 | 設定内容 | -|---|---| -| statementReuse(必須) | [BasicDbConnectionFactoryForDataSourceへの設定](../../component/libraries/libraries-04-Connection.md#設定内容詳細) の同一項目を参照すること。 | -| statementFactory(必須) | [BasicDbConnectionFactoryForDataSourceへの設定](../../component/libraries/libraries-04-Connection.md#設定内容詳細) の同一項目を参照すること。 | -| jndiProperties | JNDI経由でDataSourceを取得するための、環境設定を行う。 Webサーバ上で稼働する場合や、クラスパス配下に「jndi.properties」を配置している場合には、本設定値は省略して良い。 > **Note:** > 設定に関する詳細は、Webサーバのベンダーマニュアルなどを参照すること。 > 本設定例は、WebLogicサーバ上にDataSourceが登録されていることを想定した設定例となっている。 | -| jndiResourceName(必須) | JNDIリソース名を設定する。 > **Note:** > 設定に関する詳細は、Webサーバのベンダーマニュアルなどを参照すること。 > 例えば、WebLogicサーバの場合は、管理コンソールからDataSourceを登録する際に「JNDI Name」に入力した値を設定する。 | diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-DbAccessSpec.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-DbAccessSpec.md deleted file mode 100644 index 90918228c..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-DbAccessSpec.md +++ /dev/null @@ -1,424 +0,0 @@ -# データベースアクセス(検索、更新、登録、削除)機能 - -## 概要 - -下記２種類の接続方法を使用してデータベース接続を行う機能を提供する。 -下記以外の接続方法を使用したい場合には、データベース接続を取得する部品(例えば、java.sql.DriverManagerから取得する部品)を追加することにより実現可能である。 - -*デフォルトで提供するデータベース接続方法* - -a) JNDI接続(Webアプリケーションサーバに登録したデータベース接続を使用する方式) - -Webアプリケーションサーバに登録したデータベース接続を使用する場合の接続方法。 -Webアプリケーションの場合には、本接続方式を使用することを推奨する。 - -b) DataSource接続(javax.sql.DataSourceの実装クラスを使用してデータベース接続を行う方式) - -java.sql.DataSourceを使用する場合の接続方法。 -バッチアプリケーションなどのようにWebアプリケーションサーバに登録したDataSourceを使用できない場合には、本接続方式を使用することになる。 - -> **Note:** -> 自動テストなどでWebアプリケーションサーバを必要としない場合には、本接続方式を使用することによりWebアプリケーションサーバを起動しなくてもテストの実行が可能となる。 -> 接続方式の切り替えは、設定ファイルで行えるためアプリケーションコードに影響を与えることはない。 - -データベース接続は、本フレームワークの他の機能から初期化される。 -Webアプリケーションでは、 [Nablarchサーブレットコンテキスト初期化リスナ](../../component/handlers/handlers-NablarchServletContextListener.md#nablarchサーブレットコンテキスト初期化リスナ) により初期化が行われる。 - -アプリケーションプログラマは、本機能をSQL文の実行に使用する。 -SQL文の実行方法については、 [SQL文実行部品の構造とその使用方法](../../component/libraries/libraries-04-Statement.md#sql文実行部品の構造とその使用方法) 以降に記述する。 - -## 特徴 - -### JDBCのAPIを踏襲した機能 - -本機能は基本的にJDBCのAPIを踏襲(ラップ)しているため、JDBCプログラミング経験者であればスムーズに開発を行うことができる。 -JDBCのAPIを拡張している機能は、下記特徴を参照すること。 - -* [件数指定でデータを取得(簡易検索機能)できる機能](../../component/libraries/libraries-04-DbAccessSpec.md#件数指定でデータを取得簡易検索機能できる機能) -* [Javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能](../../component/libraries/libraries-04-DbAccessSpec.md#javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能) -* [LIKE検索を簡易的に実装出来る機能](../../component/libraries/libraries-04-DbAccessSpec.md#like検索を簡易的に実装出来る機能) -* [条件が可変のSQL文を組み立てる機能](../../component/libraries/libraries-04-DbAccessSpec.md#条件が可変のsql文を組み立てる機能) - -### 頻繁に使用するデータベースリソースの自動解放機能 - -データベースアクセスで頻繁に使用する下記リソースの解放処理はアプリケーションで実装する必要はない。 -ただし、下記に該当しないリソース(BLOB型から取得したInputStreamや、バイナリファイルをデータベースに登録する際のファイルリソース等)は、本機能でのリソース解放対象外となるため、各アプリケーションで実装すること。 - -**本機能で解放されるデータベースリソース** - -* java.sql.Connection -* java.sql.Statement -* java.sql.ResultSet(Statementを解放することにより、自動で解放される。) - -### SQL文の実行ログ(以降SQLログ)の出力する機能 - -SQLログはロガー名に文字列で「SQL」(SQLロガー)を指定してログ出力を行う。 -SQLログをログ出力する場合は、このSQLロガーをログ出力対象に含める必要がある。 - -ロガー名でのログ出力制御の設定方法は、 [ログ出力](../../component/libraries/libraries-01-Log.md) を参照すること。 -SQLログの詳細については、 [SQLログの出力](../../component/libraries/libraries-02-SqlLog.md#sqlログの出力) を参照。 - -> **Note:** -> 出力される内容と、出力時に使用されるログレベル -> SQLログの出力を抑制したい場合には、SQLカテゴリの下記ログレベルを出力対象外に設定する。 - -> * > DEBUGレベルで出力する内容 - -> * > 実行されたSQL -> * > SELECT文の場合には、取得件数 -> * > 実行時間 -> * > SQL文を外部ファイル化した場合のSQLを一意に特定するためのID -> * > TRACEレベルで出力する内容 - -> * > バインド変数に設定した値 - -> **Warning:** -> 性能劣化(ディスクI/Oに起因する)やディスクリソースの圧迫(ログサイズの増加に起因する)の原因となるため、SQLログは本番環境では出力すべきでない。 - -### 件数指定でデータを取得(簡易検索機能)できる機能 - -開始位置、取得件数を指定してデータを取得することができる。 -これにより、ページ切り替え機能をもつ画面を作成する際に、アプリケーションで表示データをフィルタリングする必要がなくなる。 - -### Javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能 - -オブジェクトのフィールドの値を1項目ずつ指定するのではなく、オブジェクト自体を指定してデータベースへフィールドの値を登録することができる。 -オブジェクトを指定してデータベースに登録できるデータは、下記の２種類である。 - -* 任意のオブジェクト(主に、 [業務コンポーネントの責務配置](../../about/about-nablarch/about-nablarch-determining-stereotypes.md) に定義されているFormオブジェクト)のフィールドの値 -* Map実装クラスのvalue - -この時に、ログインユーザIDとタイムスタンプは、オブジェクトに設定されていなくてもデータベースへ登録することが可能となっている。 -また、処理後にはこれらの値を参照することができるため、画面表示時に使用すること可能である。 - -詳細は、 [オブジェクトのフィールドの値のデータベースへの登録例](../../component/libraries/libraries-04-ObjectSave.md#オブジェクトのフィールドの値のデータベースへの登録機能オブジェクトのフィールド値を使用した検索機能) を参照。 - -> **Note:** -> 自動設定項目は、各開発プロジェクトで追加、変更が可能となっている。 -> 例えば、アノテーションを使用せずにカラム名（フィールド名）で判断を行い値を設定するといったことも可能である。 - -> **Note:** -> フィールドの値を個別に設定する場合と、オブジェクトを設定する場合の実装の違い - -> **フィールドの値を個別に設定する場合** - -> ```java -> UserEntity entity = new UserEntity(); -> entity.setName("名前"); -> entity.setAddress("住所"); -> -> //******************************************************** -> // フィールドの値を一項目ずつ指定する場合 -> // テーブルの項目が増えると、ステップ数が増加する。 -> // また、テーブルの項目が増えた場合に修正が発生する。 -> //******************************************************** -> statement.setString(1, entity.getName()); -> statement.setString(2, entity.getAddress()); -> -> //******************************************************** -> // ユーザID、タイムスタンプを設定する。 -> //******************************************************** -> // ユーザIDをコンテキストから取得して設定する。 -> statement.setString(3, ThreadContext.getUserId()); -> // システム日時を、日付取得部品から取得して設定する。 -> // 日付取得部品は、リポジトリ機能から事前に取得しておく必要がある。 -> statement.setString(4, systemTimeProvider.getDate()); -> statement.executeUpdate(); -> ``` - -> **オブジェクトを設定する場合** - -> ```java -> UserEntity entity = new UserEntity(); -> entity.setName("名前"); -> entity.setAddress("住所"); -> -> //******************************************************** -> // オブジェクトを指定する場合 -> // 1項目ずつ値を設定する必要がないため、1ステップでSQL文の実行が可能 -> // ログインユーザID、タイムスタンプは、executeUpdateByObject内で -> // 自動で設定されるため、事前に設定は不要。 -> //******************************************************** -> statement.executeUpdateByObject(entity); -> ``` - -### LIKE検索を簡易的に実装出来る機能 - -部分一致検索(LIKE)機能を簡易的に実装できる機能を提供する。 -この機能には、下記のメリットがある。 - -* LIKE条件に設定する文字列のエスケープ処理を実装する必要がない。(実装する必要がないので、エスケープ漏れは発生しない。) -* Javaコードで条件に「%」を付加する必要がない。(「%」はSQL文に記述するため、SQL文のレビューで仕様との相違がないかの確認が出来る。) -* Javaの実装は、 [Javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能](../../component/libraries/libraries-04-DbAccessSpec.md#javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能) 機能と同様に、オブジェクトのフィールドの値を条件に設定できる。 - -> **Note:** -> 本機能を使用した場合と、従来のJDBC標準機能を使用した場合での実装の違い - -> **本機能を使用した場合の実装** - -> ```java -> UserEntity entity = new UserEntity(); -> entity.setUserName("ユーザ"); -> -> // 「%」は、SQL文に記述を行うため、Javaコードがなくても実装の確認が行える。 -> // また、escape句はフレームワークで自動挿入されるため、SQL文に記述を行う必要はない。 -> -> ParameterizedSqlPStatement st = dbConnection.prepareParameterizedSqlStatement( -> "SELECT " -> + "USER_ID, " -> + "USER_NAME " -> + "FROM " -> + "USER_MTR " -> + "WHERE " -> + "USER_NAME LIKE :userName%"); -> -> // エスケープ処理は実装する必要がない。 -> st.retrieve(entity); -> ``` - -> **本機能を使用せずに従来のJDBC標準機能の実装(上記の本機能を使用した場合と同じ結果となる実装)** - -> ```java -> String userName = "ユーザ"; -> -> // likeが条件にある場合は、escape句を付ける必要がある。 -> SqlPStatement st = dbConnection.prepareStatement( -> "SELECT " -> + "USER_ID, " -> + "USER_NAME " -> + "FROM " -> + "USER_MTR " -> + "WHERE " -> + "USER_NAME LIKE ? ESCAPE '\\'"); -> -> // 条件はエスケープ処理を行い、「%」を付加する必要がある。 -> st.setString(1, escape(userName) + "%"); -> -> st.retrieve(); -> -> // Oracle用escape処理の内容 -> // 「%」、「％」「_」「＿」「\」をエスケープ文字(\)でエスケープ処理を行う。 -> // エスケープ文字は、SQL文をエスケープ処理 -> private static String escape(String str) { -> return str.replaceAll("(%|％|_|＿|\\\\)", "\\\\$1"); -> } -> ``` - -### 条件が可変のSQL文を組み立てる機能 - -Web機能で多く見られる可変条件(画面で入力された場合のみ、検索条件に含める機能)のSQL文を、自動で生成できる機能を提供する。 -この機能には、下記のメリットがある。 - -* Javaで入力判定を行ない、SQL文を組み立てる必要がない。(生産性が向上する。) -* [Javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能](../../component/libraries/libraries-04-DbAccessSpec.md#javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能) 機能と同様に、オブジェクトのフィールドの値を条件に設定できる。 - -> **Note:** -> 本機能を使用した場合と、従来のJDBC標準機能を使用した場合での実装の違い - -> **本機能を使用した場合の実装** - -> ```java -> Entity entity = new Entity(); -> entity.setUserName(null); -> entity.setUserKanaName("ユーザメイ"); -> -> // 可変となるSQL文の組み立て -> // prepareParameterizedSqlStatementを呼び出し時に、検索条件を持つオブジェクトを指定することで、SQL文の組み立てが行われる。 -> ParameterizedSqlPStatement sqlPStatement = dbConnection.prepareParameterizedSqlStatement( -> "SELECT " -> + "USER_ID, " -> + "USER_NAME, " -> + "USER_KANA_NAME " -> + "FROM " -> + "USER_MST " -> + "WHERE " -> + "$if(userName) {user_name LIKE :userName%} " -> + "AND $if(userKanaName) {user_kana_name LIKE :userKanaName%} ", entity); -> -> // 検索条件を持つオブエジェクトを指定してSQL文の実行 -> SqlResultSet resultSet = sqlPStatement.retrieve(entity); -> System.out.println("resultSet = " + resultSet); -> ``` - -> **本機能を使用せずに従来のJDBC標準機能の実装(この実装は、上記の本機能を使用した場合の実装と同義である)** -> SQL文の組み立てを各プログラムで行う必要があり可読性が非常に悪くなる。 - -> ```java -> String userName = null; -> String userKanaName = "ユーザメイ"; -> -> // 固定部分のSQL文 -> StringBuffer sql = new StringBuffer( -> "SELECT " -> + "USER_ID, " -> + "USER_NAME, " -> + "USER_KANA_NAME " -> + "FROM " -> + "USER_MST "); -> -> // 可変となるSQL文の組み立て -> // 入力のある項目のみ絞り込み条件に設定する。 -> boolean first = true; -> if (userName != null && userName.length() != 0) { -> sql.append(" WHERE USER_NAME LIKE ? ESCAPE '\\'"); -> first = false; -> } -> -> if (userKanaName != null && userKanaName.length() != 0) { -> sql.append(first ? " WHERE " : " AND ").append("USER_KANA_NAME LIKE ? ESCAPE '\\'"); -> first = false; -> } -> -> // バインド変数に入力された値を設定する。 -> // 入力されてた項目のみ値の設定をする。 -> SqlPStatement statement = dbConnection.prepareStatement(sql.toString()); -> int index = 0; -> if (userName != null && userName.length() != 0) { -> statement.setObject(++index, userName); -> } -> if (userKanaName != null && userKanaName.length() != 0) { -> statement.setObject(++index, userKanaName); -> } -> ``` - -### データベーストランザクションのタイムアウト機能 - -本機能は、データベースアクセスに該当トランザクションがトランザクションの有効期限内（トランザクションがタイムアウトしていないこと）のチェックを行う機能を提供する。 -この機能は、以下のメリットがある。 - -この機能は、データベースアクセスで処理遅延(データベースのロック解放待ちやSQL文の応答待ちなど)が発生し、 -トランザクションの有効期限を過ぎた場合に、トランザクションタイムアウトが発生したことを示す例外を送出する。 -これにより、処理遅延の発生した業務処理は強制的に終了されるため、遅延した処理が大量に残存することを防止できる。 - -特に画面処理で本機能を適用した場合、Web Application Server上のデータベース接続プールやリクエスト要求を処理するスレッドが枯渇 [1] することを防ぐことが出来る。 - -データベース接続プールなどが枯渇すると、クライアントからの処理要求はプールの解放待ちとなり、処理遅延が発生した業務処理が終了するまで後続のリクエストは全て待機状態となる。 - -## 注意点 - -### データベース接続のプール機能について - -本機能では、データベース接続のプール機能は提供しない。 -各プロジェクトでプール機能を使用したい場合には、下記のプール機能の有効化方法を参照し、プールの有効化作業を行うこと。 - -**プール機能の有効化方法** - -a) JNDI接続を使用する場合 - -Webアプリケーションサーバに設定するデータベース接続のプール機能を有効にする。 -データベース接続の登録方法、プールの設定方法は、Webアプリケーションサーバのマニュアルを参照すること。 - -b) DataSource接続を使用する場合 - -プール機能を有するDataSource実装クラスを使用する。 - -> **Note:** -> 例えばデータベースがOracleの場合、「oracle.jdbc.pool.OracleDataSource」や「oracle.ucp.jdbc.PoolDataSourceImpl」を使用して -> プール用のプロパティを設定することにより、プール機能を使用することができる。 - -> **Attention:** -> データベースベンダーによっては、プール機能を有するDataSourceが提供されていない可能性がある。詳細は各データベースベンダーのJDBCマニュアルを参照すること。 - -### SQLインジェクション対策について - -一般的にSQLインジェクションに対する対策は、PreparedStatementを使用して入力値 [2] をバインド変数化することと言われている。 -ただし、この対策は各アプリケーションプログラマにルールを徹底させるものであり、対策としては不十分である。 -例えば、 [SQLインジェクションの脆弱性を含んだ実装](../../component/libraries/libraries-04-DbAccessSpec.md#sqlインジェクション対策について) を業務ロジック内で行われた場合、問題を検出することが非常に困難である。 - -この問題への対策として、本機能ではSQL文を外部ファイルに記述する機能を提供する。 -SQL文の外部化機能を使用した場合、業務ロジックではSQL文を参照することができないため、SQL文と入力値 [2] とを文字列連結することを完全に防止することができる。 -これにより、アプリケーションプログラマが [SQLインジェクションの脆弱性を含んだ実装](../../component/libraries/libraries-04-DbAccessSpec.md#sqlインジェクション対策について) を行うことを防ぐことができ、 -SQLインジェクション対策として最も有効な手段となる。 - -※業務ロジックでSQL文実行時に使用する値は、SQL文ではなくSQL文を一意に識別するためのIDとなっている。 - -* SQL文を外部ファイルに記述した場合の例 - - ```java - private final String sqlResource = this.getClass().getName() + "#"; - - public List getUserName(String userId) { - - // ステートメントを生成する際にSQL文ではなくSQLを識別するためのIDを指定する。 - // このため、SQL文を直接編集（文字連結）することができないので、SQLインジェクション対策となる。 - AppDbConnection connection = DbConnectionContext.getConnection(); - connection.prepareStatementBySqlId(sqlResource + "SQL_ID"); - - // 以下省略 - } - ``` - -詳細は、 [推奨するJavaの実装例(SQL文を外部ファイル化した場合)](../../component/libraries/libraries-04-Statement.md#推奨するjavaの実装例sql文を外部ファイル化した場合) を参照すること。 - -* SQLインジェクションの脆弱性を含んだ実装の例 - - > **Warning:** -> このような実装は、SQLインジェクションの可能性があるためすべきではない。 - - ```java - public List getUserName(String userId) { - // 入力値を連結しているため、SQLインジェクションの脆弱性を含んだ実装となる。 - String sql = - "SELECT " - + "USER_NAME" - + "FROM " - + "USER_MTR " - + "WHERE " - + "ID = " + userId; - - AppDbConnection connection = DbConnectionContext.getConnection(); - connection.prepareStatement(sql); - - // 以下省略 - - } - ``` - -入力値とは、ユーザ入力値や外部システムからの連携データの事である。 - -## 要求 - -### 実装済み - -* データベースへの接続ができる。 -* SQL文の実行ができる。 -* SQL文の実行ログの出力ができる。 -* 各種リソース(Connection、Statement、ResultSet)の解放ができる。 -* バイナリ(LOBやBYTE型)型の検索、更新ができる。 -* プリフェッチ(SQLStatement#setFetchSize)ができる。 -* バッチ更新(SQLStatement#addBatch)ができる。 -* 重複エラー等をアプリケーションでハンドリングできる。 -* 共通項目(最終更新者、最終更新日時など)に設定する値を、自動で設定できる。 -* 条件が可変の場合のSQL文が生成できる。 - - * IN句の項目数が可変の場合のSQL文が生成できる。 -* LIKE検索時のエスケープ処理ができる。 -* SQL文を外部ファイルなどに定義でき、Javaコードとは分離できる。 -* データベースアクセス時にトランザクションタイムアウトチェックができる。 - -### 未実装 - -* PL/SQLの実行ができる。 -* 1トランザクション内でのSQL文の実行回数がチェックできる。 -* テーブル更新順序がチェックできる。 -* テーブル更新順序に違反した場合の振る舞い(警告または例外)が指定できる。 -* SQL文の実行ログを指定機能(リクエストID)のみ出力する事ができる。 -* データベース接続パスワードを暗号化して管理できる。 - -## 全体構造 - -### クラス図 - -本機能の全体構造図。各クラスの責務については、以降の章で解説を行う。 - -![DbAccessSpec_AllClassDesign.jpg](../../../knowledge/assets/libraries-04-DbAccessSpec/DbAccessSpec_AllClassDesign.jpg) - -## 各機能単位の構造 - -04/04_Connection - -04/04_Statement - -04/04_ObjectSave - -04/04_TransactionTimeout diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-HttpAccessLog.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-HttpAccessLog.md deleted file mode 100644 index 8104d79ef..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-HttpAccessLog.md +++ /dev/null @@ -1,348 +0,0 @@ -# HTTPアクセスログの出力 - -HTTPアクセスログは、フレームワークが提供するハンドラを使用して出力する。 -アプリケーションでは、ハンドラの設定を行うことでHTTPアクセスログを出力する。 - -リクエストパラメータを含めたリクエスト情報を出力することで、個別アプリケーションの証跡ログの要件を満たせる場合は、 -HTTPアクセスログと証跡ログを兼用することも想定している。 - -## HTTPアクセスログの出力方針 - -HTTPアクセスログで想定している出力方針と出力項目を下記に示す。 -HTTPアクセスログは、アプリケーション全体のログ出力を行うアプリケーションログに出力する。 - -| ログレベル | ロガー名 | -|---|---| -| INFO | HTTP_ACCESS | - -上記出力方針に対するログ出力の設定例を下記に示す。 - -log.propertiesの設定例 - -```bash -writerNames=appFile - -# アプリケーションログの出力先 -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=/var/log/app/app.log -writer.appFile.encoding=UTF-8 -writer.appFile.maxFileSize=10000 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=<アプリケーションログ用のフォーマット> - -availableLoggersNamesOrder=ACC,ROO - -# アプリケーションログの設定 -loggers.ROO.nameRegex=.* -loggers.ROO.level=INFO -loggers.ROO.writerNames=appFile - -# HTTPアクセスログの設定 -loggers.ACC.nameRegex=HTTP_ACCESS -loggers.ACC.level=INFO -loggers.ACC.writerNames=appFile -``` - -## HTTPアクセスログの出力項目 - -HTTPアクセスログの出力項目を下記に示す。 - -| 項目名 | 説明 | -|---|---| -| 出力日時 | ログ出力時のシステム日時。 | -| 起動プロセスID | アプリケーションを起動したプロセス名。実行環境の特定に使用する。 | -| 処理方式区分 | 処理方式の特定に使用する。 | -| リクエストID | 処理を一意に識別するID。 | -| 実行時ID | 処理の実行を一意に識別するID。 | -| ユーザID | ログインユーザのユーザID。 | -| URL | リクエストURL。 | -| ポート番号 | リクエストを受信したサーバの使用ポート。 | -| HTTPメソッド | リクエストの種類（GET、POSTなど）。 | -| セッションID | HTTPセッションのセッションID。 | -| セッションスコープ情報 | セッションスコープ情報のダンプ。 セッションスコープに含まれる個人情報や機密情報は、マスクして出力する。 (マスク用の設定が必要となる。) | -| ディスパッチ先クラス | リクエストのディスパッチ先のクラス名。 | -| リクエストパラメータ | リクエストパラメータのダンプ。 リクエストパラメータに含まれる個人情報や機密情報は、マスクして出力する。 (マスク用の設定が必要となる。) | -| クライアント端末IPアドレス | リクエストを送信したクライアントのIPアドレス。 | -| クライアント端末ホスト | リクエストを送信したクライアントのホスト名。 | -| ステータスコード(内部) | 内部で保持するレスポンスのステータスコード。 [ステータスコードの変換](../../component/handlers/handlers-HttpResponseHandler.md#ステータスコードの変換) で示した HTTPレスポンスハンドラによるステータスコードの変換を行う前のステータスコード を出力する。 レスポンスとして返されるステータスコードの詳細は、 [HTTPエラー制御ハンドラ](../../component/handlers/handlers-HttpErrorHandler.md#httpエラー制御ハンドラ) を参照。 > **Note:** > [HTTPレスポンスハンドラ](../../component/handlers/handlers-HttpResponseHandler.md#httpレスポンスハンドラ) のフォーワード処理でコンテンツパスに > "servlet://" が指定された場合、 > フォワード先のサーブレットで200以外のステータスコードを返却した際も、 > アクセスログには 200 が出力される。 > これは、 JavaEE 5 の仕様上フォワードした先のサーブレットの処理結果を取得 > できない制約により発生したアクセスログの仕様である。 | -| ステータスコード(クライアント) | クライアントに実際に返されるステータスコード。 [ステータスコードの変換](../../component/handlers/handlers-HttpResponseHandler.md#ステータスコードの変換) で示した HTTPレスポンスハンドラによるステータスコードの変換を行った後のステータスコードを出力する。 > **Warning:** > "ステータスコード(クライアント)" の値は、 HTTPアクセスログハンドラの処理の後に > JSP のエラーなどシステムエラーが発生場合、実際の内部コードと異なることがある。 > この場合、システムエラーとして別途障害監視ログが出力されるため、障害監視ログが > 発生した際にはこの値が正しくない可能性があることを考慮してログを検証すること。 | -| コンテンツパス | レスポンスのコンテンツパス。 | -| 開始日時 | 処理の開始日時。 | -| 終了日時 | 処理の終了日時。 | -| 実行時間 | 処理の実行時間（終了日時－開始日時）。 | -| 最大メモリ量(開始時) | 処理の開始時点のヒープサイズ。 | -| 空きメモリ量(開始時) | 処理の開始時点の空きヒープサイズ。 | -| 付加情報 | アプリケーションで追加する付加情報。 | - -HTTPアクセスログの個別項目は、リクエストID、ユーザID、URLから空きメモリ量(開始時)までとなる。 -残りの項目は、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) の設定で指定する共通項目となる。 -共通項目と個別項目を組み合わせたフォーマットについては、 [各種ログの共通項目のフォーマット](../../component/libraries/libraries-01-Log.md#各種ログの共通項目のフォーマット) を参照。 - -リクエストIDとユーザIDは、 [BasicLogFormatter](../../component/libraries/libraries-01-Log.md#basiclogformatter) が出力を提供する共通項目と重複するが、 -HTTPアクセスログのフォーマットの自由度を高めるために個別項目として指定できるようにしている。 - -## HTTPアクセスログの出力方法 - -HTTPアクセスログの出力に使用するクラスを下記に示す。 - -![Log_HttpAccessLog_ClassDiagram.jpg](../../../knowledge/assets/libraries-04-HttpAccessLog/Log_HttpAccessLog_ClassDiagram.jpg) - -| クラス名 | 概要 | -|---|---| -| nablarch.common.web.handler.HttpAccessLogHandler | HTTPアクセスログを出力するハンドラ。 リクエスト処理開始時と終了時のログを出力する。 | -| nablarch.common.web.handler.NablarchTagHandler | Nablarchのカスタムタグ機能に必要なリクエスト処理を行うハンドラ。 [hiddenタグの暗号化](../../component/libraries/libraries-07-FormTag.md#hiddenタグの暗号化) 機能に対応する改竄チェックと復号を行う。 hiddenパラメータ復号後のログを出力する。 | -| nablarch.fw.web.handler.HttpRequestJavaPackageMapping | URI中の部分文字列をJavaパッケージへマッピングすることで動的に委譲先を決定するディスパッチャ。 ディスパッチ先クラス決定後のログを出力する。 | -| nablarch.fw.web.handler.HttpAccessLogUtil | HTTPアクセスログを出力するクラス。 | -| nablarch.fw.web.handler.HttpAccessLogFormatter | HTTPアクセスログの個別項目をフォーマットするクラス。 | - -HTTPアクセスログ出力時の処理シーケンスを下記に示す。 -各ハンドラは、HttpAccessLogUtilを使用してHTTPアクセスログを出力する。 - -![Log_HttpAccessLog_SequenceDiagram.jpg](../../../knowledge/assets/libraries-04-HttpAccessLog/Log_HttpAccessLog_SequenceDiagram.jpg) - -上記処理シーケンスの通り、HTTPアクセスログを出力するには、下記の順番にハンドラを指定する必要がある。 -説明のために省略しているが、NablarchTagHandlerとHttpRequestJavaPackageMappingの間には、データベース接続管理、トランザクション管理、 -認可チェックなど、 [汎用のハンドラ](../../component/handlers/handlers-handler.md#汎用のハンドラ) で記載したハンドラが入る。 - -```bash -ThreadContextHandler - ↓ -HttpAccessLogHandler - ↓ -NablarchTagHandler - ↓ -HttpRequestJavaPackageMapping -``` - -HttpAccessLogHandlerのハンドラキューへの設定例を下記に示す。 -HttpAccessLogHandlerはプロパティを持たないため、HttpAccessLogHandlerへの設定項目は不要である。 - -```xml - - - - - - - - - - - - -``` - -## HTTPアクセスログの設定方法 - -HttpAccessLogUtilは、プロパティファイル(app-log.properties)を読み込み、 -HttpAccessLogFormatterオブジェクトを生成して、個別項目のフォーマット処理を委譲する。 -プロパティファイルのパス指定や実行時の設定値の変更方法は、 [各種ログの設定](../../component/libraries/libraries-01-Log.md#各種ログの設定) を参照。 -HTTPアクセスログの設定例を下記に示す。 - -app-log.propertiesの設定例 - -```bash -# HttpAccessLogFormatter -httpAccessLogFormatter.className=nablarch.fw.web.handler.HttpAccessLogFormatter -httpAccessLogFormatter.beginFormat=> sid = [$sessionId$] @@@@ BEGIN @@@@\n\turl = [$url$]\n\tmethod = [$method$] -httpAccessLogFormatter.parametersFormat=> sid = [$sessionId$] @@@@ PARAMETERS @@@@\n\tparameters = [$parameters$] -httpAccessLogFormatter.dispatchingClassFormat=> sid = [$sessionId$] @@@@ DISPATCHING CLASS @@@@ class = [$dispatchingClass$] -httpAccessLogFormatter.endFormat=< sid = [$sessionId$] @@@@ END @@@@ url = [$url$] status_code = [$statusCode$] content_path = [$contentPath$] -httpAccessLogFormatter.datePattern="yyyy-MM-dd HH:mm:ss.SSS" -httpAccessLogFormatter.maskingChar=# -httpAccessLogFormatter.maskingPatterns=\\.*password\\.*,\\.*mobilePhoneNumber\\.* -httpAccessLogFormatter.parametersSeparator=, -httpAccessLogFormatter.sessionScopeSeparator=, -httpAccessLogFormatter.beginOutputEnabled=true -httpAccessLogFormatter.parametersOutputEnabled=true -httpAccessLogFormatter.dispatchingClassOutputEnabled=true -httpAccessLogFormatter.endOutputEnabled=true -``` - -プロパティの説明を下記に示す。 - -| プロパティ名 | 設定値 | -|---|---| -| httpAccessLogFormatter.className | HttpAccessLogFormatterのクラス名。 HttpAccessLogFormatterクラスを差し替える場合に指定する。 | -| httpAccessLogFormatter.beginFormat | リクエスト処理開始時のログ出力に使用するフォーマット。 | -| httpAccessLogFormatter.parametersFormat | hiddenパラメータ復号後のログ出力に使用するフォーマット。 | -| httpAccessLogFormatter.dispatchingClassFormat | ディスパッチ先クラス決定後のログ出力に使用するフォーマット。 | -| httpAccessLogFormatter.endFormat | リクエスト処理終了時のログ出力に使用するフォーマット。 | -| httpAccessLogFormatter.datePattern | 開始日時と終了日時に使用する日時パターン。 パターンには、java.text.SimpleDateFormatが規程している構文を指定する。 デフォルトは"yyyy-MM-dd HH:mm:ss.SSS"。 | -| httpAccessLogFormatter.maskingPatterns | マスク対象のパラメータ名又は変数名を正規表現で指定する。 複数指定する場合はカンマ区切り。 リクエストパラメータとセッションスコープ情報の両方のマスキングに使用する。 指定した正規表現は、Pattern.CASE_INSENSITIVEを指定してコンパイルする。 コンパイル処理の呼び出しを下記に示す。 ```java Pattern.compile(<指定した正規表現>, Pattern.CASE_INSENSITIVE) ``` | -| httpAccessLogFormatter.maskingChar | マスクに使用する文字。 デフォルトは'*'。 | -| httpAccessLogFormatter.parametersSeparator | リクエストパラメータのセパレータ。 デフォルトは"\\n\\t\\t"。 | -| httpAccessLogFormatter.sessionScopeSeparator | セッションスコープ情報のセパレータ。 デフォルトは"\\n\\t\\t"。 | -| httpAccessLogFormatter.beginOutputEnabled | リクエスト処理開始時の出力が有効か否か。デフォルトはtrue。 falseを指定するとリクエスト処理開始時の出力を行わない。 | -| httpAccessLogFormatter.parametersOutputEnabled | hiddenパラメータ復号後の出力が有効か否か。デフォルトはtrue。 falseを指定するとhiddenパラメータ復号後の出力を行わない。 | -| httpAccessLogFormatter.dispatchingClassOutputEnabled | ディスパッチ先クラス決定後の出力が有効か否か。デフォルトはtrue。 falseを指定するとディスパッチ先クラス決定後の出力を行わない。 | -| httpAccessLogFormatter.endOutputEnabled | リクエスト処理終了時の出力が有効か否か。デフォルトはtrue。 falseを指定するとリクエスト処理終了時の出力を行わない。 | - -フォーマットに指定可能なプレースホルダの一覧とデフォルトのフォーマットを下記に示す。 -フォーマットの改行位置で改行して表示する。 - -### リクエスト処理開始時のログ出力に使用するフォーマット - -プレースホルダ一覧 - -| 項目名 | プレースホルダ | -|---|---| -| リクエストID | $requestId$ | -| ユーザID | $userId$ | -| URL | $url$ | -| ポート番号 | $port$ | -| HTTPメソッド | $method$ | -| セッションID | $sessionId$ | -| リクエストパラメータ | $parameters$ | -| セッションスコープ情報 | $sessionScope$ | -| クライアント端末IPアドレス | $clientIpAddress$ | -| クライアント端末ホスト | $clientHost$ | -| HTTPヘッダのUser-Agent | $clientUserAgent$ | -| リクエストパラメータ | $parameters$ | - -リクエストパラメータは、 [hiddenタグの暗号化](../../component/libraries/libraries-07-FormTag.md#hiddenタグの暗号化) 機能の復号前の状態となる。 - -デフォルトのフォーマット - -```bash -@@@@ BEGIN @@@@ rid = [$requestId$] uid = [$userId$] sid = [$sessionId$] - \n\turl = [$url$] - \n\tmethod = [$method$] - \n\tport = [$port$] - \n\tclient_ip = [$clientIpAddress$] - \n\tclient_host = [$clientHost$] - \n\tparameters = [$parameters$] -``` - -### hiddenパラメータ復号後のログ出力に使用するフォーマット - -プレースホルダ一覧 - -[リクエスト処理開始時のプレースホルダ一覧](../../component/libraries/libraries-04-HttpAccessLog.md#リクエスト処理開始時のログ出力に使用するフォーマット) と同じ。 -ただし、リクエストパラメータは、 [hiddenタグの暗号化](../../component/libraries/libraries-07-FormTag.md#hiddenタグの暗号化) 機能の復号後の状態となる。 - -デフォルトのフォーマット - -```bash -@@@@ PARAMETERS @@@@ - \n\tparameters = [$parameters$] -``` - -### ディスパッチ先クラス決定後のログ出力に使用するフォーマット - -プレースホルダ一覧 - -[リクエスト処理開始時のプレースホルダ一覧](../../component/libraries/libraries-04-HttpAccessLog.md#リクエスト処理開始時のログ出力に使用するフォーマット) に加えて、下記のプレースホルダを指定できる。 -リクエストパラメータは、 [hiddenタグの暗号化](../../component/libraries/libraries-07-FormTag.md#hiddenタグの暗号化) 機能の復号後の状態となる。 - -| 項目名 | プレースホルダ | -|---|---| -| ディスパッチ先クラス | $dispatchingClass$ | - -デフォルトのフォーマット - -```bash -@@@@ DISPATCHING CLASS @@@@ class = [$dispatchingClass$] -``` - -### リクエスト処理終了時のログ出力に使用するフォーマット - -プレースホルダ一覧 - -[リクエスト処理開始時のプレースホルダ一覧](../../component/libraries/libraries-04-HttpAccessLog.md#リクエスト処理開始時のログ出力に使用するフォーマット) に加えて、下記のプレースホルダを指定できる。 -リクエストパラメータは、 [hiddenタグの暗号化](../../component/libraries/libraries-07-FormTag.md#hiddenタグの暗号化) 機能の復号後の状態となる。 - -| 項目名 | プレースホルダ | -|---|---| -| ディスパッチ先クラス | $dispatchingClass$ | -| ステータスコード(内部) | $statusCode$ | -| ステータスコード(クライアント) | $responseStatusCode$ | -| コンテンツパス | $contentPath$ | -| 開始日時 | $startTime$ | -| 終了日時 | $endTime$ | -| 実行時間 | $executionTime$ | -| 最大メモリ量 | $maxMemory$ | -| 空きメモリ量(開始時) | $freeMemory$ | - -デフォルトのフォーマット - -```bash -@@@@ END @@@@ rid = [$requestId$] uid = [$userId$] sid = [$sessionId$] url = [$url$] status_code = [$statusCode$] content_path = [$contentPath$] - \n\tstart_time = [$startTime$] - \n\tend_time = [$endTime$] - \n\texecution_time = [$executionTime$] - \n\tmax_memory = [$maxMemory$] - \n\tfree_memory = [$freeMemory$] -``` - -## HTTPアクセスログの出力例 - -HTTPアクセスログの出力例を下記に示す。 -ユーザ登録を依頼するリクエストの例である。 -パラメータ名にpasswordが含まれるリクエストパラメータは、マスク対象とする。 -HTTPアクセスログの個別項目のフォーマットは、デフォルトのフォーマットを使用する。 - -app-log.propertiesの設定例 - -```xml -# HttpAccessLogFormatterの設定 -httpAccessLogFormatter.maskingChar=# -httpAccessLogFormatter.maskingPatterns=\\.*password\\.* -``` - -log.propertiesの設定例 - -```bash -writerNames=appFile - -# appFile -writer.appFile.className=nablarch.core.log.basic.FileLogWriter -writer.appFile.filePath=./app.log -writer.appFile.encoding=UTF-8 -writer.appFile.maxFileSize=10000 -writer.appFile.formatter.className=nablarch.core.log.basic.BasicLogFormatter -writer.appFile.formatter.format=$date$ -$logLevel$- $loggerName$ [$executionId$] $message$$information$$stackTrace$ - -availableLoggersNamesOrder=ACC - -# ACC -loggers.ACC.nameRegex=HTTP_ACCESS -loggers.ACC.level=INFO -loggers.ACC.writerNames=appFile -``` - -パラメータ名にpasswordを含むパラメータは、HttpAccessLogFormatterの設定で指定した文字にマスクして出力される。 - -```bash -2011-03-03 19:35:47.848 -INFO- ACC [201103031935478480009] @@@@ BEGIN @@@@ rid = [USERS00302] uid = [0000000001] sid = [60174985E7D35DB7B80681107098C426] - url = [http://localhost:8090/action/management/user/UserRegisterAction/USERS00302] - method = [POST] - port = [8090] - client_ip = [127.0.0.1] - client_host = [127.0.0.1] -2011-03-03 19:35:47.848 -INFO- ACC [201103031935478480009] @@@@ PARAMETERS @@@@ - parameters = [{ - users.extensionNumberBuilding = [12], - ugroupSystemAccount.ugroupId = [0000000000], - users.mailAddress = [yamada@sample.co.jp], - systemAccount.loginId = [U03021934], - users.mobilePhoneNumberAreaCode = [090], - users.extensionNumberPersonal = [3456], - users.kanjiName = [山田太郎], - systemAccount.confirmPassword = [########], - systemAccount.useCase = [UC00000000, UC00000001, UC00000002], - users.mobilePhoneNumberCityCode = [1234], - nablarch_token = [UmNDw+Z2nuTQPwsZ], - users.kanaName = [ヤマダタロウ], - systemAccount.newPassword = [########], - users.mobilePhoneNumberSbscrCode = [5678]}] -2011-03-03 19:35:47.848 -INFO- ACC [201103031935478480009] @@@@ DISPATCHING CLASS @@@@ class = [nablarch.sample.management.user.UserRegisterAction] -2011-03-03 19:35:48.362 -INFO- ACC [201103031935478480009] @@@@ END @@@@ rid = [USERS00302] uid = [0000000001] sid = [60174985E7D35DB7B80681107098C426] url = [http://localhost:8090/action/management/user/UserRegisterAction/USERS00302] status_code = [200] content_path = [/management/user/USER-004.jsp] - start_time = [2011-03-03 19:35:47.848] - end_time = [2011-03-03 19:35:48.362] - execution_time = [514] - max_memory = [66650112] - free_memory = [53128512] -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-ObjectSave.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-ObjectSave.md deleted file mode 100644 index ec02fdb1a..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-ObjectSave.md +++ /dev/null @@ -1,371 +0,0 @@ -# オブジェクトのフィールドの値のデータベースへの登録機能(オブジェクトのフィールド値を使用した検索機能) - -本章では、 [Javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能](../../component/libraries/libraries-04-DbAccessSpec.md#javaオブジェクトのフィールドの値を容易にデータベースに登録できる機能) 、 [LIKE検索を簡易的に実装出来る機能](../../component/libraries/libraries-04-DbAccessSpec.md#like検索を簡易的に実装出来る機能) 、 [条件が可変のSQL文を組み立てる機能](../../component/libraries/libraries-04-DbAccessSpec.md#条件が可変のsql文を組み立てる機能) の機能説明を行う。 -本機能を使用した場合、SQL文のバインド変数には「?」ではなく、名前付きの変数名を記述する必要がある。 - -下記は、名前付き変数を使用した場合とJDBCの標準機能を使用した場合のSQL文の記述例である。 - -```sql --- JDBC標準機能の場合 - -INSERT INTO USER_MTR -VALUES (?, ?, ?, ?) - --- 本機能を使用した場合 -INSERT INTO USER_MTR -VALUES (:userId, :userName, :userNameKana, :tel) - --- 部分一致検索の「%」を使用した場合 -SELECT USER_NAME - FROM USER_MTR - WHERE USER_NAME LIKE :userName% - --- 可変条件を定義できる。 -SELECT USER_NAME - FROM USER_MTR - WHERE $if(userName) {USER_NAME LIKE :userName%} -``` - -## クラス図 - -![DbAccessSpec_ObjectStatementClassDesign.jpg](../../../knowledge/assets/libraries-04-ObjectSave/DbAccessSpec_ObjectStatementClassDesign.jpg) - -### 各クラスの責務 - -本章に記載のないインタフェース、クラスは、 [SQL文実行部品の構造とその使用方法](../../component/libraries/libraries-04-Statement.md#sql文実行部品の構造とその使用方法) を参照。 - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| SqlParameterParserFactory | 名前付きバインド変数をもつSQL文を解析するためのオブジェクト(SqlParameterParser)を 取得するンタフェース | -| SqlParameterParser | 名前付きバインド変数をもつSQL文を解析するインタフェース 実装クラスでは、SQL文を解析し下記情報を取得できるようにすること。 * java.sql.PreparedStatementで実行できる形式のSQL文(バインド変数を「?」に置き換えたSQL文) * 名前付きバインド変数のList | -| SqlConvertor | SQL文の変換を行うインタフェース。 | -| AutoPropertyHandler | オブジェクトの自動設定項目のフィールドに値を設定するインタフェース。 実装クラスでは、フィールドのアノテーションやフィールド名等を元に値を自動設定する。 | - -#### クラス定義 - -a) nablarch.core.db.statement.SqlParameterParserFactoryの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| BasicSqlParameterParserFactory | BasicSqlParameterParserを生成するSqlParameterParserFactoryの基本実装クラス。 | - -b) nablarch.core.db.statement.SqlParameterParserの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| BasicSqlParameterParser | SqlParameterParserのBasic実装クラス。 本クラスでは、下記ルールにしたがいSQL文の解析、及びJDBC実行用のSQL文の変換処理を行う。 * 名前付きバインド変数は、コロン(":")で開始され英(大文字、小文字)数字、 アンダースコア("_")、パーセント("%")で構成されている。 * LIKE検索条件の構築 本機能でサポートする部分一致検索のパターンは下記の3パターンとなっている。 > **Note:** > a) 前方一致検索 > バインド変数名の末尾にパーセントを付加する。 > 例：「:userName%」 > b) 後方一致検索の場合 > バインド変数名の先頭にパーセントを付加する。 > 例：「:%userName」 > c) 部分一致検索の場合 > バインド変数名の前後にパーセントを付加する。 > 例：「:%userName%」 > > **Warning:** > > 後方、部分一致検索は、顧客要件で回避不可能である場合に、顧客と下記デメリットを合意した上で使用すること。 > > デメリット > > ``` > > 後方、部分一致検索では、インデックスが使用されずにテーブルフルスキャンとなる。 > > これにより、極端な性能劣化が発生する。 > > ``` * Nablarchの拡張構文が埋め込まれたSQL文をJDBC標準のSQL文に変換する。 デフォルトでは、下記の拡張構文を変換する。 * 可変条件構文 * 可変IN構文 * 可変ORDER BY構文 | - -c) nablarch.core.db.statement.SqlConvertorの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statement.sqlconvertorパッケージ | | -| SqlConvertorSupport | SQL文の変換を行うクラスをサポートするクラス。 バインド変数に対応するフィールドの値を取得する機能を提供する。 | -| VariableConditionSyntaxConvertor | SQL文の可変条件構文を変換するクラス。 可変条件(入力有無によって条件に含めるか否かの条件)は、 $if(フィールド名) {SQL文の条件}となっていること。 可変条件部分を本クラスでは、下記例のようにJDBC実行用のSQL文に変換を行う。 JDBC実行用SQLに変換後のSQL文が不正な場合は、SQL実行時エラーが発生する。 このため変換後のSQL文が、不正なSQL文とならないように本機能独自のSQL文を記述する必要がある。 特に、$if構文が使用できる箇所は条件部分(WHERE句)のみであるため、その他の部分で使用した場合には、 不正なSQL文が生成される原因となる。 以下に例を示す。 ```java public class UserMtr { /** ユーザ名 */ private String userName; /** ユーザ区分 */ private String userKbn; // アクセスメソッドなどは省略 } // 可変条件の部分は、$if(フィールド名) {SQL文の条件}形式で実装する。 // UserMtr#userNameがnull、空文字列以外(配列の場合は、サイズが1以上)の場合には、 // 「user_name = :user_name」が有効な条件となる。 // UserMtr#userKbnがnull、空文字列以外(配列の場合は、サイズが1以上)の場合には、 // 「user_kbn = ('1', '2')」が有効な条件となる。 String sql = "SELECT " + "USER_ID, " + "USER_NAME, " + "USER_KBN " + "FROM " + "USER_MTR " + "WHERE " + "$if (userName) {USER_NAME = :user_name} " + "AND $if (userKbn) {USER_KBN IN ('1', '2')}" //*********************************************************************** // 上記SQL文は、本クラスで、下記の形に変換される。 // 条件に含める場合(フィールドの値がnull以外かつ空文字列 // (配列の場合は、サイズが1以上)以外の場合条件を // 「(0 = 1 or (user_name = ?))」形式に変換する。 // 0 = 1はfalseになるため、必ず(user_name = ?)が評価される。 // // 条件に含めない場合(フィールドの値がnullまたは、 // 空文字列(配列の場合は、サイズが0)の場合条件を // 「(0 = 0 or (user_name = ?))」形式に変換する。 // 0 = 0はtrueになるため、(user_name = ?)は評価されない。 //*********************************************************************** "SELECT " + "USER_ID, " + "USER_NAME, " + "USER_KBN " + "FROM " + "USER_MTR" + "WHERE (0 = 0 OR (USER_NAME = ?))" + "AND (0 = 1) OR (USER_KBN IN ('1', '2'))" //*********************************************************************** // 本クラスで「$if」構文を利用できる箇所は条件部分(WHERE句)のみとなっている。 // また、$ifをネストして利用することはできない。 // このような構文を利用した場合は、本クラスで生成されるJDBC実行用のSQLが // 不正な構文となり、SQL実行時エラーが発生する。 // 以下が、NGとなるSQL文の例である。 //*********************************************************************** // SELECT句で、$if構文を使用しているため不正 "SELECT $if (user) {:user} FROM USER_MTR" // WHERE句で$if構文を使用しているが、ネストしているため不正 "SELECT " + "USER_ID " + "FROM " + "USER_MTR " + "WHERE $if (user) {USER = :user $if(userId) {USER_ID = :userId}}" ``` | -| VariableInSyntaxConvertor | SQL文の可変IN構文を変換するクラス。 IN句の条件部分を動的に生成する場合は、バインド変数名の末尾を角括弧([])で終わらすこと。 角括弧で終了しているバインド変数名は、無条件にIN句の条件項目であると判断し 動的にIN句の構築を行う。 また、IN句のバインド変数名に対応するフィールドのデータタイプは 配列または、Collectionとして定義されている必要がある。 この配列(Collection)の要素数がIN句の条件数となる。 以下に例を示す。 ```java // IN句に対応するフィールドは、配列またはCollectionとして宣言すること。 public class UserSearchCondition { /** ユーザ区分 */ private List userKbn; } // IN区のバインド変数名は、末尾に角括弧([])を付加する。 // IN句と可変条件を合わせて使用する場合には、 // 可変条件の条件部分には角括弧を付加せずに記述する。 String sql = "SELECT " + "USER_ID, " + "USER_NAME, " + "USER_KBN " + "FROM " + "USER_MTR " + "WHERE " + "$if (userKbn) {USER_KBN IN (:userKbn[])}"; // 上記のSQL文に、['1', '2']をもつListを設定した場合。 // 条件部分は、「(0 = 1 OR (USER_KBN IN (?, ?)))」と変換される。 // 上記のSQL文に、サイズ0のListを設定した場合、 // 条件部分は、「(0 = 0 OR (USER_KBN IN (?)))」と変換される。 // この場合、条件部分には固定で"null"が設定される。 ``` > **Note:** > IN句の条件数は、データベースベンダーによって上限が設けられている。 > 各アプリケーションでは、この上限を超えることがないように設計を行うこと。 > **Warning:** > IN句の拡張構文は、本機能は、検索条件のオブジェクトにMapインタフェースの実装クラスを指定することは出来ない。 > なぜなら、Mapは値に対する型情報が存在しないため、IN句を構築する際に値が配列またはCollectionであることの > チェックが確実に行えないためである。 > これは、テスト時に確実に型チェックを行えないことを意味し(例えば値がnullの場合は、その型が何かは実行時にはわからない)、 > 予期せぬ不具合の温床となるため本フレームワークでは敢えてMapの使用を制限している。 > **Warning:** > IN句の条件項目に設定する配列(Collection)がnullや要素数が0になる可能性がある場合は、 > 必ず可変条件と組み合わせて使用すること。 > 可変条件としなかった場合に、サイズ0の配列(Collection)やnullのオブジェクトを設定した場合、 > 条件が「IN (null)」となり、想定したデータが取得できない可能性がある。 > ※IN句は、条件式(カッコの中)を空にすることはできないため、サイズ0の配列やnullが指定された場合は、 > 条件式を「IN (null)」とする仕様としている。 > **Warning:** > IN句以外の箇所に、IN句用のバインド変数を設定しないこと。 > IN句以外の箇所に指定されていた場合、不正なSQL文が生成されSQL実行時エラーとなる。 > 不正な例: > ``` > 条件:USER_ID = :userId[] > フィールド値:["00001", "00002"] > 生成されるSQL文:USER_ID = ?, ? > ``` * リテラル部分に名前付きバインド変数と同じ形式の文字列が記述されていてもバインド変数として扱わない。 * リテラル文字は、シングルクォート("'")で囲われている。 * リテラル文字のエスケープ文字は、シングルクォート("'")である。 * SQL文にコメントが存在しない。 > **Warning:** > 本クラスでは、SQL文の妥当性のチェックは行わない。 > このため、不正な構文のSQL文があった場合には、SQL文実行時に例外が発生する。 | -| VariableOrderBySyntaxConvertor | SQL文の可変ORDER BY構文を変換するクラス。 可変ORDER BY構文の仕様は下記のとおり。 書き方: ``` $sort(フィールド名) {(ケース1)(ケース2)・・・(ケースn)} フィールド名: 検索条件オブジェクトからソートIDを取得する際に使用するフィールド名を表す。 ケース: ORDER BY句の切り替え候補を表す。 候補を一意に識別するソートIDとORDER BY句に指定する文字列(以降はケース本体と称す)を記述する。 どの候補にも一致しない場合に使用するデフォルトのケースには、ソートIDに"default"を指定する。 ``` ケース部分の仕様は下記のとおり。 * 各ケースは、ソートIDとケース本体を半角丸括弧で囲んで表現する。 * ソートIDとケース本体は、半角スペースで区切る。 * ソートIDには半角スペースを使用不可とする。 * ケース本体には半角スペースを使用できる。 * 括弧開き以降で最初に登場する文字列をソートIDとする。 * ソートID以降で括弧閉じまでの間をケース本体とする。 * ソートIDおよびケース本体はトリミングする。 検索条件オブジェクトからフィールド名で指定された値を取得し、 取得した値が一致するケースのケース本体をORDER BY句としてSQL文に追加する。 取得した値が一致するケースが存在しない、かつデフォルトのケースが存在する場合は、 デフォルトのケース本体をORDER BY句としてSQL文に追加する。 取得した値が一致するケースが存在しない、かつデフォルトのケースも存在しない場合は、 可変ORDER BY構文を削除しただけのSQL文を返す。 以下に例を示す。 ```java public class UserMtr { /** ユーザ名 */ private String userName; /** 可変ORDER BYのソートID */ private String sortId; // アクセスメソッドなどは省略 } // 可変ORDER BYの部分は、$sort(フィールド名) {(ケース1) (ケース2)・・・(ケースn)}形式で実装する。 String sql = "SELECT " + "USER_ID, " + "USER_NAME, " + "FROM " + "USER_MTR " + "WHERE " + "USER_NAME = :user_name " + "$sort(sortId) {(1 USER_ID ASC) (2 USER_ID DESC) (3 USER_NAME ASC) (4 USER_NAME DESC) (default USER_ID)}"; //*********************************************************************** // 上記SQL文に対するORDER BY句の変換例を下記に示す。 // // UserMtr#sortId -> 変換後のORDER BY句 // null -> ORDER BY USER_ID ・・・(デフォルトのケースが使用される) // 1 -> ORDER BY USER_ID ASC // 2 -> ORDER BY USER_ID DESC // 3 -> ORDER BY USER_NAME ASC // 4 -> ORDER BY USER_NAME DESC // 5 -> ORDER BY USER_ID ・・・(デフォルトのケースが使用される) //*********************************************************************** ``` > **Warning:** > 本クラスでは、SQL文の妥当性のチェックは行わない。 > このため、不正な構文のSQL文があった場合には、SQL文実行時に例外が発生する。 | - -d) nablarch.core.db.statement.AutoPropertyHandlerの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statement.autopropertyパッケージ | | -| FieldAnnotationHandlerSupport | フィールドのアノテーション情報を元に値を設定するクラスをサポートするクラス。 | -| CurrentDateTimeAnnotationHandler | nablarch.core.db.statement.autoproperty.CurrentDateTimeアノテーションが 設定されているフィールドにシステム日時を設定するクラス。 システム日時は、下記ルールで設定される。 \| フィールドのデータ型 \| 設定方法 \| \|---\|---\| \| java.sql.Date \| システム日時をjava.sql.Dateに変換して設定する。 \| \| Timestamp \| システム日時をjava.sql.Timestampに変換して設定する。 \| \| Time \| システム日時をjava.sql.Timeに変換して設定する。 \| \| String \| CurrentDateTimeのformatプロパティに設定されている値で、 SimpleDateFormatを使用してフォーマットした値を設定する。 formatプロパティが指定されていない場合は、 [設定ファイル](../../component/libraries/libraries-04-ObjectSave.md#設定ファイル例) に記述されたデフォルトのフォーマットを使用する。 \| \| Integer \| \| \| Long \| \| > **Note:** > システム日時は、 [システム日時機能](../../component/libraries/libraries-06-SystemTimeProvider.md#システム日時機能) を使用して取得する。 | -| UserIdAnnotationHandler | nablarch.core.db.statement.autoproperty.UserIdアノテーションが 設定されているフィールドにユーザIDを設定するクラス。 ユーザIDは、ThreadContextから取得する。 > **Note:** > ThreadContextに設定されるユーザIDについては、 [同一スレッド内でのデータ共有(スレッドコンテキスト)](../../component/libraries/libraries-thread-context.md#同一スレッド内でのデータ共有スレッドコンテキスト) を参照 | -| RequestIdAnnotationHandler | nablarch.core.db.statement.autoproperty.RequestIdアノテーションが 設定されているフィールドにリクエストIDを設定するクラス。 リクエストIDは、ThreadContextから取得する。 > **Note:** > ThreadContextに設定されるリクエストIDについては、 [同一スレッド内でのデータ共有(スレッドコンテキスト)](../../component/libraries/libraries-thread-context.md#同一スレッド内でのデータ共有スレッドコンテキスト) を参照 | - -e) オブジェクトのフィールドの値をデータベースに登録するためのクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statement.autopropertyパッケージ | | -| FieldAndAnnotationLoader | オブジェクトに定義されたフィールド情報とフィールドのアノテーション情報をロードするクラス。 このクラスでロードした値は、オブジェクトのフィールドの値をSQL文のバインド変数にセットする際に 使用される。 なお、ロードした値は、 [静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md) を使用してキャッシュされるため、 同一のクラスに対してフィールド情報の取得処理が複数回実行されることはない。 これにより、リフレクションを使用してフィールド情報を取得する再のコストを 軽減でき性能劣化を防止することができる。 | - -## 使用例 - -### 処理シーケンス - -本章では、オブジェクトのフィールドの値をデータベースに登録する場合のシーケンス、実装例について解説を行う。 - -![DbAccessSpec_ObjectStatementSequence.jpg](../../../knowledge/assets/libraries-04-ObjectSave/DbAccessSpec_ObjectStatementSequence.jpg) - -#### 処理概要 - -No1.登録対象のオブジェクトを生成し、必要な情報を設定する。 - -ユーザID、システム日時アノテーションが設定されているフィールドには値を設定する必要はない。 - -No2.AppDbConnection#prepareParameterizedSqlStatementを呼び出し、SQL文実行用のstatementを取得する。 - -SQL文のバインド変数部分には、JDBC標準の「?」を記述するのではなく名前付き変数名を記述する。 -ここで指定された名前付き変数名をもつSQL文は、BasicSqlParameterParserで解析が行われJDBC標準機能で実行可能な下記情報が取得される。 - -* JDBC標準のSQL文(名前付きバインド変数名を、「?」に置き換えたSQL文) -* バインド変数「?」に対応するバインド変数名 - -> **Note:** -> BasicSqlParameterParserの仕様に付いては、 BasicSqlParameterParserの概要 を参照すること。 -> BasicSqlParameterParserの仕様では不十分な場合は、 [SqlParameterParser](../../component/libraries/libraries-04-ObjectSave.md#nablarchcoredbstatementパッケージ) の実装クラスを追加し、実装を置き換えて使用すること。 - -No3.BasicSqlPStatement#executeUpdateByObjectを呼び出しオブジェクトのフィールドの値を登録する。 - -No4.オブジェクトのフィールドの値に自動設定値を設定する。 - -2でexecuteUpdateByObjectに設定されたオブジェクトに対して、フィールドに対して自動設定値を設定する。 -以下が、自動設定項目を示すアノテーションである。 - -| アノテーション名 | 概要 | -|---|---| -| @UserId | UserIdAnnotationHandlerによって、ユーザIDが設定される。 | -| @CurrentDateTime | CurrentDateTimeAnnotationHandlerによって、システム日時が設定される。 | -| @RequestId | RequestIdAnnotationHandlerによって、リクエストIDが設定される。 | - -※自動設定値の取得元は、 [AutoPropertyHandlerの実装クラスのクラス概要](../../component/libraries/libraries-04-ObjectSave.md#nablarchcoredbstatementsqlconvertorパッケージ) を参照すること。 - -No5.SQL文を実行する。 - -オブジェクトのフィールドの値をバインド変数に設定し、SQL文を実行する。 -バインド変数への設定は、PreparedStatement#setObjectを使用して行う。 -フィールドの値が不正な値(データベースへ登録できない値)の場合には、SQL文の実行時例外が発生する。 - -> **Note:** -> 使用するハンドラクラスを追加や変更することにより、各プロジェクトで作成したアノテーションやカラム名で自動設定項目を判断する事もできる。 - -### Java実装例(Objectのフィールド値を登録する場合) - -```java -// オブジェクトの実装 -public class MyEntity { - // 顧客ID - private String cstId; - - // 金額 - private long kingaku; - - // 登録日時 - @CurrentDateTime(format="yyyyMMddHHmmss") - private String insDateTime; - - // 登録ユーザID - @UserId - private String insUserId; - - // 更新日時 - @CurrentDateTime(format="yyyyMMddHHmmss") - private String updDateTime; - - // 更新ユーザID - @UserId - private String updUserId; - - // リクエストID - @RequestId - private String requestId; - - // 本来はここに各フィールドのアクセスメソッドを定義する。 - -} - -// Entityを生成し、自動設定項目以外を設定する。 -MyEntity entity = new MyEnitity(); -entity.setCstId("1000000001"); -entity.setKingaku(1000); - -AppDbConnection perCon = DbConnectionContext.getConnection(); - -// 指定するSQL文のバインド変数部分には、「?」を設定するのではなく、「:」＋「オブジェクトのフィールド名」とすること。 -ParameterizedSqlPStatement insert = perCon.prepareParameterizedSqlStatement( - "INSERT INTO " - + "MY_TABLE " - + "(" - + "CST_ID, " - + "KINGAKU, " - + "INS_DATE_TIME, " - + "INS_USER_ID, " - + "UPD_DATE_TIME, " - + "UPD_USER_ID, " - + "EXECUTION_ID, " - + "REQUEST_ID" - + ")" - + "VALUES" - + "(" - + ":cstId, " - + ":kingaku, " - + ":insDateTime, " - + ":insUserId, " - + ":updDateTime, " - + ":updUserId, " - + ":executionId, " - + ":requestId)"); -insert.executeUpdateByObject(entity); -``` - -> **Note:** -> 本フレームワークではSQL文を外部化(外部ファイルに記述)することを推奨している。 -> SQL外部化した場合のの実装例は、 [推奨するJavaの実装例(SQL文を外部ファイル化した場合)](../../component/libraries/libraries-04-Statement.md#推奨するjavaの実装例sql文を外部ファイル化した場合) を参照すること。 - -## 設定ファイル例 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -### 設定内容詳細 - -a) StatementFactoryの設定 - -| property名 | 設定内容 | -|---|---| -| sqlParameterParserFactory(必須) | nablarch.core.db.statement.SqlParameterParserFactoryを実装したクラスの設定を行う。 本サンプルでは、「nablarch.core.db.statement.BasicSqlParameterParserFactory」を設定している。 | -| objectFieldCache(必須) | nablarch.core.cache.StaticDataCacheを実装したクラスの設定を行う。 本サンプルでは、component名:fieldAnnotationCacheへの参照を設定している。 | -| updatePreHookObjectHandlerList(必須) | nablarch.core.ObjectHandlerを実装したクラスをListで設定を行う。 本サンプルでは、本機能で提供する下記の実装クラスを設定している。 * nablarch.core.db.statement.autoproperty.CurrentDateTimeAnnotationHandler * nablarch.core.db.statement.autoproperty.UserIdAnnotationHandler * nablarch.core.db.statement.autoproperty.RequestIdAnnotationHandler | -| likeEscapeChar(必須) | LIKE条件の文字列のエスケープに使用するエスケープ文字を設定する。ここで設定した値は、LIKE条件を持つSQL文に自動で設定される。 本設定値の指定がない場合は、デフォルトで「\\」がエスケープ文字として使用される。 また、この設定値は「likeEscapeTargetCharList」で指定がなくても自動でエスケープが行われる。 | -| likeEscapeTargetCharList(必須) | LIKE条件の文字列の中でエスケープが必要となる文字をカンマ(,)区切りで設定する。 本設定値の指定がない場合は、デフォルトで「%」、「_」がエスケープ対象の文字となる。 | - -a)-1.BasicSqlParameterParserFactoryへの設定 - -| property名 | 設定内容 | -|---|---| -| sqlConvertors | SqlConvertorの実装クラスをlistコンポーネントとして設定する。 本設定を省略した場合は、以下のSqlConvertor実装クラスがデフォルトの設定として使用される。 * VariableConditionSyntaxConvertor * VariableInSyntaxConvertor * VariableOrderBySyntaxConvertor | - -a)-2.VariableConditionSyntaxConvertorへの設定 - -| property名 | 設定内容 | -|---|---| -| allowArrayEmptyString | 配列(Collection)の要素数が1で、その要素の値が空文字列かnullの場合に条件に含めるか否かを設定する。 falseを設定した場合には、配列(Collection)の要素数が1で、その要素の値が空文字列またはnullの場合には、 $if構文から実行用SQLの変換時に該当の条件を除外するように「(0 = 0) or」条件を付加する。 本設定を省略した場合の設定値は「true」となる。このため設定を省略した場合は、「true」を設定した時と同じ動作となり、 配列(Collection)の要素数が1で、その要素の値が空文字列またはnullの場合であっても条件から除外されることはない。 > **Note:** > 画面アプリケーションのでは、リクエストパラメータとしてキーが存在していて値が空文字列の場合、 > 精査後に生成されるオブジェクトが持つプロパティの配列サイズは1となり、その値は空文字列となる。 > この場合、値が送信されていないため$if構文の条件を除外する事が正しい動作となる。 > このため本プロパティには「false」を設定する必要がある。 > 逆にバッチ処理では、条件の配列に要素が存在する場合は必ず条件に含める必要があるため、 > 本設定値には「true(デフォルト値)」を設定すること。 | - -a)-3.VariableInSyntaxConvertorへの設定 - -本クラスは、プロパティを持たないため特に設定は不要である。 - -a)-4.VariableOrderBySyntaxConvertorへの設定 - -本クラスは、プロパティを持たないため特に設定は不要である。 - -b) フィールドに自動で値を設定するコンポーネントの設定 - -b)-1.CurrentDateTimeAnnotationHandlerの設定 - -| property名 | 設定内容 | -|---|---| -| dateFormat(必須) | デフォルトの日付フォーマットを指定する。指定できるフォーマット形式は、java.text.SimpleDateFormatに準拠する。 このフォーマットはCurrentDateTimeAnnotationHandlerで、フィールドにシステム日時を設定する際に使用される。 | -| dateProvider(必須) | システム日付を取得するためのクラスを設定する。 本サンプルでは、「nablarch.core.date.BasicSystemTimeProvider」を設定している。 | -| fieldAnnotationCache(必須) | nablarch.core.cache.StaticDataCacheを実装したクラスの設定を行う。 本サンプルでは、component名:fieldAnnotationCacheへの参照を設定している。 | - -b)-2.UserIdAnnotationHandlerの設定 - -| property名 | 設定内容 | -|---|---| -| fieldAnnotationCache(必須) | nablarch.core.cache.StaticDataCacheを実装したクラスの設定を行う。 本サンプルでは、component名:fieldAnnotationCacheへの参照を設定している。 | - -b)-3.RequestIdAnnotationHandlerの設定 - -| property名 | 設定内容 | -|---|---| -| fieldAnnotationCache(必須) | nablarch.core.cache.StaticDataCacheを実装したクラスの設定を行う。 本サンプルでは、component名:fieldAnnotationCacheへの参照を設定している。 | - -b)-4.FieldAnnotationHandlerSupportのサブクラス(CurrentDateTimeAnnotationHandlerやUserIdAnnotationHandlerなど)から参照されるBasicStaticDataCacheの設定 - -| property名 | 設定内容 | -|---|---| -| loader(必須) | nablarch.core.db.statement.autoproperty.FieldAndAnnotationLoaderを設定する。 > **Attention:** > 本プロパティには、必ず「nablarch.core.db.statement.autoproperty.FieldAndAnnotationLoader」を設定すること。 > これは、FieldAndAnnotationLoaderを使用しているクラスと密結合になっているためである。 > 本来は、この設定は不変であるため設定ファイルに記述する必要はないが、StaticDataCacheの実装クラスの > BasicStaticDataCacheを置き換える可能性があるため設定ファイルに記述を行うようにしている。 | - -> **Attention:** -> 下記のコンポーネントはpropertyのref属性を使用して同一のBasicStaticDataCacheを参照すること。 - -> * > BasicStatementFactory -> * > CurrentDateTimeAnnotationHandler -> * > UserIdAnnotationHandler -> * > RequestIdAnnotationHandler - -> 別々のBasicStaticDataCacheを設定した場合、まったく同じ情報が別々のメモリ上にキャッシュされ、不必要にメモリを消費してしまう。 -> これにより、メモリ不足が発生しシステムに重大な影響を与える可能性がある。 - -c) initializerの設定 - -本機能で使用する、BasicStaticDataCacheを初期化する設定を行う。 -initializerの詳細な設定方法は、 [リポジトリ](../../component/libraries/libraries-02-Repository.md) を参照すること。 diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Permission.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Permission.md deleted file mode 100644 index d97f88459..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Permission.md +++ /dev/null @@ -1,459 +0,0 @@ -# 認可 - -## 概要 - -リクエストに対して認可チェックを行う機能を提供する。 - -本機能は、ハンドラとして使用されることを想定している。詳細は [認可制御ハンドラ](../../component/handlers/handlers-PermissionCheckHandler.md) を参照すること。 - -通常アーキテクトが本機能を使用して実装を行い認可処理を局所化するため、アプリケーションプログラマは本機能を直接使用しない。 - -## 特徴 - -### グループ単位とユーザ単位を併用した権限設定 - -グループに対して権限を設定し、ユーザにグループを設定することで、グループ単位の権限を設定することができる。 -さらに、ユーザに直接権限を設定することもできるため、イレギュラーな権限付与に対応することができる。 - -### 自由度の高いテーブル定義 - -テーブル名・カラム名を自由に付けることができ、カラムのデータ型についてもフレームワークが規定するJavaの型に変換可能であれば任意のデータ型を使用できる。 -そのため、個別アプリケーションは、プロジェクトの命名規約を使用して、本機能に必要なテーブル定義を作成することができる。 - -## 要求 - -### 実装済み - -* 機能（任意のリクエストのかたまり）単位で認可判定の設定を行うことができる。 -* ユーザに対してグループを設定することができ、グループ単位で認可判定の設定を行うことができる。 -* リクエストIDを設定し、特定のリクエストIDを認可判定の対象から除外できる。 -* ユーザに有効日（From/To）を設定できる。 -* ユーザとグループの関連に有効日（From/To）を設定できる。 -* 認可判定の結果に応じて画面項目（メニューやボタンなど）の表示・非表示を切り替えることができる。 - -### 未実装 - -* 本機能で使用するマスタデータをメンテナンスできる。 -* 本機能で使用するマスタの初期データを一括登録できる。 -* 認証機能によりユーザIDがロックされているユーザの認可判定を失敗にできる。 - -### 未検討 - -* データへのアクセスを制限できる。 -* 機能単位の権限に有効日（From/To）を設定できる。 - -## 構成 - -### 概念モデル - -認可情報の概念モデルを下記に示す。 -本機能では、リクエストIDを使用して認可判定を行う。リクエストIDの体系は、アプリケーション毎に設計する。 - -![Permission_ConceptualModel.jpg](../../../knowledge/assets/libraries-04-Permission/Permission_ConceptualModel.jpg) - -本機能では、ユーザが機能として認識する最小単位の概念として、認可単位という用語を使用する。 - -認可単位とリクエストの関係を下記に示す。 - -![Permission_Unit.jpg](../../../knowledge/assets/libraries-04-Permission/Permission_Unit.jpg) - -この例では、社員登録は入力画面→確認画面→完了画面、社員検索は検索画面→検索結果画面と画面遷移することを想定している。 -認可単位には、認可を実現するために必要なリクエスト（Webアプリケーションであれば画面のイベント）が複数紐付く。 - -グループに認可単位を紐付けることでグループ権限、ユーザに認可単位を直接紐付けることでユーザ権限を表す。 -グループ権限とユーザ権限の例を下記に示す。 - -![Permission_Authority.jpg](../../../knowledge/assets/libraries-04-Permission/Permission_Authority.jpg) - -| ユーザ | 説明 | -|---|---| -| Aさん | 人事部グループに紐づいているので、社員登録・社員削除・社員検索・社員情報変更を使用できる。 | -| Bさん | 社員グループに紐づいているので、社員検索・社員情報変更を使用できる。 | -| Cさん | パートナーグループに紐づいているので、社員情報変更のみ使用できる。 | -| Xさん | 部長グループと社員グループに紐づいているので、社員登録・社員削除・社員検索・社員情報変更を使用できる。 | -| Yさん | 社員グループに紐づいているので、社員検索・社員情報変更を使用できる。 さらにDさんは、社員登録認可単位に直接紐づいているので、社員登録も使用できる。 > **Note:** > Yさんのようにグループ権限とユーザ権限が異なる場合は、 > 双方の権限に紐づく認可単位が足し合わされる。 | - -> **Note:** -> 通常は、認可情報のメンテナンス性を考慮して、グループ権限を登録し、ユーザにグループを割り当てることで権限の設定を行う。 -> ユーザに直接認可単位を紐付けるユーザ権限は、イレギュラーな権限付与に対応するために使用する。 - -### クラス図 - -![Permission_ClassDiagram.jpg](../../../knowledge/assets/libraries-04-Permission/Permission_ClassDiagram.jpg) - -#### 各クラスの責務 - -##### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.common.permission.Permission | 認可を行うインタフェース。 認可判定の実現方法毎に本インタフェースの実装クラスを作成する。 | -| nablarch.common.permission.PermissionFactory | Permissionを生成するインタフェース。 認可情報の取得先毎に本インタフェースの実装クラスを作成する。 | - -##### クラス定義 - -a) nablarch.common.permission.Permissionの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.common.permission.BasicPermission | 保持しているリクエストIDを使用して認可を行うPermissionの基本実装クラス。 | - -b) nablarch.common.permission.PermissionFactoryの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.common.permission.BasicPermissionFactory | BasicPermissionを生成するPermissionFactoryの基本実装クラス。 データベース上のユーザ及びユーザが属するグループ毎に使用できる 認可単位を保持したテーブル構造から、ユーザに紐付く認可情報を取得する。 | - -c) その他のクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.common.handler.PermissionCheckHandler | 認可判定を行うハンドラ。 | -| nablarch.common.permission.PermissionUtil | 権限管理に使用するユーティリティ。 | - -### シーケンス図 - -本機能のシーケンス図を下記に示す。 - -* PermissionCheckHandlerは、リクエストの度にユーザに紐付くPermissionを取得し、認可判定を行った後、Permissionをスレッドローカルに格納する。 -* 個別アプリケーションにおいて認可判定が必要な場合は、PermissionUtilからPermissionを取得して認可判定を行う。 -* 認証機能によりユーザIDがロックされている場合は認可失敗となる。 -* 認可判定の対象リクエストのチェックには、設定で指定されたリクエストIDを使用して行う。設定方法は、 [特定のリクエストIDを認可判定の対象から除外する方法](../../component/libraries/libraries-04-Permission.md#特定のリクエストidを認可判定の対象から除外する方法) を参照のこと。 -* ユーザIDとリクエストIDは、PermissionCheckHandlerよりも先に処理を行うハンドラにより、ThreadContextに設定しておく必要がある。ThreadContextへの設定は、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) が行う。 - -![Permission_SequenceDiagram.jpg](../../../knowledge/assets/libraries-04-Permission/Permission_SequenceDiagram.jpg) - -### テーブル定義 - -本機能で使用するテーブル定義を下記に示す。 - -テーブル名、カラム名は、後述するBasicPermissionFactoryの設定で指定するので、任意の名前を使用できる。 -データベースの型についても、表のJavaの型に変換可能な型であれば、任意の型を使用できる。 - -#### グループ - -グループテーブルには、グループ情報を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| グループID | java.lang.String | ユニークキー | - -#### システムアカウント - -システムアカウントテーブルには、アカウント情報を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| ユーザID | java.lang.String | ユニークキー | -| ユーザIDロック | boolean | | -| 有効日(From) | java.lang.String | 書式 yyyyMMdd 指定しない場合は"19000101" | -| 有効日(To) | java.lang.String | 書式 yyyyMMdd 指定しない場合は"99991231" | - -#### グループシステムアカウント - -グループシステムアカウントテーブルには、グループとシステムアカウントの関連情報を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| グループID | java.lang.String | ユニークキー | -| ユーザID | java.lang.String | ユニークキー | -| 有効日(From) | java.lang.String | ユニークキー 書式 yyyyMMdd 指定しない場合は"19000101" | -| 有効日(To) | java.lang.String | 書式 yyyyMMdd 指定しない場合は"99991231" | - -#### 認可単位 - -認可単位には、認可単位情報を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| 認可単位ID | java.lang.String | ユニークキー | - -#### 認可単位リクエスト - -認可単位リクエストテーブルには、認可単位とリクエストの関連情報を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| 認可単位ID | java.lang.String | ユニークキー | -| リクエストID | java.lang.String | ユニークキー | - -#### グループ権限 - -グループ権限テーブルには、グループと認可単位の関連情報を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| グループID | java.lang.String | ユニークキー | -| 認可単位ID | java.lang.String | ユニークキー | - -#### システムアカウント権限 - -システムアカウント権限テーブルには、システムアカウントと認可単位の関連情報を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| ユーザID | java.lang.String | ユニークキー | -| 認可単位ID | java.lang.String | ユニークキー | - -#### テーブル定義の例 - -* システムアカウントテーブルは、認証機能と同じテーブルを使用することを想定しているので、認証機能で使用するデータ項目（パスワード等）が含まれている。 - -![Permission_ERDiagram.jpg](../../../knowledge/assets/libraries-04-Permission/Permission_ERDiagram.jpg) - -## 使用方法 - -使用方法について解説する。 - -### BasicPermissionFactoryの設定方法 - -本機能では、DIコンテナの機能を使用して、PermissionCheckHandlerとBasicPermissionFactoryの設定を行い使用する。 -DIコンテナの機能については、 [リポジトリ](../../component/libraries/libraries-02-Repository.md) を参照すること。 - -PermissionCheckHandlerとBasicPermissionFactoryの設定例を下記に示す。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -BasicPermissionFactoryの設定では、複数テーブルのスキーマ情報を指定する。 -設定が煩雑にならないように、テーブル毎にスキーマ情報を格納するクラスを設けている。 -スキーマ情報を格納するクラスを下記に示す。 - -| クラス名 | 概要 | -|---|---| -| nablarch.common.permission.schema.GroupTableSchema | グループテーブルのスキーマ情報を保持するクラス。 | -| nablarch.common.permission.schema.SystemAccountTableSchema | システムアカウントテーブルのスキーマ情報を保持するクラス。 | -| nablarch.common.permission.schema.GroupSystemAccountTableSchema | グループシステムアカウントテーブルのスキーマ情報を保持するクラス。 | -| nablarch.common.permission.schema.PermissionUnitTableSchema | 認可単位テーブルのスキーマ情報を保持するクラス。 | -| nablarch.common.permission.schema.PermissionUnitRequestTableSchema | 認可単位リクエストテーブルのスキーマ情報を保持するクラス。 | -| nablarch.common.permission.schema.GroupAuthorityTableSchema | グループ権限テーブルのスキーマ情報を保持するクラス。 | -| nablarch.common.permission.schema.SystemAccountAuthorityTableSchema | システムアカウント権限テーブルのスキーマ情報を保持するクラス。 | - -プロパティの説明を下記に示す。 - -#### PermissionCheckHandlerの設定 - -| property名 | 設定内容 | -|---|---| -| permissionFactory(必須) | Permissionを生成するPermissionFactory。 | -| ignoreRequestIds | 認可判定を行わないリクエストID。 複数指定する場合はカンマ区切り。 | - -#### BasicPermissionFactoryの設定 - -| property名 | 設定内容 | -|---|---| -| dbManager(必須) | データベースへのトランザクション制御を行うSimpleDbTransactionManager。 nablarch.core.db.transaction.SimpleDbTransactionManagerクラスのインスタンスを指定する。 SimpleDbTransactionManagerについては、 [データベースアクセス(検索、更新、登録、削除)機能](../../component/libraries/libraries-04-DbAccessSpec.md) を参照すること。 | -| groupTableSchema(必須) | グループテーブルのスキーマ情報。GroupTableSchemaクラスのインスタンス。 | -| systemAccountTableSchema(必須) | システムアカウントテーブルのスキーマ情報。SystemAccountTableSchemaクラスのインスタンス。 | -| groupSystemAccountTableSchema(必須) | グループシステムアカウントテーブルのスキーマ情報。GroupSystemAccountTableSchemaクラスのインスタンス。 | -| permissionUnitTableSchema(必須) | 認可単位テーブルのスキーマ情報。PermissionUnitTableSchemaクラスのインスタンス。 | -| permissionUnitRequestTableSchema(必須) | 認可単位リクエストテーブルのスキーマ情報。PermissionUnitRequestTableSchemaクラスのインスタンス。 | -| groupAuthorityTableSchema(必須) | グループ権限テーブルのスキーマ情報。GroupAuthorityTableSchemaクラスのインスタンス。 | -| systemAccountAuthorityTableSchema(必須) | システムアカウント権限テーブルのスキーマ情報。SystemAccountAuthorityTableSchemaクラスのインスタンス。 | -| businessDateProvider(必須) | 業務日付の取得に使用するBusinessDateProvider。 nablarch.core.date.BusinessDateProviderインタフェースを実装したクラスのインスタンスを指定する。 業務日付は、有効日（From/To）のチェックに使用する。 業務日付の詳細は、 [業務日付機能](../../component/libraries/libraries-06-SystemTimeProvider.md#業務日付機能) を参照すること。 | - -#### GroupTableSchema（グループ）の設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| groupIdColumnName(必須) | グループIDカラムの名前。 | - -#### SystemAccountTableSchema（システムアカウント）の設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| userIdColumnName(必須) | ユーザIDカラムの名前。 | -| userIdLockedColumnName(必須) | ユーザIDロックカラムの名前。 | -| failedCountColumnName(必須) | 認証失敗回数カラムの名前。 | -| effectiveDateFromColumnName(必須) | 有効日(From)カラムの名前。 | -| effectiveDateToColumnName(必須) | 有効日(To)カラムの名前。 | - -#### GroupSystemAccountTableSchema（グループシステムアカウント）の設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| groupIdColumnName(必須) | グループIDカラムの名前。 | -| userIdColumnName(必須) | ユーザIDカラムの名前。 | -| effectiveDateFromColumnName(必須) | 有効日(From)カラムの名前。 | -| effectiveDateToColumnName(必須) | 有効日(To)カラムの名前。 | - -#### PermissionUnitTableSchema（認可単位）の設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| permissionUnitIdColumnName(必須) | 認可単位IDカラムの名前。 | - -#### PermissionUnitRequestTableSchema（認可単位ケースリクエスト）の設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| permissionUnitIdColumnName(必須) | 認可単位IDカラムの名前。 | -| requestIdColumnName(必須) | リクエストIDカラムの名前。 | - -#### GroupAuthorityTableSchema（グループ権限）の設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| groupIdColumnName(必須) | グループIDカラムの名前。 | -| permissionUnitIdColumnName(必須) | 認可単位IDカラムの名前。 | - -#### SystemAccountAuthorityTableSchema（システムアカウント権限）の設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | テーブル名。 | -| userIdColumnName(必須) | ユーザIDカラムの名前。 | -| permissionUnitIdColumnName(必須) | 認可単位IDカラムの名前。 | - -BasicPermissionFactoryクラスは初期化が必要なため、 [初期化処理の使用手順](../../component/libraries/libraries-02-02-Repository-initialize.md#初期化処理の使用手順) に記述したInitializableインタフェースを実装している。 -[初期化処理の使用手順](../../component/libraries/libraries-02-02-Repository-initialize.md#初期化処理の使用手順) を参考にして、下記のように permissionFactory が初期化されるよう設定すること。 - -```xml - - - - - - - - -``` - -### 特定のリクエストIDを認可判定の対象から除外する方法 - -ログイン処理など、一部の処理のみ認可判定の対象から除外したい場合がある。 -そのような場合は、PermissionCheckHandlerの設定でignoreRequestIdsプロパティを指定する。 -リクエストIDがRW11AA0101とRW11AA0102を認可判定の対象から除外する場合の設定例を下記に示す。 - -```xml - - - - - -``` - -### 使用例 - -認可判定の使用例を下記に示す。 - -```java -// ******** 注意 ******** -// 下記のコードはフレームワークが行う処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -// PermissionCheckHandlerにより、スレッドローカルにPermissionが保持されている。 -// PermissionUtilからPermissionを取得する -Permission permission = PermissionUtil.getPermission(); - -// リクエストIDを指定して認可判定を行う。 -if (permission.permit("リクエストID")) { - - // 認可に成功した場合の処理 - -} else { - - // 認可に失敗した場合の処理 - -} -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Statement.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Statement.md deleted file mode 100644 index 89859df27..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-Statement.md +++ /dev/null @@ -1,232 +0,0 @@ -# SQL文実行部品の構造とその使用方法 - -本章では、SQL文実行部品の中でJDBCのAPIをラップしている機能と簡易検索機能の説明を行う。 - -## クラス図 - -![DbAccessSpec_StatementClassDesign.jpg](../../../knowledge/assets/libraries-04-Statement/DbAccessSpec_StatementClassDesign.jpg) - -### 各クラスの責務 - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| StatementFactory | 下記オブジェクトを生成するインタフェース * java.sql.PreparedStatementのラッパークラス * java.sql.CallableStatementのラッパークラス * ParameterizedSqlPStatement(オブジェクトのフィールドの値の登録用ステートメント)クラス | -| SqlStatement | SqlPStatement、ParameterizedSqlPStatementの親インタフェース。 | -| SqlPStatement | PreparedStatementのラッパー機能のインタフェース。 また、本機能の特徴の１つである [簡易検索機能](../../component/libraries/libraries-04-DbAccessSpec.md#件数指定でデータを取得簡易検索機能できる機能) のインタフェースをもつ。 | -| ResultSetConvertor | java.sql.ResultSetから値を取得するインタフェース。 ResultSet#getObject以外を使用して、SELECT結果の値を取得する必要がある場合には、実装クラスを追加する必要がある。 主に、getObject以外を使用するケースは、データベースのデータタイプに応じてJavaオブジェクトのデータ対応を決め打ちたい場合である。 | -| ParameterizedSqlPStatement | オブジェクトのフィールド値をデータベースに登録するインタフェース。 | -| StatementExceptionFactory | SQLException発生時に送出するExceptionを生成するインタフェース。 | - -#### クラス定義 - -a) nablarch.core.db.statement.StatementFactoryの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| BasicStatementFactory | StatementFactoryの基本実装クラスで、下記オブジェクトを生成する。 * BasicSqlPStatement(java.sql.PreparedStatementラッパークラス) > **Note:** > [SQLインジェクション対策](../../component/libraries/libraries-04-DbAccessSpec.md#sqlインジェクション対策について) にあるように、 > 本機能ではjava.sql.Statementクラスのラッパークラスの生成機能は提供しない。 | - -b) nablarch.core.db.statement.SqlPStatementの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| BasicSqlPStatement | SqlPStatement(SqlStatement)、ParameterizedSqlPStatementの基本実装クラス。 > **Note:** > 本クラスは、データベースベンダーに依存するような実装にはなっていない。 > このため、データベースベンダーに依存する実装が必要にならない限り、 > 本クラスを置き換える必要はない。 > 各プロジェクトにおいてデータベースベンダーに依存する実装が必要となった場合には、 > SqlPStatement及びParameterizedSqlPStatementの実装クラスを追加し差し替えること。 | - -c) nablarch.core.db.statement.exception.StatementExceptionFactoryの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statement.exceptionパッケージ | | -| BasicSqlStatementExceptionFactory | SqlStatementExceptionFactoryの基本実装クラス。 本クラスでは、下記のSqlStatementExceptionを生成する。 * 発生したSQLExceptionが一意制約違反の場合 DuplicateStatementExceptionを送出する。 * 一意制約違反以外の場合 SqlStatementExceptionを送出する。 > **Note:** > 一意制約違反の判定は、SQLException#getSQLStateまたは、SQLException#getErrorCodeを元に行う。 > 判定に使用する値は、 [BasicSqlStatementExceptionFactoryの設定](../../component/libraries/libraries-04-Statement.md#設定内容詳細) を参照すること。 > **Note:** > 一意制約違反以外の例外をアプリケーションでハンドリングする必要がある場合には、 > SqlStatementExceptionを継承したクラスと、そのFactoryクラスを追加する。 | - -d) 検索結果クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| ResultSetIterator | java.sql.ResultSetのラッパー機能のクラス。 ResultSetから1レコード分のデータをSqlRowで取得するインタフェースを提供する。 | -| SqlResultSet | 簡易検索結果が格納されるArrayListのサブクラス。 本クラスは、JDBC経由で検索処理(SELECT文)を実行し際に返却される、java.sql.ResultSetの結果を 全件メモリ上に保持する。 > **Attention:** > 本クラスでは、java.sql.ResultSetの結果を全てメモリ上に保持するため、 > 大量データを検索した場合メモリ不足の原因となる可能性がある。 > 大量データを検索する場合には、PreparedStatementラッパークラスのexecuteQueryを使用し、 > ResultSetIteratorを使用して検索結果を扱うこと。 | -| SqlRow | java.sql.ResultSetの結果の1レコード文のデータが格納されるMapインタフェースの実装クラス。 SqlResultSetの各要素に、本クラスが格納されている。 | - -e) SQL文のロードクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.statementパッケージ | | -| BasicSqlLoader | クラスパス上にある外部ファイルからSQL文を読み込むクラス 本クラスで読み込んだSQL文は、 [静的データのキャッシュ](../../component/libraries/libraries-05-StaticDataCache.md) によりメモリ上にSQLファイル単位に、 KEY:SQL_ID、VALUE:SQL文としてキャッシュされる。 SQLファイル単位にキャッシュを行うため、SQL_IDはSQLファイル内で一意とする必要がある。 SQLファイルに記述するSQL文のルール: ``` a) SQL_IDとSQL文の1グループは、空行で区切られて記述されている。 1つのSQL文の中に空行はいれてはならない。 また、異なるSQL文との間には必ず空行を入れなくてはならない。 コメント行は、空行とはならない。 b) 1つのSQL文の最初の「=」までがSQL_IDとなる。 SQL_IDとは、SQLファイル内でSQL文を一意に特定するためのIDである。 SQL_IDには、任意の値を設定することが可能となっている。 c) コメントは、「--」で開始されている必要がある。 「--」以降の値は、コメントとして扱い読み込まない。 ※コメントは、行コメントとして扱う。複数行に跨るブロックコメントはサポートしない。 d) SQL文の途中で改行を行っても良い。また、可読性を考慮してスペースやtabなどで桁揃えを行っても良い。 ``` 例 ```sql -- ＸＸＸＸＸ取得SQL -- SQL_ID:GET_XXXX_INFO GET_XXXX_INFO = SELECT COL1, COL2 FROM TEST_TABLE WHERE COL1 = :col1 -- ＸＸＸＸＸ更新SQL -- SQL_ID:UPDATE_XXXX UPDATE_XXXX = UPDATE TEST_TABLE SET COL2 = :col2 WHERE COL1 = :col1 ``` | - -f) サポートクラス(業務アプリケーションを簡易的に実装するためのサポートクラス) - -| クラス名 | 概要 | -|---|---| -| nablarch.core.db.supportパッケージ | | -| DbAccessSupport | SQL_IDからStatementオブジェクトを生成するクラス。 データベースアクセスを必要とするクラスでは、本クラスを継承する事により、 簡易的にStatementオブジェクトを生成することが可能となる。 本クラスでは、下記ルールに従いSQLファイルからSQL文を読み込む。 SQLファイル名は、本クラスを継承したデータベースアクセスクラスのクラス名(完全修飾名)と 一致していること。 ``` データベースアクセスクラス名:nablarch.sample.management.user.UserRegisterService SQLファイル名:nablarch/sample/management/user/UserRegisterService.sql ``` [BasicSqlLoader](../../component/libraries/libraries-04-Statement.md#nablarchcoredbstatementパッケージ) を使用した場合、 クラスパス配下のSQLファイルが読み込まれる。 このため、クラスパスが設定されたディレクトリにデータベースアクセスクラスと 同じパッケージを作成しSQLファイルを配置すれば良い。 > **Note:** > 継承モデルを使用できない場合(既にステレオタイプが割り当てられている(既に継承モデルを使用している) > クラスでデータベースアクセスを行う場合になど)は、本クラスを直接インスタンス化して使用すること。 > なお、インスタンス化する際にはデフォルトコンストラクタを使用するのではなく、 > Classオブジェクトを引数に取る下記コンストラクタを呼び出すこと。 > デフォルトコンストラクタを使用してインスタンス化した場合、 > データベースアクセスクラスではなくDbAccessSupportクラスの完全修飾名を元に > SQLファイルをクラスパス配下から検索する点に注意すること。 本クラスでは、下記のインタフェースを提供する。 SQL_IDを元に、SQL文実行用のSqlPStatementを生成する。 SQL_IDを元に、SQL文実行用のParameterizedSqlPStatementを生成する。 SQL_IDと条件をフィールドに保有したオブジェクトを元に、 可変の条件を持つSQL文を構築し、SQL文実行用のParameterizedSqlPStatementを生成する。 SQL_IDを元に件数取得(カウント)用のSQL文を生成して実行する。 ※本メソッドは、条件を必要としないSQL文の場合を使用する。 SQL_IDと条件をフィールドに保有したオブジェクトを元に、 件数取得(カウント)用のSQL文を生成して実行する。 SQL_IDとnablarch.core.db.support.ListSearchInfoを元に、件数取得及び検索を実行する。 このメソッドを使用した検索結果の一覧表示機能については、 [検索結果の一覧表示](../../component/libraries/libraries-07-FacilitateTag.md#検索結果の一覧表示) を参照。 | - -## 使用例 - -本章では、簡易検索処理を行う場合のシーケンス、実装例を説明している。 - -### 簡易検索の場合の処理シーケンス - -![DbAccessSpec_StatementSequence.jpg](../../../knowledge/assets/libraries-04-Statement/DbAccessSpec_StatementSequence.jpg) - -#### 処理概要 - -No1.SQL_IDを元にSqlPStatementを取得する。 - -DbAccessSupport#getSqlPStatementを呼び出し、SqlPStatementを取得する。 - -No2.SQL文を実行する。 - -SqlPStatement#retrieveを呼び出し、SQL文を実行する。 - -> **Note:** -> 本シーケンスでは、条件設定のシーケンスを省略しているが、 -> SqlPStatement#setString()等を呼び出しSQL文の実行前に条件を設定すること。 - -No3.簡易検索結果を処理する。 - -簡易検索で返却された、SqlResultSetから検索結果の値を取得する。 - -### 推奨するJavaの実装例(SQL文を外部ファイル化した場合) - -* SQLファイルの定義 - - SQLファイル名は、クラスパス配下にDbAccessSupportを継承したデータベースアクセスクラスのクラス名で作成する。 - 拡張子は、設定ファイルにて任意の値を設定できるが、設定を省略した場合は『.sql』となる。 - - SQL文の記述ルールについては、 [SQL文のロードクラス](../../component/libraries/libraries-04-Statement.md#nablarchcoredbstatementパッケージ) を参照にすること。 - - 本実装例の場合、データベースアクセスクラスのクラス名が『nablarch.sample.user.UserService』となっているため、 - クラスパス配下に『nablarch/sample/user/UserService.sql』を作成する必要がある。 - - ```sql - GET_USER_INFO = - SELECT USER_ID, - NAME, - TEL, - AGE - FROM USER_MTR - WHERE USER_ID = ? - ``` -* Javaの実装 - - ```java - package nablarch.sample.user; - - public class UserService extends DbAccessSupport { - - /** - * ユーザ情報を取得する。
- * @param userId ユーザID - * @return 指定されたユーザIDに紐づく情報 - */ - public SqlResultSet getUserInfo(String userId) { - - // getSqlPStatementを使用してStatementを生成する。 - // getSqlPStatementの引数には、SQL_IDを指定する。 - // 本サンプルの場合は、上記のSQLファイルの定義の部分に - // 記述されたSQL文を元にStatementが生成される。 - SqlPStatement statement = getSqlPStatement("GET_USER_INFO"); - - // 条件を設定し、SQL文を実行 - statement.setObject(1, "00001"); - return statement.retrieve(); - - } - } - ``` - -### Javaの実装例(SQL文指定の場合) - -```java -// ******** 注意 ******** -// テーブルのスキーマ情報から動的にSQL文を組み立てる必要があるフレームワークの機能において、 -// 下記のような実装を行う。 -// 通常、SQLインジェクション対策のためSQL文を外部ファイル化するため、 -// 各アプリケーション・プログラマはこのような実装を行わない。 - -// Statementの取得 -AppDbConnection connection = DbConnectionContext.getConnection(transaction.getDbTransactionName()); -SqlPStatement statement = connection.prepareStatement( - "SELECT " - + "USER_ID, " - + "NAME, " - + "TEL, " - + "AGE " - + "FROM " - + "USER_MTR " - + "WHERE " - + "USER_ID = ?"); - -// 条件を設定し、SQL文を実行 -statement.setObject(1, "00001"); -SqlResultSet resultSet = statement.retrieve(); - -// 検索結果を処理する。 -for (SqlRow row : resultSet) { - String userId = row.getString("user_id"); - String name = row.getString("name"); - String tel = row.getString("tel"); - String age = row.getString("age"); -} -``` - -## 設定ファイル例 - -```xml - - - - - - - - - - - - - - - - - - - - - - -``` - -### 設定内容詳細 - -a) StatementFactoryの設定 - -| property名 | 設定内容 | -|---|---| -| sqlStatementExceptionFactory(必須) | nablarch.core.db.statement.SqlStatementExceptionFactoryを実装したクラスの設定を行う。 本サンプルでは、「nablarch.core.db.statement.exception.BasicSqlStatementExceptionFactory」を設定している。 | -| resultSetConvertor | nablarch.core.db.statement.ResultSetConvertorを実装したクラスの設定を行う。 本サンプルでは、変換を行わないため設定を行っていない。 SELECT結果のカラムデータを変換する必要がある場合は、ResultSetConvertorの実装クラスを設定する。 | -| fetchSize | プリフェッチサイズを設定する。 本設定値を省略した場合は、デフォルトの設定値である10が適用される。 本設定値を変更することにより、データベースサーバとのラウンドトリップ数を削減でき性能改善が期待できる。 本設定値は、Statement単位で変更が可能となっている。個別のStatementで変更したい場合には、 SqlPStatement#setFetchSizeを呼び出し変更すること。 > **Note:** > SqlPStatement#setFetchSizeを呼び出した場合の変更後の値は、値が変更されたインスタンスでのみ有効となっている。 > ```java > SqlPStatement statement1 = connection.prepareStatement("select * from test"); > // statement1のfetchSizeは、100となる。 > // この値は、再びsetFetchSizeが呼び出されるまで有効である。 > statement1.setFetchSize(100); > > // AppDbConnection#prepareStatementを呼び出した場合のfetchSizeの値は、設定ファイルの値となる。 > // これは、同一のSQL文であっても同じ振る舞いとなる。 > SqlPStatement statement2 = connection.prepareStatement("select * from test"); > ``` > これは、 [statementReuse](../../component/libraries/libraries-04-Connection.md#設定内容詳細) の設定内容に関わらず、同一の振る舞いとなる。 | -| queryTimeout | クエリータイムアウトの秒数を設定する。 本設定値を省略した場合は、デフォルトの設定値である0（無制限）が適用される。 本設定値を変更することにより、SQLの実行結果を待っている途中で処理をタイムアウトさせることができる。 本設定値は、Statement単位で変更が可能となっている。個別のStatementで変更したい場合には、 SqlPStatement#setQueryTimeoutを呼び出し変更すること。 クエリータイムアウトの詳細は、JDKのJavaDoc(java.sql.Statement#setQueryTimeout(int))及び、 各データベースベンダーのドキュメントを参照すること。 > **Note:** > SqlPStatement#setQueryTimeoutを呼び出した場合の変更後の値は、値が変更されたインスタンスでのみ有効となっている。 > ```java > SqlPStatement statement1 = connection.prepareStatement("select * from test"); > // statement1のqueryTimeoutは、600となる。 > // この値は、再びsetQueryTimeoutが呼び出されるまで有効である。 > statement1.setQueryTimeout(600); > > // AppDbConnection#prepareStatementを呼び出した場合のqueryTimeoutの値は、設定ファイルの値となる。 > // これは、同一のSQL文であっても同じ振る舞いとなる。 > SqlPStatement statement2 = connection.prepareStatement("select * from test"); > ``` > これは、 [statementReuse](../../component/libraries/libraries-04-Connection.md#設定内容詳細) の設定内容に関わらず、同一の振る舞いとなる。 | -| sqlLoader | nablarch.core.cache.StaticDataLoaderを実装したクラスの設定を行う。 本サンプルでは、「nablarch.core.db.statement.BasicSqlLoader」を設定している。 BasicSqlLoader以外の実装クラスに差し替える場合には、下記仕様に準拠すること: ``` a) StaticDataLoaderのgeneric型は、Mapとすること。 例：implements StaticDataLoader> b) StaticDataLoaderで定義されているgetValueメソッドでSQLの読み込み処理を行うこと。 getValueメソッド以外は、nullを返す実装とすること。 c) getValueで返却するデータの形式 a)で説明したように、Mapを返却すること。 返却するMapのKEY、VALUEには下記の値を格納すること。 KEY:SQL_ID VALUE:SQL文 ``` | - -b) BasicSqlStatementExceptionFactoryの設定 - -| property名 | 設定内容 | -|---|---| -| 下記propertyのうちどちらか一方を必ず設定すること。 | | -| duplicateErrorSqlState | 一意制約違反を示すSqlState(SQLException#getSqlStateで返却される値)を設定する。 | -| duplicateErrorErrCode | 一意制約違反を示すErrCode(SQLException#getErrorCodeで返却される値)を設定する。 | - -c) BasicSqlLoaderの設定 - -| property名 | 設定内容 | -|---|---| -| fileEncoding | SQLファイルのエンコーディングを設定する。 本設定値を省略した場合は、JVMのデフォルトエンコーディングが使用される。 | -| extension | SQLファイルの拡張子を設定する。 本設定値を省略した場合は、デフォルトの拡張子である「sql」が使用される。 | diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-TransactionConnectionName.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-TransactionConnectionName.md deleted file mode 100644 index 5f8517e52..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-TransactionConnectionName.md +++ /dev/null @@ -1,135 +0,0 @@ -# データベースコネクション名とトランザクション名 - -本章では、 [トランザクション管理](../../component/libraries/libraries-03-TransactionManager.md) と [データベースアクセス(検索、更新、登録、削除)機能](../../component/libraries/libraries-04-DbAccessSpec.md) で触れた、データベースコネクション名とトランザクション名についての解説を行う。 - -## データベースコネクション名 - -データベースコネクション名は、DbConnectionContextに設定するAppDbConnection(以降データベース接続)毎に設定する名前である。 -名前を分けて登録するケースは、主に以下の場合である。 - -* データベースの接続先が異なる場合 -* 同一の接続先であるが、異なるトランザクション制御を行う場合。 - - (例えば、業務処理内で別トランザクションで処理を行う必要がある場合) - -この名前は、スレッド内ではユニークにする必要があり、アプリケーションでDbConnectionContextからデータベース接続を取得する際に使用する名前である。 - -> **Note:** -> DbConnectionContextには、無名のデータベース接続を１つだけ登録することができる。無名のデータベース接続は、アプリケーションから取得する際にも名前指定なしで取得することができる。 -> この無名のデータベース接続は、ビジネスロジックでメインで使用するデータベース接続に使用することを推奨する。 -> なぜなら、データベース接続を取得する際に名前を指定する必要がないため、名前の指定間違いによる不具合を防ぐことが出きるからである。 - -> ※無名の場合であっても、内部的には名前付きでデータベース接続が保持される。この名前は、「TransactionContext#DEFAULT_TRANSACTION_CONTEXT_KEY」の値となる。 - -### データベースコネクション名の使用例 - -```java -//*************************************************************************** -// DbConnectionContextへの登録例 -// この処理は、フレームワークの責務である。 -//*************************************************************************** - -// 現在実行中のスレッドに、無名のデータベース接続を登録する。 -// 内部的にデータベースコネクション名は「TransactionContext#DEFAULT_TRANSACTION_CONTEXT_KEY」として保持される。 -// つまり、DbConnectionContext.setConnection(TransactionContext#DEFAULT_TRANSACTION_CONTEXT_KEY, connection1)と同義となる。 -DbConnectionContext.setConnection(connection1); - -//**************************************************************************** -// 下記ロジックは、無名のデータベース接続を登録する事と同義である。 -DbConnectionContext.setConnection(TransactionContext.DEFAULT_TRANSACTION_CONTEXT_KEY, connection1); -DbConnectionContext.setConnection("transaction", connection1); -//**************************************************************************** - -// 現在実行中のスレッドに、データベースコネクション名：user-schemaでデータベース接続を登録する。 -DbConnectionContext.setConnection("user-schema", connection2); - -// 同一スレッドで既に登録されている名前で登録を行った場合は、エラーとなる。 -DbConnectionContext.setConnection("user-schema", connection3); // 「user-schema」は既に登録されているのでエラー - -//*************************************************************************** -// ビジネスロジックでのAppDbConnectionの取得例 -//*************************************************************************** - -// 無名のデータベース接続を取得する。 -AppDbConnection connection1 = DbConnectionContext.getConnection(); - -// データベースコネクション名に「user-schema」を指定してデータベース接続を取得する。 -AppDbConnection connection2 = DbConnectionContext.getConnection("user-schema"); -``` - -> **Attention:** -> TransactionContext#DEFAULT_TRANSACTION_CONTEXT_KEYの値は、「transaction」となっている。 -> この名前(transaction)は、無名のデータベース接続の内部的な名前であるため、「transaction」と無名のデータベースコネクションは同義となる。 -> 無名と「transaction」を同時に使用した場合の振る舞いは、下記実装を参照。 - -> ```java -> // 無名のコネクションは、「transaction」を指定して取得できる。 -> DbConnectionContext.setConnection(connection); -> DbConnectionContext.getConnection("transaction"); -> -> // 「transaction」で登録したコネクションは、無名で取得できる。 -> DbConnectionContext.setConnection("transaction", connection); -> DbConnectionContext.getConnection(); -> -> // 無名が登録されている場合、「transaction」は登録できない。 -> DbConnectionContext.cetConnection(connection1); -> DbConnectionContext.setConnection("transaction", connection); // 「transaction」は既に登録されているのでエラー -> ``` - -## トランザクション名 - -トランザクション名は、TransactionContextに設定するTransaction(以降トランザクション)毎に設定する名前である。 -この名前は、スレッド内ではユニークにする必要があり、アプリケーションでTransactionContextからトランザクションを取得する際に使用する名前である。 - -### トランザクション名の使用例 - -```java -//*************************************************************************** -// TransactionContextへの登録例 -// この処理は、フレームワークの責務である。 -//*************************************************************************** - -// 現在実行中のスレッドに、トランザクション名：TransactionContext.DEFAULT_TRANSACTION_CONTEXT_KEYでトランザクションを登録する。 -TransactionContext.setTransaction(TransactionContext.DEFAULT_TRANSACTION_CONTEXT_KEY, transaction); - -// 現在実行中のスレッドに、トランザクション名：user-schemaでトランザクションを登録する。 -TransactionContext.setTransaction("user_schema", transaction2); - -// 同一スレッドで既に登録されている名前で登録を行った場合は、エラーとなる。 -TransactionContext.setTransaction("user_schema", transaction3); // 「user_schema」は既に登録されているのでエラー - -//*************************************************************************** -// トランザクションの取得例 -// 基本的にこの処理はフレームワークの責務である。 -// アプリケーションで、トランザクションが必要となるケースは、 -// 例外発生時(異常終了)であっても処理を確定する必要がある場合である。 -//*************************************************************************** -// トランザクション名に「TransactionContext.DEFAULT_TRANSACTION_CONTEXT_KEY」を指定してトランザクションを取得する。 -Transaction tran = TransactionContext.getTransaction(TransactionContext.DEFAULT_TRANSACTION_CONTEXT_KEY); - -// トランザクション名に「user-schema」を指定してトランザクションを取得する。 -Transaction tran = TransactionContext.getTransaction("user-schema"); -``` - -### JdbcTransactionを使用した場合のトランザクション名とデータベースコネクション名の関係 - -本クラスを使用した場合、トランザクション名とデータベースコネクション名は1対1で紐付く仕様となっている。 -つまり、JdbcTransactionは、自身のトランザクション名と同一の名前でDbConnectionContextに登録されているデータベース接続を使用して、 -トランザクション制御を行う仕様となっている。 - -#### 実装コードで見るトランザクション制御 - -```java -// 無名のデータベース接続とトランザクションを登録 -DbConnectionContext.setConnection(connection1); -TransactionContext.setTransaction(TransactionContext.DEFAULT_TRANSACTION_CONTEXT_KEY, transaction1); - -// user-schemaという名前でデータベース接続とトランザクションを登録 -DbConnectionContext.setConnection("user-schema", connection2); -TransactionContext.setTransaction("user-schema", transaction2); - -// このコミット処理は、connection1に対して実行される。 -// connection2は、このトランザクション制御の影響を一切うけない。 -Transaction tran1 = TransactionContext.getTransaction(); -tran1.commit(); -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-TransactionTimeout.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-TransactionTimeout.md deleted file mode 100644 index de12b9add..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-04-TransactionTimeout.md +++ /dev/null @@ -1,120 +0,0 @@ -# トランザクションタイムアウト機能 - -本章では、本機能で提供するトランザクションタイムアウト機能について解説を行う。 - -トランザクションタイムアウト機能では、トランザクションを開始してから一定秒数（設定ファイルで指定した秒数）を超過した場合、 -トランザクションタイムアウト例外を送出しアプリケーションの処理を強制的に中止する。 -トランザクションタイムアウト例外が発生するタイミングは、データベースへのアクセス時となる。 -これは、データベースアクセス時にトランザクションタイムアウトチェックを行なっているためである。 - -トランザクションタイムアウトチェックのタイミング等の詳細は、後述の 処理シーケンス を参照。 - -本機能を使用する際には、必ず 注意点 の内容を確認すること。 - -## 処理シーケンス - -トランザクションタイムアウトの処理シーケンス（概要）を以下に示す。 - -![DbAccessSpec_TransactionTimeout.png](../../../knowledge/assets/libraries-04-TransactionTimeout/DbAccessSpec_TransactionTimeout.png) - -### 各処理の概要 - -**1). トランザクション開始** - -トランザクションを開始する。 - -トランザクションの開始時に、トランザクションタイムアウト秒数と現在日時からトランザクションの有効期限を算出する。 - -**2). SQL実行** - -アプリケーションからSQL文(SQL文の種類は問わない)を実行する。 - -**2-1). トランザクションタイムアウトチェック** - -SQL文を実行する前に、トランザクションタイムアウトの事前チェックを行う。 -この時点で、現在日時がトランザクションの有効期限を過ぎている場合、トランザクションタイムアウトエラーを送出する。 - -**2-2). SQL文のタイムアウト時間を設定** - -現在日時を元にトランザクション有効期限までの残り秒数を求め、クエリタイムアウト秒数 [1] を設定する。 -これは、データベース側でのロック解放待ちや、単純にパフォーマンスの悪いSQLの場合であっても、 -トランザクション有効期限を過ぎた場合にSQL文の実行を強制的に中止するために設定する。 - -**2-3). トランザクションタイムアウトチェック** - -**2-3-1). SQL文の実行が成功した場合** - -SQL文の実行が成功した場合でも、既にトランザクション有効期限を超過している可能性があるためトランザクションタイムアウトチェックを行う。 -もし、トランザクション有効期限を過ぎている場合には、トランザクションタイムアウトエラーを送出する。 [2] - -**2-3-2). SQL文の実行に失敗した場合** - -SQL文の実行に失敗した場合、発生した例外がトランザクションタイムアウト対象の例外かをチェックする。 [3] -トランザクションタイムアウト対象の例外の場合で、トランザクションの有効期限を過ぎている場合には、トランザクションタイムアウト例外を送出する。 - -> **Note:** -> トランザクションの有効期限内であれば、トランザクションタイムアウト対象の例外が発生してもトランザクションタイムアウトエラーとはしない。 -> この場合は、通常のSQL文実行時例外として例外の送出を行う。 - -**3). トランザクション終了** - -トランザクションを終了（コミットまたはロールバック）する。 -トランザクションタイムアウトエラーが発生した場合には、必ずロールバック処理が行われる。 - -> **Note:** -> トランザクション終了時にはトランザクションタイムアウトチェックは行わない。 - -> これは、トランザクション終了時にトランザクションの有効期限が過ぎていたとしても、クライアント（ユーザ）に対する応答時間は変わらないため、 -> 利便性を考え処理を正常に終了させることを優先させるためである。 - -クエリタイムアウト設定は、java.sql.Statement#setQueryTimeoutを使用して行う。 - -クエリタイムアウトは、厳密に設定秒数を超過した場合にエラーとなるわけではない。 -このため、設定したタイムアウト秒数を超過しても例外が発生せずに、SQL文の実行が正常終了する場合がある。 -このような場合でも、トランザクションタイムアウトエラーを発生させるために、SQL文の実行が成功した場合でもトランザクションのタイムアウトチェックを実施している。 - -トランザクションタイムアウト対象の例外の判定は、ベンダー依存の例外コード(SQLException#getErrorCodeから取得される値)で行う。 -トランザクションタイムアウト対象としたい例外コードは設定ファイルに指定する。 - -なお、上述の通りSQL文実行時にクエリタイムアウト設定を行なっている。 -このため、トランザクションタイムアウトの例外コードの設定には、クエリタイムアウト発生時に送出される例外の例外コードを設定する必要がある。 -クエリタイムアウト発生時の例外コードの詳細は各データベースベンダより提供されるマニュアル等を参照すること。 - -## トランザクションタイムアウトを使用するための設定 - -トランザクションタイムアウトを有効化するためには、「JdbcTransactionFactory」に対してトランザクションタイムアウト秒数を設定する。 - -以下に設定例を示す。 - -```xml - - - - - - - - -``` - -各設定値の詳細 - -| プロパティ名 | 設定値 | -|---|---| -| transactionTimeoutSec | トランザクションタイムアウト秒数を設定する。 本設定値を省略した場合や0以下の値を設定した場合には、 トランザクションタイムアウト機能は有効化されない。 | -| transactionTimeoutErrorCodeList | トランザクションタイムアウト対象とするベンダー依存の例外コード (SQLException#getErrorCodeから取得できる値)を設定する。(複数指定可能) 処理シーケンス で説明したように、最低限クエリタイムアウト時に発生する ベンダー依存の例外コードを設定すること。 また、データベースベンダーによってはロック解放待ちが一定時間に達すると、タイムアウトエラーが 発生するものがある。 このロック解放待ちのエラーが発生した場合で、トランザクション有効期限を過ぎていた場合に、 トランザクションタイムアウトとしたい場合がある。 この場合は、追加でロック解放待ちの例外コードを指定すると良い。 | - -## 注意点 - -### クエリタイムアウト時の動作について - -本機能ではSQL文の実行タイムアウト(クエリタイムアウト)をトランザクションタイムアウトの判定で使用している。 -このクエリタイムアウトの動作は、データベースベンダーのJDBC実装に依存するため、必ず各ベンダー提供のマニュアルを確認すること。 -特に注意すべき点は、クエリタイムアウト時にデータベース側のSQL文の実行処理が確実に取り消されるかどうかである。 -万が一SQL文の実行が取り消されない場合、データ不整合などの原因になる可能性があるため、トランザクションタイムアウト機能は使用しないようにすること。 - -### アプリケーションロジックでの処理遅延について - -トランザクションタイムアウト機能は、データベースアクセス時に有効期限を過ぎていないかの判定を行う。 -このため、データベースアクセスを伴わない処理や、アプリケーションロジックで無限ループなどが発生した場合は、 -トランザクションタイムアウトエラーとはならない点に注意すること。 diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-FileDownload.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-FileDownload.md deleted file mode 100644 index 5f3586f2a..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-FileDownload.md +++ /dev/null @@ -1,311 +0,0 @@ -# ファイルダウンロード - -## 概要 - -ファイルをクライアントへダウンロードする機能を提供する。 - -## 特徴 - -### 実装の容易性 - -HTTPレスポンスオブジェクト（ `HttpResponse` クラス）が提供するメソッドのみを使用し、単純な実装方法でダウンロードを実現できる。 -アプリケーションプログラマは、ダウンロード用の特別なクラスの仕様などを学習する必要はない。 -使用するHTTPレスポンスオブジェクトのメソッドを以下に記す。 - -1. コンテンツタイプ、文字コードの設定 - - `HttpResponse#setContentType(String)` -2. ダウンロードファイル名、およびインライン表示有無の設定 - - `HttpResponse#setContentDisposition(String)` -3. レスポンスボディに対するデータの書き込み - - a) バイト配列(byte[])の場合 ： `HttpResponse#write(byte[])` - b) 文字シーケンス(CharSequence)の場合 ： `HttpResponse#write(CharSequence)` - c) 入力ストリーム(java.io.InputStream)の場合 ： `HttpResponse#setBodyStream(InputStream)` - d) ファイルパス指定(String)の場合 ： `HttpResponse#setContentPath(String)` - -バイト配列、文字シーケンス、入力ストリーム、ファイルパス指定と、４種類のデータ型によるレスポンスデータの作成に対応しているので、通常複雑になりがちなダウンロード処理を容易に実装することができる。 - -> **Note:** -> writeメソッド、setBodyStreamメソッド、setContentPathメソッドが同時に使用された場合の優先順位を以下に記す。 -> 　1. setContentPathメソッド -> 　2. setBodyStreamメソッド -> 　3. writeメソッド -> たとえば、setBodyStreamメソッドとwriteメソッドが同時に呼ばれた場合、setBodyStreamメソッドで設定した内容がダウンロードされ、writeメソッドで設定した内容は無視される。 - -以下に、コード例を記す。 - -```java -/** 文字シーケンスをShift_JISのデータとしてダウンロードする。 */ -public HttpResponse doDownloadCharSequence(HttpRequest req, ExecutionContext context) { - - HttpResponse res = new HttpResponse(); - - // HttpResponseのsetContentTypeメソッドを使用して、Content-Typeを設定する。 - res.setContentType("text/csv; charset=Shift_JIS"); - - // HttpResponseのwriteメソッドを使用して、ダウンロードデータを生成する - res.write("ユーザID, ユーザ名\n"); - res.write("0000001, nabla\n"); - res.write("0000002, arch\n"); - res.write("0000003, arch\n"); - - // ファイル名を設定する - res.setContentDisposition("サンプルCSVファイル.csv"); - - return res; -} -``` - -> **Note:** -> HttpResponseクラスのwriteメソッドでダウンロードされる文字シーケンスは、Content-Typeヘッダに設定した文字コード（charset）でエンコードされるので、原則writeメソッド実行前に文字コードを設定しておく必要がある。 -> もし文字コードの設定を行わず、writeメソッドを実行した場合、ダウンロードされる文字シーケンスはUTF-8でエンコードされる。 - -### サイズが大きいファイルをダウンロードする場合でもメモリリソースを圧迫しない - -HttpResponseオブジェクトのwriteメソッドを用いてダウンロードデータを作成する際に、データサイズが一定の閾値を超えると、自動的にデータの保存先をメモリから一時ファイルに切り替える機能を提供する。 -本機能を使用することで、アプリケーションプログラマがデータのサイズ（データ量）を意識した実装を行わなくとも、データサイズに応じて自動的に選択された最適な方式でダウンロードが行われる。 -（データサイズが小さい場合はメモリ経由で高速なダウンロードが行われ、データサイズが大きい場合は一時ファイル経由でメモリ消費量を抑えたダウンロードが行われる） - -## 要求 - -### 実装済み - -* ファイルのダウンロードができる。 -* テキストファイル、バイナリファイルのダウンロードができる。 -* ダウンロードしたファイルのインライン表示ができる。 - - 通常、ファイルをダウンロードする場合、ファイルの保存先を選択するダイアログが表示されるが、 - インライン表示オプションを有効にすることで、ブラウザ上に直接ファイルを表示できる。 - 本機能はイントラ環境等で、ダウンロードしたExcelファイルを直接ブラウザ上で表示する場合などに使用される。 - - > **Note:** -> インライン表示の挙動はブラウザの種類やセキュリティ設定に依存する。 -* データサイズが大きいダウンロードファイルを作成する際に、データの保存先を一時ファイルにできる。 -* ダウンロードファイル名に日本語などの非ASCII文字(多言語)を使用できる。 - - > **Note:** -> ファイル名に非ASCII文字(多言語)の使用をサポートをするブラウザは、Internet Explorer、Firefox、Google Chromeの３種類。 - > Windows版Safariは非Ascii文字には未対応（Ascii文字は使用可能）。 - -### 未実装 - -* ダウンロード履歴を残すことができる - - ダウンロードの際に使用した一時ファイルをサーバ上に保管することで履歴管理できる（byte配列、文字シーケンスを使う場合だけでなく、入力ストリームも保管する。また保管する一時ファイル名には、ダウンロードファイル名（+拡張子）が含まれるようにする。また、HTTPログと紐付けられるような情報を残す。 - -## 構成 - -### クラス図 - -![FileDownload_ClassDiagram.png](../../../knowledge/assets/libraries-05-FileDownload/FileDownload_ClassDiagram.png) - -### 各クラスの責務 - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.fw.web.download.encorder.DownloadFileNameEncoder | ダウンロードファイル名のエンコーダのインタフェース。本インタフェースの実装クラスを用いて、ファイル名を適切にエンコードすることで、非ASCII文字の使用が可能となる。標準では、URLエンコーディング方式およびMIME-Bエンコーディング方式の実装クラスを提供する。 URLエンコーディング方式およびMIME-Bエンコーディング方式以外のエンコーダが必要な場合は、本インタフェースを実装することにより実現可能。 現状、URLエンコーディング方式またはMIME-Bエンコーディング方式でほとんどのブラウザに対応可能なので、通常、利用者側で独自のエンコーダを実装する必要はない。 | - -##### クラス定義 - -a) nablarch.fw.web.download.encorder.DownloadFileNameEncoderの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.fw.web.download.encorder.MimeBDownloadFileNameEncoder | ダウンロードファイル名をRFC2047の仕様に従い、MIME-Bエンコード方式でダウンロードファイル名をエンコードするエンコーダ。本ドキュメントでは、このエンコーダを「MIME-Bエンコーダ」と称する。 | -| nablarch.fw.web.download.encorder.UrlDownloadFileNameEncoder | URLエンコード方式でダウンロードファイル名をエンコードするエンコーダ。本ドキュメントでは、このエンコーダを「URLエンコーダ」と称する。 | - -b) nablarch.fw.Handlerの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.fw.web.handler.HttpResponseHandler | アプリケーションプログラマがHttpResponseクラスに設定したダウンロードデータおよびHTTPヘッダ情報をレスポンスに出力するハンドラ。 ダウンロードファイル名のエンコーダを取得するクラス（DownloadFileNameEncoderFactory）を用いて、ダウンロードファイル名のエンコーダを取得し、エンコードしたファイル名を、Content-Dispositionに設定する。 ダウンロードデータが一時ファイルに保存されている場合は、レスポンス出力後に不要になった一時ファイルを削除する。 | - -c) その他のクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.fw.web.HttpResponse | アプリケーションプログラマがダウンロードデータおよびHTTPヘッダ情報を設定するHTTPレスポンスオブジェクト。 ダウンロードデータの出力、Content-Dispositionヘッダ、Content-Typeヘッダの設定機能を持つ。 | -| nablarch.fw.web.ResponseBody | ダウンロードデータを保持するクラス。 ダウンロードデータのサイズが一定量を超えると、データの保存先をメモリから一時ファイルに変更し、メモリ消費量を抑制する機能を持つ。 | -| nablarch.fw.web.HttpResponseSetting | レスポンスに関連する設定を保持するクラス。コンポーネント設定ファイルで本クラスを定義することで、設定の変更が可能となる。 具体的には、以下の設定を行うことができる。 ・ ダウンロードデータをメモリにバッファリングするサイズの上限 ・ 一時ファイルの出力先フォルダのパス ・ 一時ファイルの使用有無などの設定を保持するクラス コンポーネント設定ファイルについては、 [HTTPレスポンスの設定](../../component/libraries/libraries-05-FileDownload.md#httpレスポンスの設定) の項を参照すること。 | -| nablarch.fw.web.download.encorder.DownloadFileNameEncoderEntry | User-Agentヘッダのパターン（例：「.*MSIE.*」）とダウンロードファイル名のエンコーダの関連を保持するエントリ。 | -| nablarch.fw.web.download.encorder.DownloadFileNameEncoderFactory | ダウンロードファイル名のエンコーダを取得（生成）するクラス。User-Agentヘッダとエンコーダの関連は、コンポーネント設定ファイルで容易に編集が可能。 コンポーネント設定ファイルについては、 [ファイル名のエンコーダの設定の記述](../../component/libraries/libraries-05-FileDownload.md#ファイル名のエンコーダの設定の記述) の項を参照すること。 | - -### クラス詳細 - -#### nablarch.fw.web.HttpResponseクラスのメソッド - -| メソッド名 | 概要 | -|---|---| -| setContentType(String contentType) | Content-Typeヘッダを設定するメソッド 。省略した場合、setContentDispositionメソッドの引数で指定されたファイル名の拡張子をもとに自動的にContent-Typeが設定される。 アプリケーションプログラマが任意でContent-Typeを設定する場合は、本メソッドを使用する。 特に、writeメソッドで文字シーケンスデータを作成する場合は、Content-Typeヘッダに設定した文字コード（charset）でエンコードされるので、writeメソッド実行前に必ず本メソッドを実行し、文字コードを設定しておく必要がある。たとえば、Shift_JISの文字シーケンスデータを作成する場合は、本メソッドの引数に「text/csv; charset=Shift_JIS」のような値を設定すれば良い。 バイト配列、ストリーム、ファイルパスのデータをダウンロードする場合は、Content-Typeヘッダに設定した文字コードでエンコードは行われずそのままデータがレスポンスに出力される。 | -| setContentDisposition(String fileName) | Content-Dispositionヘッダを設定するメソッド。ダウンロードファイル名を指定する。このメソッドを使用する場合、インライン表示は行われない。 | -| setContentDisposition(String fileName, boolean inline) | Content-Dispositionヘッダを設定するメソッド。ダウンロードファイル名およびインライン表示の有無を指定する。 | -| write(byte[] bytes) | ダウンロードデータとしてバイト配列を使用する際に使用するメソッド 。 | -| write(CharSequence text) | ダウンロードデータとして文字シーケンスを使用する際に使用するメソッド 。 | -| setBodyStream(InputStream bodyStream) | ダウンロードデータとして入力ストリームを使用する際に使用するメソッド 。引数で渡された入力ストリームがダウンロードされる。 | -| setContentPath(String path) | ダウンロードデータとしてファイルパスを使用する際に使用するメソッド 。引数で渡されたパスに存在するファイルがダウンロードされる。 | - -### シーケンス図 - -本機能のシーケンス図を下記に示す。 - -![FileDownload_SequenceDiagram.png](../../../knowledge/assets/libraries-05-FileDownload/FileDownload_SequenceDiagram.png) - -## 設定の記述 - -ファイルダウンロード機能は、リポジトリ機能を利用して設定を行うことができる。 - -### HTTPレスポンスの設定 - -```xml - - - - - - - -``` - -#### 設定内容詳細 - -##### nablarch.fw.web.HttpResponseの設定 - -| property名 | 設定内容 | -|---|---| -| bufferLimitSizeKb | データをメモリにバッファリングするサイズの上限（KB）。 本プロパティの設定を省略した場合は「1024」（1MB）が設定される。 本プロパティで設定したサイズを超えるダウンロードデータは、 メモリではなく一時ファイルに保存される。 | -| tempDirPath | 一時ファイルが作成されるディレクトリパス。 本プロパティで設定されたパスにディレクトリが存在しない場合、 一時ファイル作成時に例外が発生する。 本プロパティの設定を省略した場合、OSデフォルトの一時ディレクトリに 一時ファイルが生成される （たとえばWINDOWSならば「C:\\WINDOWS\\Temp」が一時ディレクトリとなる。 詳細はjava.io.FileクラスのcreateTempFileメソッドのAPI仕様を参照すること）。 本番環境では本プロパティは省略せず、事前に適切なサイズ設計、 権限設定が行われたディレクトリを用意し、そのパスを本プロパティに設定すること。 | - -### ファイル名のエンコーダの設定の記述 - -本機能は、クライアントのブラウザから送信されるUser-Agentヘッダの内容をもとに、使用するダウンロードファイル名のエンコーダを選択する。 -User-Agentヘッダとエンコーダの関連は、コンポーネント設定ファイルで定義できる。 - -標準サポートのブラウザ（Internet Explorer、Google Chrome、Firefox）のみを想定する場合、コンポーネント設定ファイルの定義をすべて省略しても、ファイル名は適切にエンコードされる。 -サポート外のブラウザに対応する必要がでてきた場合や、ブラウザのバージョンアップでUser-Agentヘッダの仕様が変わった場合は、コンポーネント設定ファイルに独自の設定を定義する。 - -> **Note:** -> コンポーネント設定ファイルの定義をすべて省略した場合、User-Agentヘッダの内容が「.*MSIE.*」、 -> 「.*WebKit.*」のパターンにマッチする場合にはURLエンコーダ、「.*Gecko.*」のパターンにマッチする場合にはMIME-Bエンコーダ、 -> いずれのパターンにもマッチしない場合はURLエンコーダが使用される。 -> コンポーネント設定ファイルに独自の設定を定義する場合は、 -> 初期ハンドラ構成を変更し、HTTPレスポンスハンドラにダウンロードファイル名のエンコーダを取得するクラス -> （DownloadFileNameEncoderFactory）を設定する必要がある。初期ハンドラ構成については、 -> [画面オンライン実行制御基盤](../../processing-pattern/web-application/web-application-web-gui.md#画面オンライン実行制御基盤) の標準ハンドラ構成の項を参照すること。 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -#### 設定内容詳細 - -##### nablarch.fw.web.handler.HttpResposeHandlerの設定 - -| property名 | 設定内容 | -|---|---| -| downloadFileNameEncoderFactory | ダウンロードファイル名のエンコーダを取得するクラス。 本プロパティの設定を省略した場合、DownloadFileNameEncoderFactoryクラスが使用され、DownloadFileNameEncoderFactoryクラスのdownloadFileNameEncoderEntriesプロパティおよびdefaultEncoderプロパティには、デフォルト値が設定される。 DownloadFileNameEncoderFactoryのデフォルト値（プロパティの設定を省略した場合の値）については、 [nablarch.fw.web.download.encorder.DownloadFileNameEncoderFactoryの設定](../../component/libraries/libraries-05-FileDownload.md#nablarchfwwebdownloadencorderdownloadfilenameencoderfactoryの設定) を参照すること。 | - -##### nablarch.fw.web.download.encorder.DownloadFileNameEncoderFactoryの設定 - -| property名 | 設定内容 | -|---|---| -| downloadFileNameEncoderEntries | User-Agentヘッダのパターンと、ダウンロードファイル名のエンコーダの関連を保持するエントリ のList。 本プロパティの設定を省略した場合、以下の３種類のエントリがデフォルトで登録される。 1.User-Agentパターン「".*MSIE.*"」、エンコーダ「URLエンコーダ」。 2.User-Agentパターン「".*WebKit.*"」、エンコーダ「URLエンコーダ」。 3.User-Agentパターン「".*Gecko.*"」、エンコーダ「Mime-Bエンコーダ」。 | -| defaultEncoder | 標準のダウンロードファイル名のエンコーダ。本プロパティの設定を省略した場合、URLエンコーダが使用される。 | - -##### nablarch.fw.web.download.DownloadFileNameEncoderEntryの設定 - -| property名 | 設定内容 | -|---|---| -| userAgentPattern(必須) | User-Agentヘッダにマッチするパターン。本プロパティが設定されていない場合、DIコンテナ起動時に例外がスローされる。 | -| encoder | ダウンロードファイル名をエンコードするクラス。本プロパティの設定を省略した場合、URLエンコーダが使用される。 | - -##### nablarch.fw.web.download.encorder.MimeBDownloadFileNameEncoderの設定 - -| property名 | 設定内容 | -|---|---| -| charset | ファイル名のエンコードに使用する文字コードを設定する。本プロパティの設定を省略した場合、「UTF-8」が使用される。 | - -##### nablarch.fw.web.download.encorder.UrlDownloadFileNameEncoderの設定 - -| property名 | 設定内容 | -|---|---| -| charset | ファイル名のエンコードに使用する文字コードを設定する。本プロパティの設定を省略した場合、「UTF-8」が使用される。 | - -## 使用例 - -```java -/** 文字シーケンスをShift_JISのデータとしてダウンロードする。 */ -public HttpResponse doDownloadCharSequence(HttpRequest req, ExecutionContext context) { - - HttpResponse res = new HttpResponse(); - - // HttpResponseのsetContentTypeメソッドを使用して、Content-Typeを設定する。 - res.setContentType("text/csv; charset=Shift_JIS"); - - // HttpResponseのwriteメソッドを使用して、ダウンロードデータを生成する - res.write("ユーザID, ユーザ名\n"); - res.write("0000001, nabla\n"); - res.write("0000002, arch\n"); - res.write("0000003, arch\n"); - - // ファイル名を設定する - res.setContentDisposition("サンプルCSVファイル.csv"); - - return res; -} -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-ServiceAvailability.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-ServiceAvailability.md deleted file mode 100644 index ef2e765f1..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-ServiceAvailability.md +++ /dev/null @@ -1,193 +0,0 @@ -# 開閉局 - -## 概要 - -サービスの提供可否状態をチェックおよび設定する（切り替える）機能を提供する。 - -* サービス提供可否状態のチェックは、本機能が提供する共通ハンドラおよびユーティリティを使用する。 -* サービス提供可否状態の設定は、本機能が提供するユーティリティを使用する。 - -11| 共通ハンドラ及びユーティリティは特定の実行制御基盤には依存しない。本機能をハンドラ構成に組み込むだけで、画面オンライン実行制御基盤でもバッチ実行制御基盤でも開閉局を実現できる。 -| ユーティリティは、業務アクションなどの任意のロジックからサービス提供可否状態を取得する際に使用されることを想定している。 - -> **Note:** -> 「サービス提供可否状態の設定」とはサービス提供可否状態のON/OFFを切り替えることを示す。 -> サービス提供可否状態はデータベースのテーブルに格納されている。テーブル構造については、 [テーブル定義の例](../../component/libraries/libraries-05-ServiceAvailability.md#テーブル定義の例) を参照すること。 - -### 概要図 - -![ServiceAvailability_ServiceImage.jpg](../../../knowledge/assets/libraries-05-ServiceAvailability/ServiceAvailability_ServiceImage.jpg) - -## 特徴 - -リクエスト、各機能（複数のリクエストの集合）、システム全体の単位で、サービス提供可否状態を設定することが可能。 - -## 要求 - -### 実装済み - -* アクション(リクエスト)単位でサービス提供可否状態をチェックすることができる。 - -> **Note:** -> サービス提供可否状態をチェックする方式としては、フレームワーク側で指定時間にサービス提供可否を切り替えるパターンと、運用JOBスケジューラ側で指定時間にサービス提供可否を切り替えるパターンの２種類が考えられる。 -> 前者の方式では、フレームワークがデータベースに格納されたリクエストごとの開局時間、閉局時間、曜日などの日時情報をもとにサービス提供可否を判定し、後者の方式では、フレームワークがデータベースに格納されたリクエストごとのサービス提供可否フラグをもとにサービス提供可否を判定する。 -> 前者の方式では、 フレームワークが日時情報を管理するため、機能は豊富だがアーキテクチャが複雑になり、データベースのテーブルの構造にも制約が生まれ、柔軟性・カスタマイズ性が若干低下する。 -> 後者の方式では、 フレームワークが日時情報を管理しないため、運用JOBスケジュールや常駐バッチで日時情報の管理を行う必要があるが、フレームワークのアーキテクチャはシンプルになり、要件に対して柔軟に対応できる。 -> 本フレームワークでは、まず、シンプルで柔軟性の高い後者の方式に対応した機能を提供し、前者のパターンに関しては未検討の項目に追加し、別途、取り込み検討を行う。なお、前者の方式にも対応できるインタフェースにしているので、前者を取り込む際にもインタフェースの変更等は発生しない。 - -* 開閉局が必要なすべての実行制御基盤でサービス提供可否状態のチェックができる。 - -### 未実装 - -* アクション(リクエスト)単位でサービス提供可否状態の設定を行うことができる。 -* 各機能（複数のリクエストの集合）単位でサービス提供可否状態の設定を行うことができる。 -* システム全体でサービス提供可否状態の設定を行うことができる。 -* 特定のイベントをトリガとしてサービス提供可否状態の設定を行うことができる。 - -### 未検討 - -* 指定時間にサービス提供可否を切り替えることができる。 -* サービスの提供可否判定の結果に応じて画面項目（メニューやボタンなど）の表示・非表示を切り替えることができる（カスタムタグ等を提供する）。 -* サービス提供不可の場合に、個別画面へ遷移できる。 - -> **Note:** -> 現時点での設計判断では、サービス提供不可の場合に個別画面へ遷移する要件はないと想定している。 - -### 取り下げ - -* 各機能（複数のリクエストの集合）単位でサービス提供可否状態をチェックする機能。 - - 柔軟性確保の観点より、各機能単位でのチェック機能は提供せず、リクエスト単位でのチェック機能のみ提供する。 - また、今後提供する各機能単位でサービス提供可否状態を一括設定する機能を使用することで、代替が可能である。 - -## 構成 - -### クラス図 - -![ServiceAvailability_ClassDiagram.jpg](../../../knowledge/assets/libraries-05-ServiceAvailability/ServiceAvailability_ClassDiagram.jpg) - -### 各クラスの責務 - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.common.availability.ServiceAvailability | リクエストIDをもとに、サービス提供可否状態を判定するインタフェース。 独自のサービス提供可否状態判定の実装が必要となった場合には、本インタフェースを実装することにより実現可能。 | - -##### クラス定義 - -a) nablarch.common.availability.ServiceAvailabilityの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.common.availability.BasicServiceAvailability | リクエストIDをもとに、サービス提供可否状態を判定するクラス。 サービス提供可否状態の判定には、リクエストテーブルを参照する。 リクエストテーブルのテーブル名、カラム名は、設定ファイルにより設定が可能。 | - -b) その他のクラス - -| クラス名 | 概要 | -|---|---| -| nablarch.common.handler.ServiceAvailabilityCheckHandler | サービス提供可否状態の判定をするハンドラ。 | -| nablarch.common.availability.ServiceAvailabilityUtil | サービス提供可否状態判定用ユーティリティ。 アプリケーションプログラマは本クラスを使用することで、容易にサービス提供可否状態を判定できる。 | - -### シーケンス図 - -#### 全処理方式共通 - -ユーティリティ使用時におけるシーケンス図を下記に示す。 - -![ServiceAvailability_SequenceDiagramUtil.jpg](../../../knowledge/assets/libraries-05-ServiceAvailability/ServiceAvailability_SequenceDiagramUtil.jpg) - -#### 画面オンライン - -画面オンライン時におけるシーケンス図を下記に示す。 - -* ServiceAvailabilityCheckHandlerは、リクエストIDをもとにサービス提供可否状態を判定する。 -* リクエストIDは、ServiceAvailabilityCheckHandlerよりも先に処理を行うハンドラにより、ThreadContextに設定しておく必要がある。ThreadContextへの設定は、 [スレッドコンテキスト変数管理ハンドラ](../../component/handlers/handlers-ThreadContextHandler.md#スレッドコンテキスト変数管理ハンドラ) が行う。 -* サービス提供不可の場合、一律サービス提供不可エラー画面へ遷移する。 - -![ServiceAvailability_SequenceDiagram.jpg](../../../knowledge/assets/libraries-05-ServiceAvailability/ServiceAvailability_SequenceDiagram.jpg) - -### テーブル定義の例 - -* テーブル名、カラム名は任意。 -* データベースの型は、Javaの型に変換可能な型を選択する。 - -![ServiceAvailability_ERDiagram.jpg](../../../knowledge/assets/libraries-05-ServiceAvailability/ServiceAvailability_ERDiagram.jpg) - -#### リクエスト - -リクエストテーブルには、リクエストごとのサービス提供可否状態を格納する。 - -| 定義 | Javaの型 | 制約 | -|---|---|---| -| リクエストID | java.lang.String | PK | -| リクエスト名 | java.lang.String | | -| サービス提供可否状態 | java.lang.String | | - -「リクエスト名」カラムは、保守の際など業務的に使用する項目であり、本機能では使用しない。 -「サービス提供可否状態」カラムには、サービス提供可能状態を表す値を設定する。 -標準ではサービス提供可否状態の値として"1"が設定されている場合に、サービス提供可能だと判定するが、 -設定ファイルを修正することでこの値を変更できる。 -詳細は [nablarch.core.web.service.BasicServiceAvailabilityクラスの設定](../../component/libraries/libraries-05-ServiceAvailability.md#nablarchcorewebservicebasicserviceavailabilityクラスの設定) を参照すること。 - -## 設定の記述 - -開閉局機能は、リポジトリ機能を利用して設定を行う。 - -### 全処理方式共通 - -```xml - - - - - - - - - - - - - - - - - - - - - -``` - -BasicServiceAvailabilityクラスは初期化が必要なため、 [初期化処理の使用手順](../../component/libraries/libraries-02-02-Repository-initialize.md#初期化処理の使用手順) に記述したInitializableインタフェースを実装している。 -[初期化処理の使用手順](../../component/libraries/libraries-02-02-Repository-initialize.md#初期化処理の使用手順) を参考にして、下記のように serviceAvailabilityCheckHandler.serviceAvailability が初期化されるよう設定すること。 - -```xml - - - - - - - - -``` - -#### 設定内容詳細 - -##### nablarch.core.web.service.BasicServiceAvailabilityクラスの設定 - -| property名 | 設定内容 | -|---|---| -| dbManager(必須) | データベースへのトランザクション制御を行うSimpleDbTransactionManager。 nablarch.core.db.transaction.SimpleDbTransactionManagerクラスのインスタンスを指定する。 SimpleDbTransactionManagerについては、 [データベースアクセス(検索、更新、登録、削除)機能](../../component/libraries/libraries-04-DbAccessSpec.md) を参照すること。 | -| tableName(必須) | リクエストテーブルの名前。 | -| requestTableRequestIdColumnName(必須) | リクエストテーブルのリクエストIDカラムの名前。 | -| requestTableServiceAvailableColumnName(必須) | リクエストテーブルのサービス提供可否状態カラムの名前。 | -| requestTableServiceAvailableOkStatus | リクエストテーブルのサービス提供可否状態カラムに設定されるサービス提供可能な状態の値。本プロパティを省略した場合、「1」が設定される。 | - -##### nablarch.common.handler.ServiceAvailabilityCheckHandlerの設定 - -| property名 | 設定内容 | -|---|---| -| serviceAvailability(必須) | ServiceAvailabilityインタフェースを実装したクラスを設定する。 | diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-StaticDataCache.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-StaticDataCache.md deleted file mode 100644 index f69b4a9e8..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-05-StaticDataCache.md +++ /dev/null @@ -1,481 +0,0 @@ -# 静的データのキャッシュ - -## 概要 - -頻繁にアクセスする静的データをRDBMSやXMLファイル等の媒体に永続化している場合、媒体へのアクセス速度がアプリケーションの -パフォーマンスを大きく劣化させることがある。 - -本機能はこのようなデータアクセスによるパフォーマンスの劣化を抑えるために、静的データをよりアクセス速度が早い媒体にキャッシュ -することで、アクセスを高速化する機構を提供する。 - -本機能は、リポジトリに登録して使用する。 -このため、本機能に必要な初期化処理は [リポジトリ](../../component/libraries/libraries-02-Repository.md#リポジトリ) が実行する。 - -また、本機能は他の機能の一部として使用されることを想定しており、単体で使用することはない。 -このため、アプリケーションプログラマは、本機能を直接使用することはない。 - -## 特徴 - -### 静的データキャッシュの実装負荷軽減 - -本機能では、キャッシュしたデータの保持や、 -キャッシュにデータが存在しなかった場合にロードする処理を本機能が提供するクラスが行う。 - -このため、キャッシュを使用する機能を実装する際に必要な実装が、静的データをRDBMSやXMLファイル等の媒体から -ロードする処理と、キャッシュした静的データを使用する処理の2つのみに集約され、実装負荷を軽減できる。 - -### インデックス機能 - -本機能は、キャッシュに保持した静的データの中から特定の値を持つ複数のデータを効率よく取得する機能を持つ。 -この機能をインデックス機能と呼ぶ。 -インデックス機能では、キャッシュから静的データを取得する際、ID以外の特定のキー(インデックスキー)を指定する。 -インデックス機能を使用することで、ID以外のキーで頻繁にアクセスする静的データにも高速なアクセスが可能となる。 - -## 要求 - -### 実装済み - -* 任意のクラスの静的データをキャッシュできる。 -* IDを指定してキャッシュから静的データを取得できる。 -* 任意のインデックスキーを指定して、キャッシュから複数の静的データを取得できる。 -* アプリケーション起動時に永続化した媒体から静的データをロードできる。 -* 静的データが必要になったタイミングで永続化した媒体からロードできる。 -* プロセスを再起動することなく再ロードできる。 - -### 未検討 - -* 頻繁に参照されない静的データをキャッシュから削除することでメモリを節約できる。 -* 複数のJavaプロセスでキャッシュした静的データを共有できる。 -* ファイルから静的データをロードできる。 -* SQL文を記述するだけで、データベース上にある静的データをキャッシュできる。 - -## 構成 - -### クラス図 - -![05_StaticDataCache_Class.jpg](../../../knowledge/assets/libraries-05-StaticDataCache/05_StaticDataCache_Class.jpg) - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.cache.StaticDataCache | 静的データのキャッシュを保持するインタフェース。 | -| nablarch.core.cache.StaticDataLoader | 静的データをロードするインタフェース。 RDBMSやXMLファイル等の媒体から静的データをクラスはこのインタフェースを実装する。 | - -#### クラス定義 - -| クラス名 | 概要 | -|---|---| -| nablarch.core.cache.StaticDataCache | StaticDataCacheインタフェースの基本実装クラス。 静的データをHashMapに保持する。 | - -## キャッシュした静的データの取得 - -概要で述べた通り、静的データキャッシュは、静的データキャッシュを使用する必要のあるクラスの一部として使用することを想定している。 - -キャッシュする必要のあるクラスは、データのキャッシュを行う StaticDataCache インタフェースをフィールドに持ち、 -StaticDataCache インタフェースのメソッドを使用して静的データを取得する。 - -この際、StaticDataCache インタフェースを実装したフィールドには、本機能が提供している StaticDataCache インタフェースの実装クラスを -リポジトリの [リポジトリに保持するインスタンスの生成(DIコンテナ)](../../component/libraries/libraries-02-01-Repository-config.md#リポジトリに保持するインスタンスの生成diコンテナ) の機能で設定する。 - -以下に静的データを取得する実装方法について記述する。 - -### IDを指定した静的データの取得 - -静的データは、 StaticDataCache インタフェースの getValue メソッドまたは getValues メソッドで取得する。 -StaticDataCache インタフェースを実装したクラスは、キャッシュにデータが存在しない場合には必要に応じてデータを取得する。 -このため、呼び出し元は静的データがキャッシュに存在するか否かを意識する必要がない。 - -以下にキャッシュされるデータを保持する ExampleData クラスと、キャッシュに保持した ExampleData クラスを使用するクラスの実装例を示す。 - -#### キャッシュされるデータを保持するクラス(ExampleData) - -```java -public class ExampleData { - private String id; - private String name; - - // setter, getterは省略 -} -``` - -#### キャッシュしたデータを使用するクラス - -```java -public class StaticDataUseExample { - // DIによりStaticDataを設定 - private StaticDataCache cache; - - public void setCache(StaticDataCache cache) { - this.cache = cache; - } - - public void getById(String id) { - // キャッシュからデータを取得する - // 利用者は、キャッシュにデータがあるかを意識する必要はない - ExampleData obj = cache.getValue(id); - System.out.println("id = " + obj.getId()); - System.out.println("name = " + obj.getName()); - } -} -``` - -> **Warning:** -> StaticDataCache#getValue メソッドまたは StaticDataCache#getValues メソッドで取得した静的データは、 -> クラスおよびインスタンスのフィールドに保持しないこと。 -> これは、クラスおよびインスタンスのフィールドに保持された静的データが、後述する StaticDataCache -> のリロード機能が呼ばれた際に更新されない問題があるためである。 - -### インデックスを使用した静的データの取得 - -本機能は、ID以外のキーを指定して静的データを取得できるインデックス機能を持つ。 -インデックス機能では、IDのように1つのキーに1つの静的データを紐付けるだけでなく、 -1つのキーに複数の静的データを紐付けられる。 - -インデックスを StaticDataCache インタフェースに定義された getValues メソッドを使用する。 - -[IDを指定した静的データの取得](../../component/libraries/libraries-05-StaticDataCache.md#idを指定した静的データの取得) で示した ExampleData クラスを "name" というインデックスを使用して静的データを取得する実装例を以下に示す。 - -```java -public class StaticDataUseExample { - // DIによりStaticDataを設定 - private StaticDataCache cache; - - public void setCache(StaticDataCache cache) { - this.cache = cache; - } - - public void getByName(String name) { - // キャッシュからデータを取得する - // 利用者は、キャッシュにデータがあるかを意識する必要はない - List objs = cache.getValues("name", name); - for (ExampleData obj : objs) { - System.out.println("id = " + obj.getId()); - System.out.println("name = " + obj.getName()); - } - } -} -``` - -## キャッシュにデータをロードする方法 - -本機能では、キャッシュにデータをロードする方法にオンデマンドロードと一括ロードの2種類の方法を提供している。 - -以下にそれぞれの方法の特徴と、処理順序の概要を記述する。 - -### オンデマンドロード - -オンデマンドロードでは、キャッシュにデータがなかった際に、自動的にデータをロードする。 -これに対して一括ロードでは、アプリケーション起動時に全てのデータをキャッシュにロードする。 - -オンデマンドロードは、一括ロードに対してアプリケーションの起動が速い利点がある。 -このため、使用するデータがキャッシュに保持するデータの一部に偏る場面で有利なロード方法となる。 -このような場面には、バッチやテスト時に使用するメッセージなどが想定される。 - -オンデマンドロード時の処理順序は下記シーケンス図のようになる。 - -![05_StaticDataCache_LoadOnDemandSequence.jpg](../../../knowledge/assets/libraries-05-StaticDataCache/05_StaticDataCache_LoadOnDemandSequence.jpg) - -### 一括ロード - -一括ロードは、起動してしまえば全てのデータがキャッシュに存在するため、 -オンデマンドロードがキャッシュにデータが存在しなかった際(キャッシュミスヒット時)に若干処理が遅くなる問題を回避できる。 -このため、使用するデータがキャッシュに保持するデータのほぼ全てとなる場面で有利なロード方法となる。 -このような場面には、Webアプリケーションで使用するメッセージなどが想定される。 - -一括ロード時の処理順序は下記シーケンス図のようになる。 - -![05_StaticDataCache_LoadOnStartupSequence.jpg](../../../knowledge/assets/libraries-05-StaticDataCache/05_StaticDataCache_LoadOnStartupSequence.jpg) - -いずれの方法でも、 [IDを指定した静的データの取得](../../component/libraries/libraries-05-StaticDataCache.md#idを指定した静的データの取得) で示した通り、 -キャッシュを使用する実装にはデータがどのようにロードされているか意識する必要がない。 - -それぞれのロードの使用方法について、以下に記述する。 - -## オンデマンドロードの使用方法 - -オンデマンドロードを使用する際データロードの実装方法について、IDを指定してデータを取得する際に必要なデータロードの実装方法と、 -インデックスを指定してデータを取得する際に必要なデータロードの実装方法について以下に記述する。 - -### IDを指定してデータを取得する際に必要なデータロードの実装方法 - -データをロードする処理は、 StaticDataLoader インタフェースを実装したクラスに実装する。 - -StaticDataLoader インタフェースには、IDを使用するキャッシュへのアクセスと、インデックスを使用したキャッシュへのアクセスに必要なメソッドが定義されている。 - -[IDを指定した静的データの取得](../../component/libraries/libraries-05-StaticDataCache.md#idを指定した静的データの取得) で示した、IDを指定してデータを取得する機能のみをオンデマンドロードで使用する場合、 -StaticDataLoaderインタフェースに定義されたgetValueメソッドのみを実装すればよい。 - -以下に [IDを指定した静的データの取得](../../component/libraries/libraries-05-StaticDataCache.md#idを指定した静的データの取得) で例に出した ExampleData をロードするクラスと、 StaticDataCache を使用するための設定ファイルの例を示す。 - -#### ExampleDataをロードするクラス - -```java -// ******** 注意 ******** -// 下記のコードはフレームワークが行う処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -public class ExampleDataLoader implements StaticDataLoader { - /** - * データロードに使用するSimpleDbTransactionManagerのインスタンス。 - */ - private SimpleDbTransactionManager dbManager; - - public ExampleData getValue(final Object id) { - - return new SimpleDbTransactionExecutor(dbManager) { - @Override - public ExampleData execute(AppDbConnection connection) { - // 永続化したオブジェクトをロード - SqlPStatement stmt = connection - .prepareStatement("select id, name from example_data where id = ? order by id"); - stmt.setString(1, (String) id); - SqlResultSet results = stmt.retrieve(); - if (results.size() > 0) { - SqlRow row = results.get(0); - ExampleData obj = createData(row); - return obj; - } else { - return null; - } - } - }.doTransaction(); - } - - // ...getValues以外のメソッドは省略... -} -``` - -#### 設定ファイル - -```xml - - - - - - - - - - - - - - - - - - - -``` - -### インデックスを指定してデータを取得する際に必要なデータロードの実装方法 - -オンデマンドロード時に、インデックスを使用して静的データを取得するには、 StaticDataLoader の getValues メソッドと -ロードしたデータに対するIDを取得する getId メソッドを実装する必要がある。 - -getValues メソッドはデータをロードする目的、 getId メソッドは、同一の静的データを2重に保持しない目的でそれぞれ -フレームワークから呼び出される。 - -このため、getIdメソッドは静的データを一意に決定する値を返すように実装されている必要がある。 - -以下に:ref:static_data_cache_get_example で例に出した ExampleData クラスの name をインデックスキーとして、インデックスを使用する場合の getValues の実装例を示す。 - -```java -// ******** 注意 ******** -// 下記のコードはフレームワークが行う処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -public class ExampleDataLoader implements StaticDataLoader { - - public List getValues(final String indexName, final Object key) { - - return new SimpleDbTransactionExecutor>(dbManager) { - @Override - public List execute(AppDbConnection connection) { - if (indexName.equals("name")) { - String name = (String) key; - // 永続化したオブジェクトをロード - SqlPStatement stmt = connection.prepareStatement("select id, name from example_data where name = ? order by id"); - stmt.setString(1, (String) name); - SqlResultSet results = stmt.retrieve(); - List objs = new ArrayList(); - for (SqlRow row : results) { - objs.add(createData(row)); - } - return objs; - } else { - throw new IllegalArgumentException("invalid indexName: indexName = " + indexName); - } - - } - }.doTransaction(); - } - - public Object getId(ExampleData value) { - // オブジェクトの持つidを取得する。 - return value.getId(); - } - // ...getValues以外のメソッドは省略... -} -``` - -## 一括ロード - -一括ロードを使用する際データロードの実装方法と設定方法について以下に記述する。 - -### データロードの実装方法 - -一括ロードを使用する際は、 StaticDataLoader インタフェースに定義されたメソッドのうち、 loadAll, getId, generateIndexKey, -getIndexNames の4つのメソッドを実装する必要がある。 -これらメソッドの用途は下記表の通り。 - -| メソッド名 | 用途 | -|---|---| -| loadAll | キャッシュするデータを取得する。 フレームワークはこのメソッドで返される全てのデータをキャッシュの初期データとして保持する。 | -| getId | データからデータのIDを取得する。 フレームワークは、このメソッドで返されるオブジェクトを java.util.Map のキーとしてデータを保持する。 このため、このメソッドの戻り値は、キャッシュ上で一意にオブジェクトでなくてはならない。 例えばデータベース上の複合キーでユニークとなるデータをキャッシュする場合、 equals メソッドと hashCode メソッドを適切に実装した、複合キーを表わすクラスを作成し、 このクラスのインスタンスをこのメソッドの戻り値とする。 | -| getIndexNames | 作成するインデックス名を全て取得する。 フレームワークは、このメソッドの戻り値から作成するインデックスを決定する。 | -| generateIndexKey | インデックスのキーとなる値を生成する。 ここで生成されるキーは、 getId がオブジェクトのキャッシュに使用されるのに対して、 インデックス上のどのキーにオブジェクトが属するかを示すために使われる。 このため、別々のデータ | - -以下に [IDを指定した静的データの取得](../../component/libraries/libraries-05-StaticDataCache.md#idを指定した静的データの取得) で例に出した ExampleData を一括ロードする実装例を示す。 - -#### ExampleDataをロードするクラス - -```java -// ******** 注意 ******** -// 下記のコードはフレームワークが行う処理であり、通常のアプリケーションでは実装する必要がない。 -// 従って、本フレームワークを使用する場合、アプリケーション・プログラマはこのような実装を行わない。 - -public class ExampleDataLoader implements StaticDataLoader { - - public Object getId(ExampleData value) { - // オブジェクトの持つidを取得する。 - return value.getId(); - } - - public Object generateIndexKey(String indexName, ExampleData value) { - // オブジェクトからインデックスのキー値を取得する。 - if (indexName.equals("name")) { - return value.getName(); - } else { - throw new IllegalArgumentException( - "invalid indexName: indexName = " + indexName); - } - } - - public List getIndexNames() { - // インデックスの名称を返す。 - // この例ではインデックス"name"のみ作成している - List indexNames = new ArrayList(); - indexNames.add("name"); - return indexNames; - } - - public List loadAll() { - - return new SimpleDbTransactionExecutor>(dbManager) { - @Override - public List execute(AppDbConnection connection) { - // キャッシュにロードする全てのオブジェクトを取得する - SqlPStatement stmt = connection - .prepareStatement("select id, name from example_data order by id"); - SqlResultSet results = stmt.retrieve(); - List objs = new ArrayList(); - for (SqlRow row : results) { - objs.add(createData(row)); - } - return objs; - } - }.doTransaction(); - } - - // ...getId, generateIndexKey, getIndexNames, loadAll以外のメソッドは省略... -} -``` - -### 設定例 - -一括ロードを行う場合、 BasicStaticDataCache の loadOnStartup プロパティに true を設定する必要がある。 -その他の設定方法はオンデマンドロード時と同様となる。 - -以下に設定例を示す。 - -```xml - - - - - - - - - - - - - -``` - -また BasicStaticDataCache クラスは初期化が必要なため、 [初期化処理の使用手順](../../component/libraries/libraries-02-02-Repository-initialize.md#初期化処理の使用手順) に記述した Initializable インタフェースを実装している。 -[初期化処理の使用手順](../../component/libraries/libraries-02-02-Repository-initialize.md#初期化処理の使用手順) を参考にして、下記のように exampleDataCache が初期化されるよう設定すること。 - -```xml - - - - - - - - -``` - -## 設定内容詳細 - -### nablarch.core.cache.BasicStaticDataCacheの設定 - -| property名 | 設定内容 | -|---|---| -| loader(必須) | 静的データをロードする、 StaticDataLoader インタフェースを実装したクラスのインスタンスを指定する。 | -| loadOnStartup | 一括ロードの要否を設定する。 指定しなければ一括ロードしない。 | - -## 静的データの再読み込み - -静的データは、元となるデータが更新された際には再読み込みを行う必要がある。 -アプリケーションの再起動が頻繁に行えない場合、静的データのリロード機能を使用することで再起動なしに -静的データの再読み込みができる。 - -静的データの再読み込みを行うには、 StaticDataCache インタフェースの refresh メソッドを呼び出せばよい。 - -### 実装例 - -以下に再読み込みを行うクラスの実装例を示す。 - -```java -// ******** 注意 ******** -// 下記のコードはプロジェクトのアーキテクトが作成するものである。 -// 通常、各アプリケーション・プログラマはこのような実装を行わない。 - -public class StaticDataUseExample { - // DIによりStaticDataを設定 - private StaticDataCache cache; - - public void setCache(StaticDataCache cache) { - this.cache = cache; - } - - public void refreshAndGetValue(String name) { - - // キャッシュをリロードする - cache.refresh(); - - // キャッシュから静的データを取得する - // 使用者は、静的データがキャッシュにあるかを意識する必要はない - List objs = cache.getValues("name", name); - for (ExampleData obj : objs) { - System.out.println(obj); - } - } -} -``` diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-FileUpload.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-FileUpload.md deleted file mode 100644 index f87e65c4a..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-FileUpload.md +++ /dev/null @@ -1,18 +0,0 @@ -# ファイルアップロード - -## 概要 - -ファイルアップロード機能は、 [マルチパートリクエストハンドラ](../../component/handlers/handlers-MultipartHandler.md) により実現される。 -本ハンドラは、アップロードされたファイルを当該HTTPリクエストに紐付ける。 -アプリケーションからは、 `HttpRequest#getPart(java.lang.String)` -により取得できる。 - -## ファイルアップロード機能に関する設定 - -ファイルサイズ上限値など、アップロード機能に関する設定については、 - [マルチパートリクエストハンドラ](../../component/handlers/handlers-MultipartHandler.md) を参照。 - -## アプリケーション実装方法 - -ファイルを移動する、DBに登録する、といった具体的なアプリケーション実装方法については、 - [ファイルアップロード業務処理用ユーティリティ](../../component/libraries/libraries-file-upload-utility.md) を参照。 diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-IdGenerator.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-IdGenerator.md deleted file mode 100644 index d78fe2f8b..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-IdGenerator.md +++ /dev/null @@ -1,249 +0,0 @@ -# 採番機能 - -## 概要 - -アプリケーションで使用するID(例えば取引明細ID等)を採番するための汎用的な機能を提供する。 - -本機能は、リポジトリに登録して使用する。 -このため、本機能に必要な初期化処理は [リポジトリ](../../component/libraries/libraries-02-Repository.md#リポジトリ) が実行する。 - -また、本機能は各プロジェクトでアーキテクトが作成する採番機能において使用されることを想定しており、単体で使用することはない。 -このため、アプリケーションプログラマは、本機能を直接使用することはない。 - -> **Note:** -> 本章で登場するデータベースに関する記述の詳細は、下記ドキュメントを参照すること。 - -> * > [データベースアクセス(検索、更新、登録、削除)機能](../../component/libraries/libraries-04-DbAccessSpec.md) -> * > [データベースコネクション名とトランザクション名](../../component/libraries/libraries-04-TransactionConnectionName.md) - -## 特徴 - -### 採番方法を選択可能 - -採番方法を採番単位(取引IDや、売上明細ID等の単位)で指定できるため、抜け番を許容するIDと許容しないIDで採番方法を切り替える事が可能となっている。 -また、各データベースベンダーによって提供されている採番機能(Oracleのシーケンスオブジェクト等)を使用したい場合は、設定ファイルの変更のみで切り替え可能となっている。 - -### 採番した値をフォーマット出来る機能 - -各プロジェクトで独自のフォーマットを自由に追加、拡張することが可能となっている。 - -## 要求 - -### 実装済み - -* 連番(抜け番を出さない) [1] を採番できる。 -* 高速な採番処理を選択できる。 - - 高速に採番する機能は、抜け番が発生する可能性があり、連番 [1] には対応していない。 - - * テーブルを使用して採番を行うが、ロック待機を最小限に抑え高速に採番できる。 -* 採番付加機能 - - * フォーマットを指定できる。 - - * 採番したIDの桁数を揃えることができる。 - -連番とは、業務処理が確定(コミット)したタイミングで採番したIDが確定し抜け番が発生しないIDのことを指す。 - -### 未実装機能 - -* テーブル採番を使用した場合に、サイクリック指定できる。 -* データベースベンダー固有の機能を使用して高速に採番できる。 - - * Oracleシーケンスを使用して採番できる。 - * DB2シーケンスを使用して採番できる。 -* より高速な採番処理を選択できる。 - - * テーブルを使用して採番を行うが、一部をメモリ上で採番し、より高速に採番できる。(HILOアルゴリズム) -* 採番付加機能 - - * 採番したIDの先頭に業務日付を付加できる。 - * 採番したIDの先頭にシステム日付を付加できる。 - * 採番した値を初期化できる。 - -## 構造 - -### クラス図 - -![IdGenerator_ClassDiagram.jpg](../../../knowledge/assets/libraries-06-IdGenerator/IdGenerator_ClassDiagram.jpg) - -### 各クラスの責務 - -#### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.common.idgenerator.IdGenerator | IDを採番するインタフェース。 各プロジェクトで独自の採番実装が必要となった場合には、本インタフェースを実装することにより実現可能となっている。 | -| nablarch.common.idgenerator.IdFormatter | 採番したIDをフォーマットするインタフェース。 各プロジェクトで独自のフォーマットを行う必要がある場合は、本インタフェースを実装することにより実現可能となっている。 | - -#### クラス定義 - -a) nablarch.common.idgenerator.IdGeneratorの実装クラス - -| クラス名 | 概要 | -|---|---| -| テーブルを使用した採番クラス | | -| nablarch.common.idgenerator.TableIdGenerator | テーブル(採番用テーブル)を使用して、抜け番を発生させずに採番を行うクラス。 本クラスは、アプリケーションと同一のトランザクションを使用して採番処理を行う。 これにより業務処理と同じタイミングで採番された値が確定されるため、抜け番の発生を防止する事ができる。 また、業務処理の確定順に採番を行うことができる。 > **Warning:** > 業務トランザクションと同一のトランザクションが使用されるため、業務処理のトランザクションが確定するまで、 > 採番用テーブルのロックが保持された状態となる。 > ロックが保持されている状態で、他の処理が同一のIDを採番しようとすると、ロック解放待ちとなるため性能劣化の原因になる。 > このため、業務的に抜け番が許容されるIDの場合には、抜け番の可能性がある採番(FastTableIdGeneratorやSequenceIdGeneratorSupport) > を使用することを強く推奨する。 > 特にDB2やSQLServerを使用した場合は、ロックエスカレーション(ロックの範囲がレコードではなく、ページやテーブルへと拡大すること)が発生し、 > ロック待機がより広範囲に広がり、性能劣化がより顕著となる可能性があるため注意が必要である。 | -| nablarch.common.idgenerator.FastTableIdGenerator | テーブル(採番用テーブル)を使用して、高速に採番を行うクラス。 本クラスは、アプリケーションとは異なるトランザクションを使用して採番処理を行い、即時にコミット処理を行う。 このため、ロック待機時間を最小限に抑えることができ、高速に採番処理を行うことができる。 本クラスは、テーブルを使用した採番部分はTableIdGeneratorに委譲して行い、トランザクション制御のみを実装している。 | - -b) nablarch.common.idgenerator.IdFormatterの実装クラス - -| クラス名 | 概要 | -|---|---| -| nablarch.common.idgenerator.formatter.LpadFormatter | 採番されたIDの桁数を揃えるフォーマッタークラス。 指定された桁数になるまで、指定された文字を先頭に付加する。 | - -## テーブルを使用した採番機能 - -本章では、テーブルを使用した採番機能についての説明を行う。 - -### 採番テーブルの構造 - -採番テーブルの構造例 - -| カラム | 型(Oracleの場合) | 備考 | -|---|---|---| -| ID | CHAR(4) | 採番対象を識別するためのID(採番対象ID)を格納するカラム | -| NO | NUMBER(10) | 採番対象IDの中で採番された値の最大値を保持するカラム | - -> **Note:** -> テーブル名やカラム名は、各プロジェクトの規約にしたがい命名することが考えられる。 -> このため、リポジトリ機能を使用して任意の名前を設定できるようになっている。 - -### シーケンス図 - -#### 抜け番を出さない採番 - -![IdGenerator_SequenceDiagram1.jpg](../../../knowledge/assets/libraries-06-IdGenerator/IdGenerator_SequenceDiagram1.jpg) - -#### 抜け番を出す可能性のある採番 - -![IdGenerator_SequenceDiagram2.jpg](../../../knowledge/assets/libraries-06-IdGenerator/IdGenerator_SequenceDiagram2.jpg) - -### 使用例 - -#### テーブルデータ例 - -| ID | NO | 補足説明 | -|---|---|---| -| 1101 | 0 | サンプルID用レコード | -| 1102 | 10 | サンプルID2用レコード | - -#### プロジェクト毎の採番クラスの実装例 - -```java -// ******** 注意 ******** -// 下記のコードはプロジェクトのアーキテクトが作成するものである。 -// 通常、各アプリケーション・プログラマはこのような実装を行わない。 - -public class SampleGenerator { - - /** - * サンプルIDを採番する。
- * @reutrn サンプルID - */ - public static String generateSampleId() { - // フォーマットが不要な場合 - IdGenerator generator = (IdGenerator) SystemRepository.getObject("tableIdGenerator"); - return generator.generateId("1101", null); // 1が返却される。 - } - - /** - * サンプルID２を採番する。
- * @reutrn サンプルID2(10桁で先頭0埋めされた値) - */ - public static String generateSampleId2() { - // フォーマットが必要となる場合 - IdGenerator generator = (IdGenerator) SystemRepository.getObject("fastTableIdGenerator"); - return generator.generateId("1102", new LpadFormatter(10, '0')); // 0000000011が返却される。 - } -} -``` - -#### 設定ファイルの定義 - -```xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -##### 設定内容詳細 - -a) 連番を採番するクラスの設定 - -a)-1. componentの設定 - -| 属性値 | 設定内容 | -|---|---| -| name(必須) | 任意の値を設定する。 各プロジェクトで作成する採番クラスが、SystemRepositoryから IdGeneratorを取得する際に使用する値となる。 | -| class(必須) | nablarch.common.idgenerator.TableIdGenerator | - -a)-2. nablarch.common.idgenerator.TableIdGeneratorの設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | 採番テーブルのテーブル物理名設定する。 | -| idColumnName(必須) | 採番テーブルのIDカラムの物理名を設定する。 | -| noColumnName(必須) | 採番テーブルのNOカラムの物理名を設定する。 | -| dbTransactionName | データベースコネクション名を設定する。 ビジネスロジックで無名のデータベース接続を使用する場合は、設定不要。 > **Warning:** > 無名のデータベース接続以外を使用する場合(本設定値を記述する場合)は、 > 必ずアプリケーションで使用するデータベース接続と同一のデータベースコネクション名を設定すること。 | - -※採番テーブルのレイアウトは、 [採番テーブルの構造](../../component/libraries/libraries-06-IdGenerator.md#採番テーブルの構造) を参照。 - -b) 高速に採番を行うクラスの設定 - -b)-1. componentの設定 - -| 属性値 | 設定内容 | -|---|---| -| name(必須) | 任意の値を設定する。 各プロジェクトで作成する採番クラスが、SystemRepositoryから IdGeneratorを取得する際に使用する値となる。 | -| class(必須) | nablarch.common.idgenerator.FastTableIdGenerator | - -b)-2. nablarch.common.idgenerator.FastTableIdGeneratorの設定 - -| property名 | 設定内容 | -|---|---| -| tableName(必須) | 採番テーブルのテーブル物理名設定する。 | -| idColumnName(必須) | 採番テーブルのIDカラムの物理名を設定する。 | -| noColumnName(必須) | 採番テーブルのNOカラムの物理名を設定する。 | -| dbTransactionManager(必須) | nablarch.core.db.transaction.SimpleDbTransactionManagerを設定する。 このクラスを使用して、トランザクション制御を行う。 | - -b)-3. nablarch.core.db.transaction.SimpleDbTransactionManagerの設定 - -SimpleDbTransactionManagerへの設定は、本機能で必要なプロパティのみ記載している。 -ここに記載のない設定値は、データベース機能を参照すること。 - -| property名 | 設定内容 | -|---|---| -| dbTransactionName | データベーストランザクション名を設定する。 本設定値が設定されていない場合は、データベーストランザクション名に、 「nablarch.common.idgenerator.FastTableIdGenerator」を自動で設定し、トランザクション制御を行う。 > **Warning:** > 本設定値を設定する場合には、ビジネスロジックで使用するトランザクション名と異なる値を設定すること。 > ビジネスロジックで使用するトランザクションと同一の名前を指定した場合、トランザクション開始時に例外が発生する。 | diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-SystemTimeProvider.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-SystemTimeProvider.md deleted file mode 100644 index 8f6d51c85..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-06-SystemTimeProvider.md +++ /dev/null @@ -1,278 +0,0 @@ -# 日付の管理機能 - -## 概要 - -業務日付とシステム日時(OS日時)の管理(取得)機能を提供する。あわせて、日付ユーティリティについても説明する。 - -## 特徴 - -### 高い拡張性 - -業務日付、システム日時の取得方法は切り替えることができる。これにより、本機能で提供されている機能では満たされない要件が出てきた場合でも柔軟に対応することができる。 - -### 業務日付は複数設定が可能 - -例えばオンラインとバッチで別の業務日付を使用するなど、複数の業務日付を設定できる。これにより、各業務日付ごとに個別の更新タイミングを指定することが可能である。 - -## 要求 - -### 実装済み - -* システム日付を取得できる。 -* 業務日付を取得できる。 -* 業務日付を複数管理できる。 -* 業務日付を任意の日付に上書き出来る。 - 例えばバッチ処理で障害時の再実行時に過去日付をバッチ実行時の業務日付としたい場合がある。 - このような場合に、再実行を行うプロセスのみ任意の日付を業務日付として実行することが出来る。 -* 業務日付をメンテナンスできる。 - -### 未実装 - -## 構造 - -### システム日時機能 - -本章では、システム日時機能について説明を行う。システム日時とは、OS日時(サーバ日時)のことを指し、業務日付のように営業日や非営業日の考え方を持たない日時である。 - -#### クラス図 - -![Date_SystemTime_ClassDiagram.jpg](../../../knowledge/assets/libraries-06-SystemTimeProvider/Date_SystemTime_ClassDiagram.jpg) - -##### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.date.SystemTimeProvider | システム日時を取得するインタフェース。本インタフェースの実装クラスを追加することにより、システム日時の取得方法を切り替えることができる。 | - -##### クラス定義 - -| クラス名 | 概要 | -|---|---| -| nablarch.core.date.BasicSystemTimeProvider | SystemTimeProviderの基本実装クラス。本クラスでは、JVMの稼働マシンのシステム日時(new java.util.Date())を取得する。 | -| nablarch.core.date.SystemTimeUtil | システム日時を取得するクラス。アプリケーションでは、本クラスからシステム日時を取得する。 | - -#### SystemTimeUtilで提供される機能では不足している場合の対応方法 - -SystemTimeUtilで提供される機能に不足がある場合には、下記のサンプル実装のようにプロジェクト固有のシステム日時取得クラスを追加し対応すること。 - -```java -// ******** 注意 ******** -// 本実装例は、各プロジェクトのアーキテクトが実装すべきクラスである。 -// このため、このようなクラスをアプリケーションプログラマが実装することはない。 - -public class SampleSystemTimeUtil { - /** - * システム日時を取得する。 - * @return システム日時 - */ - public static Date getDate() { - // SystemTimeUtilで実装されている機能については、SystemTimeUtilに処理を移譲する。 - return SystemTimeUtil.getDate(); - } - - //******************************************************************************** - // getDateと同じように、SystemTimeUtilで提供されている機能の、メソッドを実装する。 - //******************************************************************************** - - // プロジェクト固有の実装を行う。 - - /** - * システム時間を取得する。 - * @return システム時間 - */ - public static Time getTime() { - return new Time(SystemTimeUtil.getDate().getTime()); - } -} -``` - -### 業務日付機能 - -本章では、業務日付機能について説明を行う。 - -#### クラス図 - -![Date_BusinessDate_ClassDiagram.jpg](../../../knowledge/assets/libraries-06-SystemTimeProvider/Date_BusinessDate_ClassDiagram.jpg) - -##### インタフェース定義 - -| インタフェース名 | 概要 | -|---|---| -| nablarch.core.date.BusinessDateProvider | 業務日付を取得・設定するインタフェース。本インタフェースの実装クラスを追加することにより、業務日付の取得方法の切り替え・業務日付の設定をすることができる。 | - -##### クラス定義 - -| クラス名 | 概要 | -|---|---| -| nablarch.core.date.BasicBusinessDateProvider | BusinessDateProviderの基本実装クラス。本クラスでは、データベースから業務日付を取得・設定する。 | -| nablarch.core.date.BusinessDateUtil | 業務日付を取得するクラス。アプリケーションでは、本クラスから業務日付を取得する。 | - -#### テーブル定義 - -BasicBusinessDateProviderを使用する場合、以下に示すデータベーステーブルを用意する。テーブル名およびカラム名に制約はなく、 -設定( [設定ファイル](../../component/libraries/libraries-06-SystemTimeProvider.md#設定ファイル) 参照)により任意の名称が使用できる。 - -##### 業務日付テーブル - -| 定義 | Javaの型 | 制約 | 備考 | -|---|---|---|---| -| 区分 | java.lang.String | プライマリキー | | -| 日付 | java.lang.String | | 値はyyyyMMdd形式であること | - -##### テーブル定義の例 - -![Date_BusinessDate_EntityDiagram.jpg](../../../knowledge/assets/libraries-06-SystemTimeProvider/Date_BusinessDate_EntityDiagram.jpg) - -#### 複数の業務日付の設定 - -本フレームワークでは、設定したい業務日付ごとに区分を与えることで、複数の業務日付を管理する設計となっている。 - -基本実装クラスでは、区分で業務日付テーブルを検索し、取得したレコードの日付を返す。区分の割り振り方は、重複しないこと以外に制限はない。 -業務日付を取得する際に区分を指定しない場合は、設定ファイル( [設定ファイル](../../component/libraries/libraries-06-SystemTimeProvider.md#設定ファイル) 参照)で設定した区分を指定されたものとして、業務日付を取得する。 - -#### 設定ファイル - -設定ファイルの記述を説明する。まず、設定ファイル例を示し、次に各設定項目の詳細を説明する。 - -* 設定ファイル例 - - ```xml - - - - - - - - - - ``` -* componentの設定 - - | 属性値 | 設定値 | - |---|---| - | name(必須) | "businessDateProvider"と設定する。 | - | class(必須) | 使用するBusinessDateProviderの実装クラスを設定する。 | -* nablarch.core.date.BasicBusinessDateProviderの設定 - - | 属性値 | 設定値 | - |---|---| - | tableName(必須) | 業務日付テーブルのテーブル物理名を設定する。 | - | segmentColumnName(必須) | 業務日付テーブルの区分カラムの物理名を設定する。 | - | dateColumnName(必須) | 業務日付テーブルの日付カラムの物理名を設定する。 | - | defaultSegment(必須) | 区分を省略して業務日付取得を使用した際に、指定される区分を設定する。 | - | cacheEnabled | 業務日付テーブルのデータをキャッシュするか否かを設定する。 キャッシュ機能を利用した場合、複数回業務日付処理が呼ばれた場合であってもデータベースへのアクセスは1回ですむため、 性能向上が見込まれる。このため、キャッシュ機能を有効にすることを推奨する。 特にバッチ処理のように大量データを繰り返し処理するような場合、必然的に業務日付機能へのアクセス回数も多くなる。 このような場合に、キャッシュ機能を無効にしてしまうと業務日付を取得するたびにデータベースへのアクセスが発生し、 本機能が性能劣化の一因となるため注意すること。 キャッシュを有効にした場合、初めて日付取得メソッドが呼び出されたタイミングで 全ての業務日付のデータをスレッドコンテキスト( [同一スレッド内でのデータ共有(スレッドコンテキスト)](../../component/libraries/libraries-thread-context.md#同一スレッド内でのデータ共有スレッドコンテキスト) を参照)にキャッシュする。 キャッシュされた値は、ハンドラキューに設定された Threadcontexthandler によってクリアされる。 なお、本設定値を省略した場合のデフォルト動作はキャッシュありとなっている。 このため、キャッシュを行わない場合のみ、本設定値にfalseを設定すれば良い。 | - | dbTransactionName | データベースに対するトランザクション名を設定する。 本クラスは、業務アプリケーションと同一のデータベース接続を使用する。 このため、業務アプリケーションで使用するトランザクション名称を本プロパティに設定する必要がある。 ただし、業務アプリケーションが、デフォルトのトランザクション名を使用する場合は、 本プロパティへトランザクション名を設定する必要はない。 詳細は、以下のコードを参照 ```java // 以下のコードでコネクションが取得できる場合は、本プロパティへの設定は省略可能 AppDbConnection con = DbConnectionContext.getConnection(); // 以下のコードでコネクションを取得する必要がある場合は、 // 本プロパティには、getConnectionへ設定している引数("appTransactionName")を設定する。 AppDbConnection con = DbConnectionContext.getConnection("appTransactionName"); ``` | - | transactionManager(必須) | トランザクションマネージャを設定する。 業務日付をデータベースから取得する際に使用するトランザクションを設定する。 | - -#### 日付の上書き機能 - -本フレームワークでは、 [業務日付テーブル](../../component/libraries/libraries-06-SystemTimeProvider.md#業務日付テーブル) で管理されている日付を上書きする機能を提供する。 -この機能は、プロセス単位に使用する日付を変更できるものであり、主にバッチ処理での障害復旧時に使用することを想定する。 -例えば、現在の業務日付ではなく障害発生時の日付を業務日付として処理を実行したい場合に、データベース上の値ではなく任意の日付を業務日付として使用することが可能となる。 - -画面処理では、全ての機能が１プロセス内で実行されるため、本機能を使用するのではなく単純にデータベースで管理されている日付を変更すれば良い。 - -##### 業務日付の上書き方法 - -業務日付の上書きは、 [リポジトリ](../../component/libraries/libraries-02-Repository.md#リポジトリ) に任意の日付を登録することにより実現できる。 - -リポジトリには、Java起動時に「-D」オプションを使用して上書きしたい日付を登録することが出来る。 -「-D」オプションのキー、値には下記表を参照し設定を行うこと。 - -| キー | 値 | -|---|---| -| BasicBusinessDateProvider. + "区分" | 上書きしたい日付 | - -例：区分00の日付を20110710に上書きしたい場合 - -```bash -java -DBasicBusinessDateProvider.00=20110710 Main -``` - -以下に例を示す。 - -* データベースの値(業務日付テーブルの値) - - | 区分 | 日付 | - |---|---| - | 00 | 20110710 | - | 01 | 20110709 | -* リポジトリの内容 - - | キー | 値 | - |---|---| - | BasicBusinessDateProvider.01 | 20110708 | - -上記構成の場合取得される日付は、下記の通りとなる。 - -```java -// 20110710が取得される。 -// リポジトリに日付が登録されていないため、 -// データベースに登録された値が取得される。 -getDate("00"); - -// 20110708が取得される。 -// リポジトリに日付が登録されているため、 -// リポジトリに登録された日付が取得される。 -getDate("01"); -``` - -#### 業務日付のメンテナンス - -業務日付のメンテナンスはsetDateメソッドで行う。setDateメソッドの使用方法を以下に示す。 - -```java -// ******** 注意 ******** -// 本実装例は、各プロジェクトのアーキテクトが実装すべきクラスである。 -// このため、このようなクラスをアプリケーションプログラマが実装することはない。 -// BusinessDateUtilクラスがsetDateメソッドを提供していない理由も、 -// アプリケーションプログラマがsetDateメソッドを使用できないようにするためである。 - -// リポジトリから業務日付を操作するクラスを取得する -BusinessDateProvider bdp = (BasicBusinessDateProvider) SystemRepository.getObject("businessDateProvider"); - -// 更新対象の区分値、更新する値を入力し、更新実行 -bdp.setDate(segment, date); -``` - -#### BusinessDateUtilで提供される機能では不足している場合の対応方法 - -BusinessDateUtilで提供される機能に不足がある場合には、下記のサンプル実装のようにプロジェクト固有の業務日付取得クラスを追加し対応すること。 - -```java -// ******** 注意 ******** -// 本実装例は、各プロジェクトのアーキテクトが実装すべきクラスである。 -// このため、このようなクラスをアプリケーションプログラマが実装することはない。 - -public class SampleBusinessDateUtil { - /** - * 業務日付を取得する。 - * @return 業務日付 - */ - public static String getDate() { - // BusinessDateUtilで実装されている機能については、BusinessDateUtilに処理を移譲する。 - return BusinessDateUtil.getDate(); - } - - //********************************************************************************** - // getDateと同じように、BusinessDateUtilで提供されている機能の、メソッドを実装する。 - //********************************************************************************** - - // プロジェクト固有の実装を行う。 - - /** - * 業務日付の前日を取得する - * @return 前日 - */ - public static String getBeforeDate() { - // 業務日付の前日を取得する処理 - } -} -``` - -## 日付ユーティリティ - -日付に関する機能の中で、システム日時や業務日付に関係しないものを日付ユーティリティとして提供する。 - -詳細は、 [ユーティリティ](../../component/libraries/libraries-99-Utility.md#ユーティリティ) を参照すること。 diff --git a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-07-BasicRules.md b/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-07-BasicRules.md deleted file mode 100644 index 03b93a13d..000000000 --- a/.claude/skills/nabledge-1.2/docs/component/libraries/libraries-07-BasicRules.md +++ /dev/null @@ -1,220 +0,0 @@ -## 命名ルール - -フレームワークでは、CSSのクラス名やJavaScriptの関数名など、フレームワークが規定する名前については、 -個別アプリケーションと重複しないようにプレフィックス「nablarch_」を使用する。 -このため、個別アプリケーションでは、「nablarch_」から始まる名前を使用しないこと。 -この命名ルールの対象を下記に示す。 - -* HTMLの属性値 -* CSSのクラス名 -* JavaScriptの関数名とグローバル変数名 -* ページスコープ、リクエストスコープ、セッションスコープの属性名 - -## taglibディレクティブの指定方法 - -カスタムタグを使用するJSPでは、taglibディレクティブの指定が必須となる。 -本機能のカスタムタグを使用する場合のtaglibディレクティブの指定例を下記に示す。 - -```jsp -<%@ taglib prefix="n" uri="http://tis.co.jp/nablarch" %> -``` - -以降の実装例では、上記のtaglibディレクティブが指定されているものとする。 - -## URIの指定方法 - -カスタムタグにおいてURIを指定する属性は、下記のいずれかの方法で指定する。 - -| 指定方法 | 指定するパス | 説明 | -|---|---|---| -| 絶対URL | http又はhttpsから始まるパス | 他システム連携などでアプリケーションとホストが異なるURIを指定する場合に使用する。 カスタムタグは、指定されたパスをそのまま使用する。 | -| コンテキストからの相対パス | /(スラッシュ)から始まるパス | アプリケーション内のパスを指定する場合に使用する。 カスタムタグは、指定されたパスの先頭にコンテキストパスを付加して使用する。 | -| 現在のパスからの相対パス | /(スラッシュ)から始まらないパス (絶対URLを除く) | アプリケーション内のパスを指定する場合に使用する。 カスタムタグは、指定されたパスをそのまま使用する。 | - -コンテキストからの相対パスを指定している場合は、カスタムタグのsecure属性を指定することでURIのhttpsとhttpを切り替えることができる。 -secure属性が指定された場合は、カスタムタグの設定値(http用のポート番号、https用のポート番号、ホスト)とコンテキストパスを使用してURIを組み立てる。 -このためsecure属性を使用するアプリケーションでは、カスタムタグの設定を行う必要がある。 -カスタムタグの設定については、 [カスタムタグのデフォルト値の設定](../../component/libraries/libraries-07-HowToSettingCustomTag.md#カスタムタグのデフォルト値の設定) を参照。 - -| 属性 | 説明 | -|---|---| -| secure | URIをhttpsにするか否か。 httpsにする場合はtrue、しない場合はfalse。 | - -> **Note:** -> secure属性は、遷移先のプロトコルを切り替えるボタンやリンクのみで使用する。 -> 遷移先のプロトコルが同じ場合(httpからhttp、httpsからhttps)は、secure属性を指定せずに相対パスを指定する。 - -secure属性の使用例を下記に示す。下記のポート番号とホストが設定されているものとする。 - -* http用のポート番号: 8080 -* https用のポート番号: 443 -* ホスト: sample.co.jp - -httpからhttpsに切り替える場合 - -```jsp -<%-- secure属性にtrueを指定する。 --%> - -``` - -```bash -# 組み立てられるURI -https://sample.co.jp:443/<コンテキストパス>/LoginAction/LOGIN001 -``` - -httpsからhttpに切り替える場合 - -```jsp -<%-- secure属性にfalseを指定する。 --%> -ログアウト -``` - -```bash -# 組み立てられるURI -http://sample.co.jp:8080/<コンテキストパス>/LogoutAction/LOGOUT01 - -# 組み立てられるURI(カスタムタグの設定でhttp用のポート番号を指定しなかった場合) -# ポート番号が出力されない。 -http://sample.co.jp/<コンテキストパス>/LogoutAction/LOGOUT01 -``` - -なお、本機能では、URIを指定するHTMLタグについて、コンテキストパスの付加とURLリライトに対応する下記のカスタムタグを提供する。 - -* [aタグ](../../component/libraries/libraries-07-TagReference.md#aタグ) (リンク) -* [imgタグ](../../component/libraries/libraries-07-TagReference.md#imgタグ) (画像ファイル) -* [scriptタグ](../../component/libraries/libraries-07-TagReference.md#scriptタグ) (JavaScriptファイル) -* [linkタグ](../../component/libraries/libraries-07-TagReference.md#linkタグ) (CSSファイル) - -## HTMLエスケープと改行、半角スペース変換 - -### HTMLエスケープ - -本フレームワークが提供する全てのカスタムタグでは、原則として出力する際に全てのHTMLの属性についてHTMLエスケープを行う。 -HTMLエスケープ処理では、下記の文字変換を行う。 - -| 変換前 | 変換後 | -|---|---| -| & | & | -| < | < | -| > | > | -| " | " | -| ' | ' | - -> **Warning:** -> EL式はHTMLエスケープ処理を実施しないため、EL式を使用して値を出力しないこと。 -> 値を出力する場合は、writeタグなど本機能が提供するカスタムタグを使用する。 -> ただし、JSTLのforEachタグやカスタムタグの属性にオブジェクトを設定する場合など、直接出力しない箇所ではEL式を使用しても問題ない。 - -> **Warning:** -> JavaScriptに対するエスケープ処理は、まだ未実装のため、 scriptタグのボディやonclick属性など、JavaScriptを記述する部分には、動的な値(入力データなど)を埋め込まないこと。 -> JavaScriptを記述する部分に動的な値(入力データなど)を埋め込む場合は、プロジェクトの責任でエスケープ処理を実施すること。 - -### 改行、半角スペース変換 - -確認画面などに入力データを出力する際には、HTMLエスケープに加えて、改行と半角スペースの変換を行う。 -下記に変換内容を示す。 - -| 変換前 | 変換後 | -|---|---| -| 改行コード(\\n、\\r、\\r\\n) |
| -| 半角スペース |   | - -### HTMLエスケープせずに値を出力する方法 - -業務アクションなどで設定された値をページ上に出力する場合は、 Webview_WriteTag を使用するが、 -HTMLエスケープを行わず、変数内のHTMLタグを直接出力したい場合は、以下のタグを使用する。 - -* [prettyPrintタグ](../../component/libraries/libraries-07-TagReference.md#prettyprintタグ) - - 変数中の **** や **** のような装飾系のHTMLタグをエスケープせずに出力するカスタムタグ。 - 使用可能なHTMLタグ及び属性は、 [カスタムタグのデフォルト値の設定](../../component/libraries/libraries-07-HowToSettingCustomTag.md#カスタムタグのデフォルト値の設定) で任意に設定することができる。 - デフォルトで使用可能なタグ、属性は以下の通り。 - - **使用可能タグ** - - b big blockquote br caption center dd del dl dt em font h1 h2 h3 hr i ins li ol p small strong sub sup table td th tr u ul - - **使用可能属性** - - color size border colspan rowspan bgcolor - - > **Warning:** -> [prettyPrintタグ](../../component/libraries/libraries-07-TagReference.md#prettyprintタグ) で出力する変数の内容が、不特定のユーザによって任意に設定できるものであった場合、 - > 脆弱性の要因となる可能性があるため、使用可能なHTMLタグ及び属性を設定する場合は、その選択に十分に留意すること。 - > 例えば、 **