2024年夏 かばんの中身記録 みんな大好きかばんの中身。 当然私も大好きで、人様のブログ記事やSNS投稿を飽きもせず読み込みまくっています。なぜこんなにも見飽きないのか… 自分も以前同じようにかばんの中身の記事を書いたんですが、気づけばもう3年前!去年くらいの気分だった、月日がたつの…
2024年夏 かばんの中身記録 みんな大好きかばんの中身。 当然私も大好きで、人様のブログ記事やSNS投稿を飽きもせず読み込みまくっています。なぜこんなにも見飽きないのか… 自分も以前同じようにかばんの中身の記事を書いたんですが、気づけばもう3年前!去年くらいの気分だった、月日がたつの…
Struts(1.2.x以下)からSAStrutsへの置き換えをするときに、Actionの共通前処理をどこに実装するかで迷った。 ここで言う共通前処理とは、個々のActionを実行する前に共通で実行したいような処理のこと。 Strutsでは、org.apache.struts.actions.DispatchActionを継承したクラスを作成し、dispatchMethodをオーバーライドして、そこに実装していたが、SAStrutsはPOJO ActionなのでDispatchActionに該当するものがない。 まず、考えたのはAOPで実装する案。 個々のActionに共通のスーパークラスを作成し、共通前処理メソッドを実装した上で、Interceptorを作成し、共通前処理メソッドを呼び出すようにする。 せっかくPOJO Actionなのにスーパークラスの継承を強要させるのは微妙な気がしな
Webアプリケーションでありがちな「ログイン済みか確認する」ための処理を、S2AOPを使って組み込んでみた。 やりたいことは、「Actionクラスの@Executeなメソッドが呼ばれたとき、ログイン済みかどうかを確認し、ログインしていなければログイン画面にリダイレクトする」である。この処理を全てのActionに書いて回るのは当然ながら面倒なので、AOPで処理を差し込んでしまいたいというわけ。 通常、ログインしているかどうかはHttpSessionが特定の属性値を持っているかで判断する。そこで、次のようなインターセプタを定義する。パッケージを{root}.interceptorとしておけば、勝手にコンポーネントとして定義されるので楽。 ※追記: セッションの使い方が間違っているようです。Seasar 2.4.34以前では、HotDeploy時にClassCastExceptionが投げられる
DI(依存性の注入)×AOP(アスペクト指向)の常識:企業システムの常識をJBossで身につける(3)(1/4 ページ) 企業向けアプリケーションのさまざまな“常識”をJavaのオープンソース・フレームワーク群である「JBoss」から学んでいきましょう。企業システムを構築するうえでの基礎となる知識をリファレンス感覚で説明していきます。初心者から中堅、ベテランまで大歓迎! 前回の「“全部入り”のEclipseで学ぶ統合開発環境の常識」では、企業向けアプリケーションを構築する際に必要な要素として「統合開発環境」について説明し、実際にサンプルアプリケーションを作成し、企業向けアプリケーションの構築における、統合開発環境の機能やその重要性を学びました。 今回は、DIやAOPを通して、それらに関連するフレームワークやJBossのソフトウェアについて説明していきたいと思います。 企業向けアプリケーショ
このエントリーではSeasar 2.4.26 から 導入された S2AbstractService について書かせて頂きます。S2AbstractService を活用することで、タイプセーフを保ちつつも、データアクセスロジック関連のソースコードを大幅に減らす効果が期待できます。 S2JDBC の弱点 S2JDBCを使えば、お手軽かつパワフルにデータアクセス処理が実現できます。しかし、生のS2JDBCを野放し状態に使った場合、プロジェクトの規模が少し大きくなると、ソースコードの重複を生みやすくなる問題に直面します。具体的に、次の1件分のデータ取得処理ですら、コピー&ペーストされて複数箇所で使用されてしまいます。 Emp emp = jdbcManager.from(Emp.class).id(empId).getSingleResult(); 対処方法は、共通処理を抽出してメソッド化するこ
S2JDBCでServiceクラスをどのように作るか考えた時に参考にしたエントリー群です。肝は、3点。 Serviceクラスは、Entityクラスと1:1で対応させる。 Serviceクラスは、Entityに対する処理以外はやらない。 Serviceクラス以外は、jdbcManagerを生で使用しない。(Actionにとか) AbstractServiceを作成し、DBに関する共通処理を集約させる(削除フラグとか更新日とか) あ、4つになったw 公式ドキュメント二つ まず読みましょう S2JDBCとは サービスの作り方 JavaDoc こっちも必須です。 javadoc: S2AbstractServiceクラス 出羽さんのエントリー。納得できるまで、読み返すこと S2JDBC の弱点を補完するS2AbstractService 続・SAStruts + S2JDBCのアーキテクチャ ジェ
以下について誤解のないように書いておきます。 シンプルな問い合わせは、メソッドにしない。 Serviceクラス使ってる意味なくね? aaSerivce.selectById(aaId); というように、ID指定で取得するような問い合わせは、 selectById()メソッドを作らず、 aaService.select().id(aaId).getSingleResult(); って書くんだと。なんでも、メンテナンスコストが下がるとかで。 逆だろ、上がるだろこれ。 これすごくわかります。私も結構悩みました。本来は個人事業主さんのいう姿がよいと思います。 が、ここから本題。 私も最初のころはselectByIdをAbstractServiceにつくっていました。selectByIdって便利ですね、でもFKで関連しているテーブルもJOINしたいのですができないみたいなんですが、、、何かよいメソッ
生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
■ [Seasar]SeasarのHOT deployは難しい SeasarのHOT deployは開発時は非常に強力な機能ですが、取り扱いには注意が必要な機能でもあります。とりわけ問題になるのがHOT deployとCOOL deployの挙動の違いです。まず良くハマるのが、HOT deploy時のクラスローダの問題です。HOT deploy時はリクエスト毎にクラスがロードされるため、セッションやアプリケーションスコープに格納するオブジェクトについては普通に入れるだけだと取り出すときにClassCastExceptionが発生したりします。回避策としては以下のような方法があります。 コンテキストクラスローダで先にロードしておき、HOT deploy対象外にする マップなどに変換して格納しておくか、取り出すときにBeansなどでリフレクションを使ってコピーする フレームワークの拡張を行う場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く