SAStruts+S2JDBCでアプリケーションを構築するに当たって前調べしたことを纏めてあります。基本的なことからアーキテクトまで広く利用できるようなリンク集＆コメントです。 SAStrutsについて 機能について http://sastruts.seasar.org/featureReference.html#SQLFileToDto 採用した理由 http://d.hatena.ne.jp/cypher256/20080419/p13 エンドユーザーの説得方法 http://d.hatena.ne.jp/cypher256/20080419/p14 Service,Actionのインスタンスについて どういう単位でインスタンスが作られているかを押さえておく。 org.seasar.framework.container.creatorを参照 種類 インスタンス定義 自動バインディング

2008-04-19 のエントリー。 自分でカスタマイズするなら ActionCustomizer を継承し、setupValidator メソッドに少しコードを追加するすることで対応可能です。プロパティを getClass() して、その定義クラスを getFileds() し、getAnnotations() した後、プロパティ名 + "." + ネストプロパティ名をバリデーション対象として登録みたいな感じだったと思います。 ネストしたプロパティで入力チェック - C/pHeR Memo - Java とか。Eclipse とか。 コード・イメージはこんなのです。 // アクション・カスタマイザ・クラス public class HogeActionCustomizer extends ActionCustomizer { // バリデータのセットアップ @Override prote

生StrutsのActionクラスではsaveMessagesメソッドを使えば、ビューへメッセージを渡せますが、SAStrutsではどうやって渡すのか調べてみたら、ActionMessagesUtilというユーティリティクラスが用意されていました。 Actionクラスでの使い方は以下のような感じ。 public class HogeAction { public HttpServletRequest request; // 中略 @Execute(input = "index.jsp") public String submit() { ActionMessages messages = new ActionMessages(); messages.add(ActionMessages.GLOBAL_MESSAGE, new ActionMessage("xxxxxx")); // xxx

昨日の日記の例外（NoRoleException含む）発生時の処理で、StrutsのExceptionHandlerを使ってそこそこうまく解決したので公開。 ExceptionForwardHandler.java public class ExceptionForwardHandler extends ExceptionHandler { @Override public ActionForward execute(Exception ex, ExceptionConfig ae, ActionMapping mapping, ActionForm formInstance, HttpServletRequest request, HttpServletResponse response) throws ServletException { super.execute(ex, ae, m

Struts(1.2.x以下)からSAStrutsへの置き換えをするときに、Actionの共通前処理をどこに実装するかで迷った。 ここで言う共通前処理とは、個々のActionを実行する前に共通で実行したいような処理のこと。 Strutsでは、org.apache.struts.actions.DispatchActionを継承したクラスを作成し、dispatchMethodをオーバーライドして、そこに実装していたが、SAStrutsはPOJO ActionなのでDispatchActionに該当するものがない。 まず、考えたのはAOPで実装する案。 個々のActionに共通のスーパークラスを作成し、共通前処理メソッドを実装した上で、Interceptorを作成し、共通前処理メソッドを呼び出すようにする。 せっかくPOJO Actionなのにスーパークラスの継承を強要させるのは微妙な気がしな

JavaのWebアプリでユーザ認証を行う場合、サーブレット仕様で決められた認証機能を使うか、独自の認証機構を実装するか、いずれかであると思う。 サーブレットの認証機能を使うとHttpServletRequestのisUserInRoleやgetRemoteUserが有効になるのが地味に嬉しい。Strutsフレームワークのロールによるアクセス制御も有効になるのでサーブレットの認証機能は結構使える。一方、独自の認証機構を使うと自由にログイン処理を記述できる代わりにHttpServletRequestのgetRemoteUserやisUserInRoleは使えない。 しかし独自の認証でもHttpServletRequestWrapperとFilterを組み合わせれば、getRemoteUserやisUserInRoleを有効にできる。 まず、認証時にユーザ名とロールを適当な名前でセッションに格納

SAStrutsで認証を実装したいのですが、お勧めはサーブレットの認証機能を使って認証する方法みたいです。 認証 - cypher256's blog 今回はアプリケーションサーバがTomcatで、ユーザ情報はDBで管理したいのでJDBCRealmを使ってやろうかなと思っていました。 ところが、ログインの認証機能が複雑な仕様になってしまって、JDBCRealmでは実現できないことがわかりました。 何とか、@Executeのroles属性でメソッド単位に認証をかけたいと思って、調べました。 調査 そもそも、どのようにrolse属性に設定したロールで認証がかかっているのか？ また、会社にあったStruts in アクションに書いてあるんじゃないかと思って、ActionMappingのrolse属性を見てみました。 以下、抜粋。 セキュリティチェックは、RequestProcessorのproc

認証の方法は悩みがちなポイントだと思います。コンテナ等の実装も含めると手段は色々あるし、一言に認証といっても、色々な業務ロジックが絡んでくることも多いからでしょうか。 今回はSAStrutsで、sessionとAOPを使ったスタンダードな方法を実装しました。 仕組みはいたってシンプルで、何らかのロジックで認証した後、ID等のデータをセッションに格納して、その有無でログイン済みかを確認するというものです。ログアウトはそのセッションを廃棄することになります。Webアプリケーションでは王道の方法だと思います。 この場合、認証のチェックが必要な場面で同じ処理が必要になるので、SAStrutsではセッションのチェックはメソッドを分けて、AOPでアクションに適応します。 今回は、全体的にログインしっぱなしでいて欲しいので、LoginAction以外では全てのアクションで確認します。 これにより、どのペ

Webアプリケーションでありがちな「ログイン済みか確認する」ための処理を、S2AOPを使って組み込んでみた。 やりたいことは、「Actionクラスの@Executeなメソッドが呼ばれたとき、ログイン済みかどうかを確認し、ログインしていなければログイン画面にリダイレクトする」である。この処理を全てのActionに書いて回るのは当然ながら面倒なので、AOPで処理を差し込んでしまいたいというわけ。 通常、ログインしているかどうかはHttpSessionが特定の属性値を持っているかで判断する。そこで、次のようなインターセプタを定義する。パッケージを{root}.interceptorとしておけば、勝手にコンポーネントとして定義されるので楽。 ※追記: セッションの使い方が間違っているようです。Seasar 2.4.34以前では、HotDeploy時にClassCastExceptionが投げられる

特定のユースケースへの要件が少ない場合は、 ユースケースに対応した１つのActionクラスで基本的な処理は実装できます。 しかし、ユースケースへの要件が多い場合は、扱うクラスが増えてしまいます。 例えば、ユースケース専用のDto(ActionForm)やユースケース専用のLogic、セッション格納用Dtoなどです。 特定のユースケースに関するクラスが複数存在する場合は、 パッケージが分散しているよりも、１つのパッケージに集めた方が開発しやすいと思います。 (Teedaはこのような構成でした。) そこで、ユースケース名が "hoge" の場合、以下のような構成が可能なように SAStrutsを拡張してみました。 Java側： ＜ルートパッケージ＞.web.hoge.HogeAction.java ＜ルートパッケージ＞.web.hoge.HogeDto.java (ActionForm) ＜ル