Teeda のファイルアップロードの件で、ポートレットでも使えるようにしておきました。利用するためには、Apache のポートレットフィルタが必要です。ポートレットフィルタは、org.seasar.teeda.extension.portlet.MultipartFormDataFilter になります。使いかたはサーブレットと同じでそのフィルタをかませるだけですけど、ポートレットはポータルによって Request が返してくるエンコーディングに曖昧なとこがあるので、encoding パラメータを追加してあります(これないと、様々なポータルに対応できない気が)。という感じで、次のバージョンではポートレットでも使えるようになっているかと思います。
カテゴリー: Seasar
Linux上でDBFluteを使って多くのテーブルを処理する
今まで、Linux 上で DBFlute で起きていた問題ですけど、原因がわかりました。ファイルを開き過ぎで、対象のリソースが開けなくなったみたいです。つまり、ファイルディスクリプタのリミットにはまった感じ。ユーザーごとの限界値を見てみると、デフォルトで、
$ ulimit -n 1024
という感じで、1024。というわけで、
$ su # ulimit -n 65536 # su taro $ ./generate.sh
とかやれば、成功する(ユーザーではulimitできんかった)。うーん、こんな所にはまるとは・・・。というか、これをログだけ見て気づくの無理なんじゃないか。だって、Velocity 1.3 の FileResourceLoader#findTemplate で FileNotFoundException を捨てるんだもん・・・(結局、Velocityを追いました)。というわけで、私みたいにテーブルをガツガツ作らないで Linux でやれば通るだろうし、他の OS ならリミットが違うから問題が起こらないわけなのね。0.5.7 では問題なかったということは、0.5.8 から開きっぱなしになるファイル数が増えているということかな・・・(DBFlute の差分は把握してないですが)。とりあえず、原因もわかってすっきりしました(id:jflute さん、お騒がせいたしました)。
H2 で DBFlute
昨日の続き。まず、いくつかのバージョンで確認した。どうやら、0.5.8 からおかしいみたい。0.5.7 では、普通に実行できた。っで、問題の箇所は、templates/om/Control.vm の
#if (!$database.isStopGenerateExtendedEntity())
#set ( $path = "${strings.getPackageAsPath(${glPackageExtendedEntity})}${myExtendedObjectClassName}.${glClassFileExtension}" )
#if (!$files.file(${generator.OutputPath},$path).exists())
$generator.parse("om/${glResourceDirectory}/exentity/ExtendedEntity.${glTemplateFileExtension}", $path, "table", $table)
#end
#end
みたい。generator.parse して、できない感じ。これがだめなので、exentity にクラスたちが生成されない。つまり、exentity が存在してれば、ここはパスされるみたいなので、まず、0.5.7 で一度生成した後に、0.6.1 でアップデートすれば、一応コンパイルはできるから回避できるみたい(生成されたコードが問題ないかは未確認)。そもそもの原因はもっと見ないとわからなそう・・・。