[Java] 10 July 2006 はてなブックマーク - [Groovy&Velocity]最初の成果物0.0.1 Twitterでつぶやく

[Groovy&Velocity]最初の成果物0.0.1

とりあえず最初の成果物0.0.1を公開したく思います。
突貫なので簡単な作りでアレなんですが、興味ある人は、是非いじってみてください。
http://www.makino-style.org/ura/index.php?hymall%2F0.0.1

うまくいかない場合、コメントに質問書いてください。可能な限り返答します。
あと、もし面白いと感じてくれる人がいたら手伝ってください。まじめに作りますw

[Java] 09 July 2006 はてなブックマーク - GroovyがVelocityを引っ張るのです。その3 Twitterでつぶやく

GroovyがVelocityを引っ張るのです。その3

S2を取り込んで見ました。
現状でBindingの生成にS2を利用してます。
良くある区分値テーブルとかの情報一覧を表示する場合のコード例
Sample.gdo
  import groovy.sql.Sql
  list = new ArrayList()
  sql = new Sql(dataSource)
  sql.eachRow("select * from sys_param") { row |
    kbnData = new KbnData()
    kbnData.name_j=row.name_j
    kbnData.kbn=row.kbn
    kbnData.kbn_id=row.kbn_id
    list.add(kbnData)
  }
  if(list.size()>0){
    request.setAttribute("list",list)
  }
  class KbnData{
    @Property name_j,kbn_id,kbn
  }
Sample.htm
  <html>
  <body>
  #if($!list)
    <table>
      <tr>
        <td>kbn_id</td>
        <td>kbn</td>
        <td>name_j</td>
      </tr>
  #foreach($data in $list)
      <tr>
        <td>$data.kbn_id</td>
        <td>$data.kbn</td>
        <td>$data.name_j</td>
      </tr>
  #end
    </table>
  #else
    <h1>結果は0件</h1>
  #end
  </body>
  </html>

#S2の手軽さに感動しました。

[Java] 09 July 2006 はてなブックマーク - Dispatchしたときの・・・・(原因解明編) Twitterでつぶやく

Dispatchしたときの・・・・(原因解明編)

きっとGroovy本家の人やコアな人は既に把握していて既出かもしれないのだが・・・・

ある程度原因が判明、状況から判断すると、結局スクリプト実行時にダイナミックにCategoryサポートを付加する際に、クラスの型ごとに行なっており、なおかつ実行時MetaClassImplにて関連するMetaMethodをすべて取得しているという動作に由来するようだ。

なぜこのような現象が発生するかというと、結局Servletコンテナの実装のため、もしくはGroovyの実装のためとしか言いようがない。

現象に照らし合わせて、状況を整理してみる。
1,スクリプトAでrequestのsetを実行しスクリプトBへDispatchする。
2,スクリプトBでrequestのsetを実行する。
そうするとGroovyRuntimeExceptionでAmbiguous method overloading for methodと例外が発生。

この時、最初のスクリプトAでバインドされたrequestはorg.apache.catalina.connector.RequestFacadeのインスタンスであり、GroovyCategorySupportのThreadLocalのstackにもRequestFacadeクラスのClassインスタンスをkeyとしてsetのCategoryMethodがキャッシュされる。
(詳しく言えばRequestFacadeがcategorizedClassとされ、さらにCategoryMethodにてHttpServletReqeustを対象としてキャッシュされる。)

ところが、スクリプトBでバインドされたrequestはコンテナによりDispatchされたrequestなのでorg.apache.catalina.core.ApplicationHttpRequest(HttpServletRequestWrapperのサブクラス)となっている。
そのためstackには新たにApplicationHttpRequestをkeyとしてsetのCategoryMethodがキャッシュされる。
(同じくApplicationHttpRequestがcategorizedClassとされ、さらにCategoryMethodにてHttpServletReqeustを対象としてキャッシュされる。)

このためスクリプトBの実行時にはCategoryメソッドの検索で、見事に2つのsetメソッドが存在することになり、結果的にAmbiguous method overloading for methodとなるらしい。

ということで、結局Servlet関連のrequest,session,contextに関連するCategoryサポートは利用できる局面と利用できない局面が混在することになるので、紛らわしいから利用しない方向で実装することに決定。
まあsetAttributeを書くのがそれほど苦痛とも思われないので、問題ないかと・・・

参考:
GroovyCategorySupportのコードを追ってみた。
裏マキノ式:GroovyCategorySupportの分析

[Java] 05 July 2006 はてなブックマーク - DispatchしたときのGroovyCategorySupportの振る舞い Twitterでつぶやく

DispatchしたときのGroovyCategorySupportの振る舞い

GroovyのスクリプトでServletCategoryを利用して、RequestDispatcherを利用するとrequestとかのsetでこける。

具体的には
1,スクリプトAでrequestのsetを実行しスクリプトBへDispatchする。
2,スクリプトBでrequestのsetを実行する。
そうするとGroovyRuntimeExceptionでAmbiguous method overloading for methodと怒られてしまうのだが、これはおかしいよなー
場所的にはMetaClassImplクラスのchooseMostSpecificParamsにおいてmatchesが1ないしは0以外の時に発生する。つまり簡単に言えば、ServletCategoryで追加しているsetメソッドが重複しているよーって言っているのである。

Groovyのソースコードを追っていると、GroovyCategorySupportにおいてCategoryのキャッシュを保持するためにThreadLocalを利用しているが、ここが超臭う。
private static ThreadLocal local = new ThreadLocal() {
 protected Object initialValue() {
  List stack = new ArrayList();
  stack.add(Collections.EMPTY_MAP);
  return stack;
 }
};
RequestDispatcherを利用しない場合は問題ないのになー。
↑これはTomcatがThreadの使い回しの際にinitialValueで初期化しているからと思われ・・・

オリジナルのGroovletでも同じ現象が発生してる・・・・・orz
そんなに影響はないけどCategory使えないのは利便性の観点から痛いなー

[Java] 03 July 2006 はてなブックマーク - GroovyがVelocityを引っ張るのです。その2 Twitterでつぶやく

GroovyがVelocityを引っ張るのです。その2

昨日スタバのテラスで汗を流しながら考えたメモ
1.HTMLのモックアップからアプリケーションを作り上げる。
→ これは業務ではなくサイト構築という観点では非常に重要、理想論ではなく現場の現実論としての実装

2.共通のプレロジックの実行をサポート
→ 呼び出されたServletPathから判断して上位ディレクトリから順に規定された名称のGroovyスクリプトをチェーンして実行

3.DIコンテナによるカスタムBindingの生成
→ 既存Java資産の活用やトランザクションの実現が可能

4.Exceptionのハンドリング
→ 細かくは考えていないけど、規定の場所に配置して、ハンドリング後に呼び出し

5.その他
 VelocityのTemplateの実装、VelocityToolsのGroovyによる記述

番外
→ フレームワークの名前はスタバの隣のスーパーの名前(Hymall)にしようかとw

1は非常に重要で、コンシューマ向けのサイトを作り上げるときに見逃してはならない点である。具体的な実装方法としては、GroovyServletの親クラスであるAbstractHttpServletを継承して独自のコントローラを用意している。先頃GroovyのJSR06が出たのでそちらのソースコードを閲覧する必要もあるが、とりあえずJSR05で実装してみた。
大まかな流れとしては下記のようになっている。
①*.htmをハンドリング
②GroovyScriptが存在するなら、ServletPathから対応するGroovyScriptのパスを生成して実行
③Velocity用のHTMが存在するなら、マッピングされていないVelocityViewServletをgetNamedDispatcherにより取得してforward実行
④Groovy、Velocityとも対象ファイルが存在しない場合は404

開発スタイルのイメージとしては、デザイナーなどが作り上げたモックアップを配置して、Groovyのロジックを書き足していくイメージである。
仮にGroovyのロジックが存在しない場合でも、VelocityがHTMを配信するのでモックアップのまま利用すれば画面の流れが寸断されず良い。(*.htmでハンドリングしているため)
例えば下記の場合
/Sample.htm?name=F.Makino&address=Shanghai
既にSample.htmが存在して居るため対応するGroovyScriptであるSample.gdoが存在しなくても表示されるということ

#デプロイなしでシームレスに開発ができるのがこんなに幸せだとは思わなかったヨ...(TーT)

#あと意外にGroovyServletのソースは汚いよw

[Java] 02 July 2006 はてなブックマーク - GroovyがVelocityを引っ張るのです。 Twitterでつぶやく

GroovyがVelocityを引っ張るのです。

ある日、会社の中国人エンジニアがJavaはめんどくさいと言いました。
(結構根に持つタイプ→俺)
悔しいので、高速開発可能な簡易フレームワークというか環境を作ろうと心に決めました。
#目標メモ
http://www.makino-style.org/ura/index.php?AntiPhpProject


やっべー、マジで楽しいよ!グリグリいけるよ。
(今作り中、基本ができたらここでリリース予定w)
GroovyとVelocityServletは相性が良いと思う。サクサク行ける。
デプロイとリロードいらずでラピッドな開発ができるぜ!

Sample.gdo(Groovy側)
name = request.getParameter("name")
address = request.getParameter("address")
if(name!=null&&address!=null){
 info = new PersonalInfo()
 info.name = name
 info.address = address
 request.set("info",info)
}
class PersonalInfo{
 @Property name,address
}

Sample.htm(Velocity側)
<html>
 <body>
  <h1>Sample</h1>
  <h2>
   #if($!info)
    Your name is $info.name!<br>
    Your Address is $info.address
   #end
  </h2>
 </body>
</html>

Groovyへのバインド周りでDIをうまく使えば、面白いかもー
→ URLからkeyを生成して、DIでBindingオブジェクトを生成みたいな?さすれば、通常の方法で作ったDAOとかも容易に利用できるし

------------------
追記:
Spring使おうかS2使おうか迷ってたけど、ThinkITの速度比較見たらS2のほうがかなり速いのと使いやすいことからS2を使うことにする。正直Springの設定はめんどい


[Java] 30 June 2006 はてなブックマーク - AutoProxyするとApplicationContextAwareできないゾ Twitterでつぶやく

AutoProxyするとApplicationContextAwareできないゾ

何でだろう???
SpringでApplicationContextAwareをimplementsしたクラスをBeanNameAutoProxyCreatorでAOPしてるとTypeMismatchExceptionが出て、インスタンスが生成できない。別途インタフェースを持たないロジッククラスだからCGLIBでProxy作るときにApplicationContextAware拾っちゃうのかな????

org.springframework.beans.TypeMismatchException:
Failed to convert property value of type [$Proxy0] to required type
-------省略

しょうがないから呼び出し元をApplicationContextAwareにして手動でセット。orz

#トラックバック先のURLでも書いてあるけどSpringClickServletで、わざわざ自分で設定している(超不思議)のと関係あるのかな?
↑いやいや関係ないから・・・・→俺
http://d.hatena.ne.jp/kvasir/20051208/1133997009

[Java] 15 April 2006 はてなブックマーク - surefire-reportで日本語レポートでた~♪ Twitterでつぶやく

surefire-reportで日本語レポートでた~♪

2.0.1の時とか確かできなかったのであきらめてたんだけど・・・。
jreport
いつの間にかできてる、そういえば最近surefireではかれるのテキストレポートの文字化けが直っていたような気が・・・・・、あれ?いつからだっけか・・・・

とりあえず組み合わせは
Maven 2.0.4
surefire-report-maven-plugin 2.0-beta-1
→2.0-beta-2-SNAPSHOTがあるけど別にこれ使わなくでも問題ないみたいです。

あとmaven-site-pluginのコンフィギュレーションでoutputEncodingにUTF-8を指定すれば良いです。(どーでもよいけど、コンフィギュレーションのところにDiscoveredとか書いてあるのはなぜでしょうかw)
http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html

下記がレポーティングの設定例です。
 <reporting>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-site-plugin</artifactId>
    <configuration>
     <outputEncoding>UTF-8</outputEncoding>
    </configuration>
   </plugin>
   <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>surefire-report-maven-plugin</artifactId>
    <version>2.0-beta-1</version>
   </plugin>
  </plugins>
 </reporting>

サイトビルド自体の日本語化は下記にドキュメントあります。
http://maven.apache.org/plugins/maven-site-plugin/i18n.html
なにやら、自分でソース落として、↑のサイトのリソースを配置してmvn installすればよいよーとあります。
→ 中国語のリソースファイルが欲しいなw誰かに作ってもらおうかしらん

あと、mvn siteでもTestがこけると中断する問題に関しては、私の場合は下記のようにprofilesで回避してます。
surefireプラグインの設定
 <plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
   <testFailureIgnore>${test.testFailureIgnore}</testFailureIgnore>
  </configuration>
 </plugin>

プロファイルの設定
 <profiles>
  <!-- For Site Build Profile -->
  <profile>
   <id>site</id>
   <properties>
    <test.testFailureIgnore>true</test.testFailureIgnore>
   </properties>
  </profile>
 </profiles>
で、
 mvn site -Psite
みたいな感じです。

#同じくmavenのcargoが0.1から0.2にあがってる。でもなぜか0.1の設定だと失敗、SNAPSHOTで利用して他のが仇に・・・・、ある日突然デプロイ失敗wこちらも、早々に調べたいです。

[Java] 10 April 2006 はてなブックマーク - ぼかぁね、枕を濡らすほど悔しいわけですヨ Twitterでつぶやく

ぼかぁね、枕を濡らすほど悔しいわけですヨ

最近中国のコンシューマ系の案件に携わって、感じたのです。
『マジで完全なコンシューマ系サイトにはJavaは向いてないかも・・・orz』

何を今更と思われる御人も多いかと思います。なにせ昨今の世の中Rails旋風が吹きまくって、PHPによるラピッドなサイトビルドが花盛りです。
Javaなんて黙ってWASでXAトランザクションとか言ってればいんじゃない?・・・ねえ?(いやぁーー、そんなこと言わないで!泣いちゃう、泣いちゃうから!!)

確かに、
コンシューマ系のサイトにおいて今さら超重量級フレームワークStutsやJSPはあり得ないと思います。それに極端な話、客にとってはJSPが2.0だろうが、DIコンテナやO/Rマッピングを用いてようが興味ないわけです。
そこで、Javaがコンシューマ系サイト構築に向いていない(と感じる)理由を考えてみました。
 1、少なくともServletコンテナが必要(つまりTomcatとかJettyのこと)
 2、WARのデプロイが必要
 3、1画面作るまでのステップが多い
 4、静的言語のため冗長なコードが多い
 5、開発者がシステム開発的手法を持ち込みすぎ
ほかにもいろいろありますが、代表的なのはこんなもんだと思います。最初のServletコンテナが必要というのは基本的にはどう転んでもどうにもなりません。許してください・・・・
2、3、4、5はつまり書いたらすぐに結果が見れないことによるロスが大きいということです。

つまり、
簡単に言うと
 その場で修正してその場で確認させてよ。
 デプロイとかさせんなよ。
 とにかくごちゃごちゃ言うなよ。
・・・・というところでしょうか?ある意味むちゃです。
JAVAによるWEB開発というのは非常に手順が多く動かすまでに手間と時間がかかります。そして、一方でJava開発者も面倒に感じながらも、その手法を好んでいる傾向があります。少なくとも私は好きです。

でもね、
この思想はスピードが要求されるラピッドな構築では残念ながら通用しないわけです。いくら気取っていても、一昔前ならJavaでも良かった案件がPHPに取って代わられつつあります。PHPの開発者がなんと言おうとPHPはバルクでラピッドな開発に多用されており、そこへJavaが入り込めません。

さらに、
上海に来てから、こちらのエンジニアが行う欲望に忠実な場当たり的開発を見せつけられて、自分の開発手法が硬直化していたことを強く感じました。彼らの手法が良いか悪いかは別として、軍服に体のサイズを合わせさせるわけにはいかないわけです。

rails
そこで、
そんな現状に対する解答として、遅ればせながらRuby on Railsのドグマがぴったりだと思いました。特に二つめには衝撃を受けました。(遅すぎw
 ・Less software(より小さいソフトウェア)
 ・Convention over configuration(慣習は設定を超える)




そんなわけで、
しばらくの間、まじめにRuby on Railsから始めて、Groovyを中心としたソリューションを学んでみることにしました。
GroovletsGroovyTemplates、もしくはVelocityを組み合わせればラピッドな開発が可能なはずです。

またGroovyは静的なJavaクラス群も利用可能であるわけで通常のシステム開発にも応用できそうです。(いわゆるグルーコードによりクラスを関連づけるということ)

[Java] 21 March 2006 はてなブックマーク - Apache2+Tomcat5.5による実用環境 Twitterでつぶやく

Apache2+Tomcat5.5による実用環境

ってことで、実際に仕事で用いた環境とは若干違うんですが検証してみました。
コンシューマ向けから業務環境まで利用できるかと思いますので、こいつをベースに色々とオプション設定していけばよろしいのではないでしょうか?
まだ、参考サイトや注意事項など付記していくことがあるので、あと1週間ほどで完全に書き終わる予定です。とりあえず、一通りの環境構築の参考にはなります。


Tomcat5.5実運用環境指南

↑えらそう・・・TomcatもApacheも私が作ったわけじゃないのにね。orz

また、補足ですが、セッションのレプリケーションを施す場合にはターゲットのアプリケーションにおいて一般規約を守っていることが原則となります。
例えば
・SessionへのセットはsetAttributeを使う
・Sessionにセットするオブジェクトは必ずSeriarizableをimplementsする
・当然ながらSessionには巨大なオブジェクトをセットしない
などです。

あと、Tomcat5.0系より5.5系の方がAJPのコネクタの復旧が速い感じです。
(厳密な検証を経ていないので、飽くまでも私の体感ですが・・・)
«Prev || 1 | 2 | 3 | 4 || Next»