StrutsのClassLoader脆弱性はSAStrutsに影響しません - ひがやすを技術ブログ
Struts2に見つかった脆弱性と同様の脆弱性がStruts1系にも見つかりました。 Apache Struts 2の脆弱性が、サポート終了のApache Struts 1にも影響 HTTP(S)のリクエストでJavaのClassLoaderのメソッドが呼び出せてしまうという脆弱性です。 もう少し噛み砕いて言えば、リクエストのパラメータをJavaBeansにセットする時に、リフレクションを使い、パラメータ名にaaa.bbb.cccのようなネストした名前をサポートしているフレームワークは同様の問題が起こる可能性があります。 パラメータ名をclass.classLoader.xxxのような感じにして、ClassLoaderのメソッドを呼び出す訳です。 このような問題を起こすリフレクションフレームワークで最も有名なのは、Apache Commons BeanUtilsです。リクエストのパラメータ
DIを意識させたらキャズムは超えられない - ひがやすを技術ブログ
Java でも比較的先進的な考えを持つフレームワークがたくさんあります。そして、先進的なフレームワークは作者でさえ、流行っている、たくさん利用されていると錯覚する場合があります。利用者となるプロジェクトには大抵、新しいことが好きな先進的な人がいて、アーキテクチャを決めてしまいます。そういう人はよくネットなどで情報を発信します。また先進的であれば、記事や書籍でこぞって取り上げられ（もちろん中の人の努力もあります）、流行ってるように見えてしまいます。実際には出来れば新しいことには手をつけたくない人のほうが圧倒的に多いにも関わらず。 どこかの掲示板で、DIは疎結合のためにあるとか、そのためにインターフェースと実装を分離するんだとか、再コンパイルせずに、設定ファイルの変更のみで実装を変更できるんだとか、書いている人を見て、懐かしく思いました。 こんないいもの(たとえばDI)を理解できないのは、理解
S2AbstractServiceは便利なJdbcManagerじゃないよ - ひがやすを技術ブログ
シンプルな問い合わせは、メソッドにしない。 Serviceクラス使ってる意味なくね？ aaSerivce.selectById(aaId); というように、ID指定で取得するような問い合わせは、selectById()メソッドを作らず、 aaService.select().id(aaId).getSingleResult(); って書くんだと。なんでも、メンテナンスコストが下がるとかで。逆だろ、上がるだろこれ。 「シンプルな問い合わせは、メソッドにしない」というのは、S2JDBCのコミッタの間では推奨されていません。コメントによると個人事業主のつぶやきさんのプロジェクトの規約のようですね。 Serviceを利用する場合、使うほうは、select().id(aaId).getSingleResult()のように流れるようなインターフェースを使うのではなくて、ServiceにselectBy
JavaでRailsのflash機能を実現する - ひがやすを技術ブログ
Railsのflash機能とは、次のページまでは保持されている変数で、次の次のページでは、消えてしまいます。主に、リダイレクトでエラー画面に遷移して、メッセージを一度だけ表示したいような場合に使います。 Strutsで、このような機能を使いたい場合は、セッションスコープのActionMessagesを使います。 生Strutsを使う場合は、Action#saveMessages(HttpSession session,ActionMessages messages) SAStrutsを使う場合は、ActionMessagesUtil#saveMessages(HttpSession session, ActionMessages messages) を呼び出せばOKです。 意外にみんな知らないんだね。Twitterで困っている人がいたから書いてみた。
SAStrutsでクライアントサイドバリデーション - ひがやすを技術ブログ
SAStrutsでクライアントサイドバリデーションは次のようにして行ないます。 今回は、最初のサブミットボタンを押すと、aaaのみが必須チェックがかかり、次のボタンを押すとbbbのみが必須チェックがかかるサンプルで説明します。 ClientValidatorAction.javaのソースコードは次のようになります。 ClientValidatorAction.java package tutorial.action; import org.seasar.struts.annotation.Execute; import org.seasar.struts.annotation.Required; public class ClientValidatorAction { @Required(target = "submit") public String aaa; @Required(tar
SAStrutsでMapのプロパティにアクセスする方法。 - ひがやすを技術ブログ
ActionFormに次のようなプロパティがあったとします。 public Map<String, Object> map;このmapプロパティにStruts的には、次のような感じでアクセスします。 <html:text property="map(aaa)"/>SAStruts 1.0.4-sp5ではこのパターンに対応できていないので、Mapのプロパティにアクセスするときには、Strutsのタグは使えません。かわりに次のように普通のinputタグを使ってください。 <input type="text" name="map.aaa" value="${f:h(map.aaa)}"/>さっき修正したので、SAStruts 1.0.4-sp6(次のリリース)から、Strutsのタグでも使えるようになります。 https://www.seasar.org/issues/browse/SASTRU
複数種類のエンティティを扱うロジックをどこに書くのか - ひがやすを技術ブログ
「複数種類のエンティティを扱うロジックをどこに書くのか」、これは、非常に難しい問題です。エンティティに持たせると、どこのエンティティに持たせるのかを判断するのが難しい。 だから、アクションにもたせるのが良いと書いてきました。 でも、売上金額 = 売上明細.商品.単価 * 売上明細.数量みたいなロジックがあって、JSPに売上金額を表示する場合に、このロジックをアクションにもたせるかというと微妙ですね。 売上金額が1つしかないなら、それでもいいけど、複数あった場合は、うまくいかない。コメントで答えたように、これくらいの計算なら、ELでやっても全然いいんだけど、複雑な計算だとどうするのか。 売上明細エンティティが複数あって、複数の売上金額を表示するなら、売上エンティティで計算したほうが全然楽です。 <c:forEach var="e" items="salesDetailItems"> ${e.
SAStrutsで簡単Ajax - ひがやすを技術ブログ
SAStrutsで簡単にAjaxを扱えるようにしました。サンプルはこんな感じ。 package tutorial.action; import org.seasar.struts.annotation.Execute; import org.seasar.struts.util.ResponseUtil; public class AjaxAction { @Execute(validator = false) public String index() { return "index.jsp"; } @Execute(validator = false) public String hello() { ResponseUtil.write("こんにちわ"); return null; } } アクションで、ResponseUtil#write()を使ってレスポンスに文字列を書き出すだけ。
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
ビジネスロジック層とドメインモデル - ひがやすを技術ブログ
ビジネスロジック層は次のようなクラス(アプリケーションロジックもドメインロジックも1つのクラス)で構成されます。 サービス Dxo アプリケーションロジック メールを送るなどドメインに無関係なロジック ドメインモデルの再利用性を高めるためドメインモデルから分離する アプリケーションロジックをサービスのメソッドにしてしまうとアプリケーションロジックが分散する危険性がある (ドメインロジック) ドメインロジックを()で囲っているのは、ドメインロジックをドメインモデルに持たせた場合、ドメインロジックは、ビジネスロジック層に含まれないためです。 ドメインモデルにドメインロジックが含まれる場合をリッチドメインモデルと呼び、ドメインモデルにドメインロジックが含まれない場合をシンドメインモデルと呼ぶことにします。 ドメイン層ではなく、ビジネスロジック層という言葉を使ったのは、リッチドメインモデル場合、ド
2007-10-25 - ひがやすを blog
っていうか、Hibernateにも昔からcriteriaあるよね？ http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querycriteria List cats = sess.createCriteria(Cat.class) .add( Restrictions.like("name", "Fritz%") ) .add( Restrictions.between("weight", minWeight, maxWeight) ) .list(); 流れるようなインターフェースとメソッドチェーンは違うものだよヨシオリ。ぱっとみは似ているかもしれないけど。 流れるようなインターフェースでは、ソースコードを書いている人が、中断することなく流れるようにコーディングできなければいけない。 HibernateのCrit
2007-10-19 - ひがやすを blog
流暢なインターフェースという訳になってみたいなので、今後は、流れるようなインターフェースではなく、流暢なインターフェースという言い方に変えたいと思います。 流れるようなインターフェースにかわったようなので元に戻します。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FluentInterface http://d.hatena.ne.jp/higayasuo/20071018#1192681950 ぶくまのコメントで、 http://www.objectclub.jp/community/codingstandard/ このあたりのJava規約だとチェインさせるような書き方は避けるべき、となっているとあります(うちの会社のドキュメントじゃん)が、これはいろんな人が思うことだと思うので、私の意見を書いておきます。 まず、可読性が悪くなるという話は、昨日の
2007-10-18
Seasarカンファレンスで、Seasar2入門セッションを、いろんな方に喜んでいただけるようにSeasar2ロードマップと復活のStrutsのセッションに変えるよというアナウンスをしたのですが、Seasar2の入門セッションはやはり必要だということで、元に戻すことになりました。 期待していた方ごめんなさい。でも、入門セッションのほうも面白いネタをいろいろしゃべるつもりなので、是非お越しください。 今後はやるフレームワークは「流れるようなインターフェース」を持ったものになるんじゃないかなぁと思います。流れるようなインターフェースの説明は、ファウラーたんのFluentInterfaceを参照してください。 Seasar2の新O/R Mapper(以後S2JDBCと呼びます)もこの「流れるようなインターフェース」を実現しています。例えば、JdbcManagerを使った検索はこんな感じになります
きれいなソースコードを書くために読んでおくべき本10冊 - ひがやすを技術ブログ
なんか、プログラマとして必要な本をあげるのが流行っているようなので、自分も書いておこう。きれいなソースコードを書くために読んでおくべき本10冊。 最初はリファクタリング リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見る 以上。終了。10冊じゃないか(^^; きれいなソースコードを書きたければ、一にも二にもリファクタリング、それしかない。 後は、良いソースコードを読みながら自分でも、実際にプロダクトを作ってみること。OSSとして公開すると、自然と良いコードを書こうというモチベーショ
Seasar3開発中止 - ひがやすを技術ブログ
Seasar3の開発を担当する予定だった小林さんが、Seasar3開発のモチベーションが萎えちゃったようなので、開発を一旦中止します。 http://d.hatena.ne.jp/koichik/20100806#1281070800 お前がやればいいじゃないかと言われそうですが、今、丸山先生が、Spring/Rooをとても熱心に追っかけているんです。 http://maruyama.cloud-market.com/cloud-doc/Roo.pdf http://www.ustream.tv/recorded/8600913 丸山先生が熱心に追っかける技術は流行らないというジンクス(先生ごめんなさい)を私は真面目に信じているので、小林さんがヤル気をなくしたのもあり、Seasar3の開発は中止したいと思います。 ちなみに、去年PDCというマイクロソフトの大きなイベントに行って、Azure
Seasar3がやってくる - ひがやすを技術ブログ
Seasar2は、機能を枯れさせることに徹し、機能追加は行わないと宣言してから、二年以上たちます。 で、Seasar2が冒険しないことによって、適切な大きさの問題は生まれなくなり、開発者が離れ、Seasar関連プロダクトが生まれなくなり、Seasarユーザも離れていく。使われないSeasarからさらに開発者が離れていく。 こういうスパイラルが発生するかもしれないことについては、どう考えますか？ このような声もありました。「機能を枯れさせることに徹する」というのは、かなりの冒険でしたが、今のところ、うまく行っていると思っています。 「RubyやSeasar2、OpenPNEが“定番”に、Linux Foundationが活用動向調査」という記事も出てましたね。 http://itpro.nikkeibp.co.jp/article/NEWS/20100527/348514/ しかし、二年の間
Slim3 1.0.0 Released - ひがやすを技術ブログ
Slim3 1.0.0をリリースしました。 リリースノートはこちら http://sites.google.com/site/slim3appengine/release-notes ダウンロードはこちら http://code.google.com/p/slim3/downloads/list Slim3の主な特徴は次のとおりです。 Global Transactions Faster than JDO/JPA Fast spin-up HOT reloading Type safe query 詳しくはこちらをどうぞ http://slim3.org Seasar2譲りのHOT reloadingやS2JDBC譲りのType safe queryなどもありますが、最大の特徴は、Global Transactionsを実装していること。 http://d.hatena.ne.jp/hig
App Engineではどの言語を使えばいいのか - ひがやすを技術ブログ
App Engineで使える言語は基本的にはPythonとJavaです。それでは、どちらを選ぶのが良いのでしょうか。 それ以外の言語の人向けの話は後から出てくるのでしばらくこのままお読みください。 趣味ならば単に好きなものを選ぶだけでいいのですが、仕事で使うためには、長所と短所をきちんと把握した上で選ぶ必要があります。また、ここでの話は言語としての一般的な話ではなくApp Engineで使うとき限定の話としてお読みください。 まず安定度ですが、インフラ部分の安定度は、どちらも基本的に同じです。もしかすると、まったく同じものを使っているのかもしれません。 その上で動くAPIの部分は、インフラと直接結びついている低レベルな部分と低レベルなAPIの上に構築された高レベルな部分とに分けて考える必要があります。 低レベルなAPIはLLAPIと呼ばれたりしますが、安定度は、PythonとJavaも同じ
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
