2012年12月27日木曜日

sbt で設定ファイルを本番用に切り替え

Scala の勉強をかなりさぼっていたわけで・・・
構文も大分忘れている状態なんですが、またちょっとはじめることに。
というか実践。

sbt を使ってちょっとしたバッチを開発時に jar に含める設定ファイル(ログレベル設定等)を、開発、ステージング、本番用に切り替えたくなった。そして嵌った・・・約 2 日・・・

とりあえず設定ファイルの構成は、Java の時にやっていた構成で、
+ src
  + main (開発)
    + scala
    + resources
      + logback.xml
      + ...
  + product (本番)
    + resources
      + logback.xml
  + staging (ステージング)
    + resources
      + logback.xml
の構成で、product/resources, staging/resources には上書きするもののみを置くこととする。

始める sbt のスコープ軸を見ると、タスク毎に設定が出来そう。ということで、最初のアプローチは、pack-staging, pack-product のタスクを生成して、タスクのスコープで unmanagedResourceDirectory を追加しようとした。が、そこから呼び出す copy-resources は copy-resources in Compile になってしまい挫折・・・これに 1 日以上費やしたわけだが・・・結局わからなかった・・・

で、maven の profile 的なことができないかと検索してみると参考になるサイトがあった。
ここを参考に、
case class Profile(name: String)

object Profile {
 val staging = Profile("staging")
 val product = Profile("product")

 implicit def toOption(profile: Profile): Option[Profile] = Option(profile)
}
として、
  unmanagedResourceDirectories in Compile <<= (sourceDirectory, selectedProfile, unmanagedResourceDirectories in Compile)
    ((dir, env, res) => env.map((dir / _.name / "resources")).toSeq ++ res),
  unmanagedResources in Compile~= (_.groupBy((_: java.io.File).getName).map(_._2.head).toSeq),
リソースディレクトリの設定時に振り分け。さらに、リソースファイル設定時に一意になるようグループ化しているようなしていないような・・・いまいち何をやっているかわからないが完成・・・ 

記号がさっぱりわからん・・・Perl とまでは言わんが・・・演算子でなくメソッドなので色々できるわけだが、C++ みたいに標準的な演算子のみオーバーライドできればいいのに・・・ ライブラリ毎に覚えるのは大変だ・・・ 標準的な意味合いの記号があるのだろうか。

 とりあえず sbt の API ドキュメントより、Setting[T] の <<= メソッドを見てみると trait DefinableSetting[S] に定義があり、
final def <<=(app: Initialize[T]): Setting[T]
なるほど、Initialize[T] を受け取る。 unmanagedResourceDirectories は SettingKey[Seq[File]] なので、右辺の
(sourceDirectory, selectedProfile, unmanagedResourceDirectories in Compile)
    ((dir, env, res) => env.map((dir / _.name / "resources")).toSeq ++ res)
は、Initialize[Seq[File]] を返すのであろう。

で、右辺部分だが、
(sourceDirectory, selectedProfile, unmanagedResourceDirectories in Compile)(なんかの処理)
つまり、
(タプル).apply(なんかの処理)
のように見えるが、タプルに対してそんなことできるのか・・・おそらくは暗黙の型変換・・・
というわけで、ソースコードを implisit で grep すると、Structure.scala で
implicit def t3ToApp3[A,B,C](t3: (Initialize[A], Initialize[B], Initialize[C]) ): Apply3[A,B,C] = new Apply3(t3)
というのを発見。さらに、Apply3 をみると、
def apply[T](z: (A,B,C) => T) = Project.app( k3(t3) )( hf3(z) )
となっている。さらに、object Project の API ドキュメントに、Init[Scope] に app の定義があり
def app[HL <: HList, T](inputs: KList[Initialize, HL])(f: (HL) ⇒ T): Initialize[T]
なので、Initialize[Seq[File]] が返りそう。なんか予想が多いが・・・

次に、なんかの処理部分は、Apply3 の apply の引き数なので、
(A,B,C) => T
最初のタプルの設定の値がそれぞれ渡り、T つまり、Seq[File] を返す関数を渡せばよさそう。
unmanagedResourceDirectories が SettingKey[Seq[File]] なので、res は Seq[File] とおもわれる。
そして、生成したパスと res を連結したものが返ると。

最終的に返った、Initialize[Seq[File]] で unmanagedResourceDirectories in Compile を設定しているようだ。
とりあえず、今回はここまで。
追うのだけでも大変・・・自分でカスタマイズ出来る気がしない・・・Scala は嫌いじゃないけど慣れないと、読むのも困難だな・・・

2012年10月19日金曜日

Java による画像縮小 lanczos 編

JDK を使った縮小の結果納得行かなかったので、GIMP なんかにもある lanczos による縮小を実装してみることに。
元画像は Jpeg なので、RGB の 3 色のみを扱う。

こちらの Ruby バージョンをとりあえず Java にポーティング。
今回縮小のみなので、拡大部分を削除。実行してみると 6 秒前後かかった・・・

もう少し早くならないかなと、さらにコメントのリンク先を読んでみる。

何をやっているかというと、中心を 1 として距離によって重みを付けるということのようだ。
| 0.3 | 0.5 | 0.3 |
|-----+-----+-----|
| 0.5 | 1.0 | 0.5 |
|-----+-----+-----|
| 0.3 | 0.5 | 0.3 |

といった具合に。
重みを計算するのが lanczos 関数。
lanczos2 や lanczos3 の数字は距離で、縮小画像のあるピクセルを計算するために、対応する元画像ピクセルからどれくらいの範囲を参照するかを決めるものっぽい。

となると、縮小率と距離の数字が決まれば、対象のピクセルがどこであろうと、重みは一緒?
というわけで、先に上記のような重みの表を作成しておき、各ピクセル計算時はそれを使用すれば計算量は減るだろう。

中心からのオフセットと重みを保持するクラス

public class Weight {
  public final int offsetX;
  public final int offsetY;
  public final double weight;

  public Weight(int x, int y, double w) {
    offsetX = x;
    offsetY = y;
    weight = w;
  }
}

重みの一覧と合計を保持するクラス

public class WeightFilter {
  public final double weightTotal;
  public final Weight[] weightList;


  public WeightFilter(double sumw, Weight[] weights) {
    weightTotal = sumw;
    weightList = weights;
  }
}

lanczos 関数

public static double lanczos(double x, double n) {
  if (x == 0.0) return 1.0;
  if (Math.abs(x) >= n) return 0.0;
  return Math.sin(Math.PI * x) / Math.PI / x * (Math.sin(Math.PI * x / n) / Math.PI / x * n);
}

縮小率と距離で重み一覧作成

縦・横別でなく斜めも距離を計算してみる
public static WeightFilter getReduceFilter(double scale, int distance) {
  double bdx0 = 0 + 0.5, bdy0 = 0 + 0.5;
  int ss = (int)((bdx0 - distance) / scale), se = (int)((bdx0 + distance) / scale);
  double sumw = 0.0;
  List<Weight> weightList = new ArrayList<>((se - ss) * (se - ss));

  for (int sy = ss; sy <= se; ++sy) {
    for (int sx = ss; sx <= se; ++sx) {
      double xl = (sx + 0.5) * scale - bdx0;
      double yl = (sy + 0.5) * scale - bdy0;
      double w = lanczos(Math.sqrt(xl * xl + yl * yl), distance);
      if (w == 0.0) continue;
      weightList.add(new Weight(sx, sy, w));
      sumw += w;
    }
  }
  return new WeightFilter(sumw, weightList.toArray(new Weight[0]));
}


ユーティリティ関数も作成。

指定座標の RGB 値取得

範囲外は鏡像として取得。
public static int getRGB(int[] image, int x, int y, int w, int h) {
  x = Math.abs(x); y = Math.abs(y);
  if (x >= w) x = w + w - x - 1;
  if (y >= h) y = h + h - y - 1;
  return image[y * w + x];
}

0 - 255 の範囲で色値取得

public static int getColor(double val, double sumw)
{
  if (sumw != 0.0) val /= sumw;
  if (val < 0.0) return 0;
  if (val > 255.0) return 255;
  return (int)val;
}

縮小処理

public static BufferedImage reduce3(BufferedImage image, int n, int dw, int dh)
  int sw = image.getWidth(), sh = image.getHeight();

  double scale = (double)dw / sw;
  BufferedImage thumb = new BufferedImage(dw, dh, image.getType());
  WeightFilter filter = getFilter(scale, n);
  double sumw = filter.weightTotal;
  int[] colors = image.getRGB(0, 0, sw, sh, null, 0, sw);

  for (int dy = 0; dy < dh; ++dy) {
    for (int dx = 0; dx < dw; ++dx) {
      double dr = 0.0, db = 0.0, dg = 0.0;
      int bsx = (int)(dx / scale), bsy = (int)(dy / scale);
      for (Weight weight : filter.weightList) {
        int rgb = getRGB(colors, bsx + weight.offsetX, bsy + weight.offsetY, sw, sh);
        dr += ((rgb >> 16) & 0xFF) * weight.weight;
        dg += ((rgb >> 8) & 0xFF) * weight.weight;
        db += (rgb & 0xFF) * weight.weight;
      }
      thumb.setRGB(dx, dy, (getColor(dr, sumw) << 16) | (getColor(dg, sumw) << 8) | getColor(db, sumw));
    }
  }
  return thumb;
}

呼び出し

lanczos2 と lanczos3 で縮小。
long start3_1 = System.currentTimeMillis();
BufferedImage reduce3_1 = reduce3(base, 2, 120, 90);
System.out.println("reduce3_1: " + (System.currentTimeMillis() - start3_1));
outputImage("reduce3_1.jpg", reduce3_1);

long start3_2 = System.currentTimeMillis();
BufferedImage reduce3_2 = reduce3(base, 3, 120, 90);
System.out.println("reduce3_2: " + (System.currentTimeMillis() - start3_2));
outputImage("reduce3_2.jpg", reduce3_2);

結果

lanczos2: 126.3ms
lanczos3: 233.0ms

元画像と左から、パターン1 3段階、パターン2 3段階、lanczos2、lanczos3




大分早くなった。JDK に比べると遅いが画質はいい。
一度作成してた後は、キャッシュするようにすればいいので、満足。

Java による画像縮小 JDK 編

忙しい日々が続いて、色々嵌っているが書けていない・・・
また同じ事で嵌まることになるだろう・・・

半年以上前だが、Java で画像を縮小してサムネイルを作成する際に、なるべく画質を落としたくなかったので色々試したのでその記録を。
結局ブログ書くために再調査したわけだけ・・・

元となる画像(1024 x 768)は、
これから 120 x 90 のサムネイルを作成することとする。


共通処理として、

画像読み込み

public static BufferedImage loadImage(String filename) {
  try (FileInputStream in = new FileInputStream(filename)) {
    return ImageIO.read(in);
  }
}

画像出力

// 品質 95 Jpeg
public static void outputImage(String filename, BufferedImage image) throws IOException {
  JPEGImageWriteParam param = new JPEGImageWriteParam(Locale.getDefault());
  param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
  param.setCompressionQuality(0.95f);

  ImageWriter writer = ImageIO.getImageWritersByFormatName("jpg").next();
  writer.setOutput(ImageIO.createImageOutputStream(new File(filename)));
  writer.write(null, new IIOImage(image, null, null), param);
  writer.dispose();
}
の 2 つを用意。

縮小処理は、2 パターン。

パターン1 BufferedImage#getScaledInstance() を使用

public static BufferedImage reduce1(BufferedImage image, int dw, int dh) {
  BufferedImage thumb = new BufferedImage(dw, dh, image.getType());
  thumb.getGraphics().drawImage(image.getScaledInstance(dw, dh, Image.SCALE_AREA_AVERAGING), 0, 0, dw, dh, null);
  return thumb;
}

パターン 2 Graphics2D#drawImage() を使用

public static BufferedImage reduce2(BufferedImage image, int dw, int dh) {
  BufferedImage thumb = new BufferedImage(dw, dh, image.getType());
  Graphics2D g2d = thumb.createGraphics();
  g2d.setRenderingHint(RenderingHints.KEY_ALPHA_INTERPOLATION, RenderingHints.VALUE_ALPHA_INTERPOLATION_QUALITY);
  g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
  g2d.setRenderingHint(RenderingHints.KEY_COLOR_RENDERING, RenderingHints.VALUE_COLOR_RENDER_QUALITY);
  g2d.setRenderingHint(RenderingHints.KEY_DITHERING, RenderingHints.VALUE_DITHER_ENABLE);
  g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);
  g2d.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);
  g2d.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_NORMALIZE);
  g2d.drawImage(image, 0, 0, dw, dh, null);
  return thumb;
}

パターン1、パターン2 をそれぞれ呼び出し

try {
  BufferedImage base = loadImage("base.jpg");
  int dw = 120, dh= 90;

  long start1_1 = System.currentTimeMillis();
  BufferedImage reduce1_1 = reduce1(base, dw, dh);
  System.out.println("reduce1_1: " + (System.currentTimeMillis() - start1_1));
  outputImage("reduce1_1.jpg", reduce1_1);

  long start2_1 = System.currentTimeMillis();
  BufferedImage reduce2_1 = reduce2(base, dw, dh);
  System.out.println("reduce2_1: " + (System.currentTimeMillis() - start2_1));
  outputImage("reduce2_1.jpg", reduce2_1);
} catch (Exception e) { e.printStackTrace(); } 

パターン1はぼやけた感じ、パターン2はざらついた感じ。
連続で 4 回実行し、1 回目を除いた 3 回の平均時間を計測。
速度はパターン2が早いが、今回は作成した画像をキャッシュするので速度より画質。

パターン1:  80.3ms


パターン2: 0.7ms


段階的に縮小

近傍縮小法だと、大きな画像から一気に縮小すると色情報の欠落が大きくなるので、段階的に縮小してみる。
  • 1024x768 -> 640x480 -> 120x90 の 2 段階
  • 1024x768 -> 800x600 -> 480x360 -> 120x90 の 3 段階
の 2 つそれぞれのパターンで実行。
int dw2_1 = 640, dh2_1 = 480;
int dw3_1 = 800, dh3_1 = 600, dw3_2 = 480, dh3_2 = 360;

long start1_2 = System.currentTimeMillis();
outputImage("reduce1_2.jpg", reduce1(reduce1(base, dw2_1, dh2_1), dw, dh));
System.out.println("reduce1_2: " + (System.currentTimeMillis() - start1_2));

long start2_2 = System.currentTimeMillis();
outputImage("reduce2_2.jpg", reduce2(reduce2(base, dw2_1, dh2_1), dw, dh));
System.out.println("reduce2_2: " + (System.currentTimeMillis() - start2_2));

long start1_3 = System.currentTimeMillis();
outputImage("reduce1_3.jpg", reduce1(reduce1(reduce1(base, dw3_1, dh3_1), dw3_2, dh3_2), dw, dh));
System.out.println("reduce1_3: " + (System.currentTimeMillis() - start1_3));

long start2_3 = System.currentTimeMillis();
outputImage("reduce2_3.jpg", reduce2(reduce2(reduce2(base, dw3_1, dh3_1), dw3_2, dh3_2), dw, dh));
System.out.println("reduce2_3: " + (System.currentTimeMillis() - start2_3));
パターン1 2段階: 141.7ms


パターン1 3段階: 215ms


パターン2 2段階: 7.3ms


パターン2 3段階: 16.3ms


多少マシになったが、ちょっと納得いかないレベル・・・
続く

2012年4月22日日曜日

Apache + Tomcat のレスポンス

ここのところ忙しく、全然更新していなかったが、実際には色々嵌りまくりな日々・・・

その中でも最近一番大きかったのが、Apache + Tomcat の構成でレスポンスがおかしい現象が発生。
しばらく使っていると、別のリクエストのレスポンスが返ってくるようになる。
別のユーザのユーザ情報が見えたり・・・セッションがおかしくなったり・・・

Apache または、Tomcat のいずれかを再起動すると普通に戻るがしばらくするとまた発生し始める
プログラムのせいではないことを祈り調査。

接続は mod_proxy_ajpを使用して mod_proxy_balancer で分散していた。
分散していないテスト環境でも発生していたため、mod_proxy_balancer は調査から除外。
mod_proxy_ajp を mod_proxy_http に変更したところ発生しなくなった。
過去に何度も Apache + Tomcat, mod_proxy_ajp 構成をやったことはあるが初めての現象。

次に、Apache 2.4 を使っていたため、2.2 にダウングレード。
mod_proxy_ajp で接続して問題は発生しなかった。

つまり、Apache 2.4 の mod_proxy_ajp が問題だったと思われる。
Apache 2.4 は今回初めて使用したが、まだ早かったんだろうか・・・

2012年2月12日日曜日

Pacemaker で仮想 IP の切り替え

Pacemaker でまず仮想 IP の切り替えを行う時に嵌まったこと。

OS は CentOS 5.7 でやってみる。インストールは、LINUX-HA JAPAN より、ローカルリポジトリ + yum を使用。

クラスタ制御部には、Corosync を使用することにする。
/etc/corosync/corosync.conf を作成。
# Please read the corosync.conf.5 manual page
compatibility: whitetank

aisexec {
        user: root
        group: root
}

service {
    name: pacemaker
    ver: 0
    use_mgmtd: yes
}

totem {
    version: 2
    secauth: off
    threads: 0
    rrp_mode: active
    clear_node_high_bit: yes
    token: 4000
    consensus: 10000
    rrp_problem_count_timeout: 3000
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.234.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
        ttl: 1
    }
}

logging {
    fileline: on
    to_stderr: no
    to_logfile: yes
    to_syslog: no
    logfile: /var/log/cluster/corosync.log
    debug: off
    timestamp: on
}
bindnetaddr にはインターフェースの IP でなくネットワークアドレスを指定する。
ログをファイルに出力するように指定。

/etc/init.d/corosync start で起動して、crm_mon を実行して確認する。
Attempting connection to the cluster.........................
帰ってこない・・・

一般ユーザで実行したからっぽい。グループに、haclient を追加したら帰ってきた。
============
Last updated: Sun Feb 12 00:54:09 2012
Stack: openais
Current DC: localhost.localdomain - partition WITHOUT quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
1 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ localhost.localdomain ]

次に、 crm configure help でコマンドを確認しようとするも、
cibadmin not available, check your installation
となる、sudo でやってもダメだった。仕方ないので root になって行う。
# crm configure property no-quorum-policy="ignore" stonith-enabled="false"
# crm configure rsc_defaults resource-stickiness="INFINITY" migration-threshold="1"
# crm configure primitive vip ocf:heartbeat:IPaddr2 \
params ip="192.168.234.51" nic="eth0" cidr_netmask="24" op monitor interval="10s"
eth0 に 192.168.234.51 の仮想 IP を作成する設定。

ifconfig で確認するも設定したアドレスが見当たらない。
eth0 にはそもそも実インターフェースの IP が割当たっているからだ。
ip addr show eth0 で確認できる。
inet 192.168.234.51/24 brd 192.168.234.255 scope global secondary eth0

最初、CentOS 6 を使用して普通に yum でインストールして開始したわけだが、こっちのほうが嵌まった。
Pacemaker が 1.1 になっており、クラスタ部に heartbeat が使えなかったり、corosync.conf の service の ver を 1 にしないとだったり、vip 指定時に nic に eth0:1 などを指定すると警告が出たりとかなり面倒だった。

結局、CentOS5.7 を使うことになり、落としたわけだが・・・

2012年1月11日水曜日

SAStruts + Maven

久々、Java での Web アプリケーションを作成をすることに。
最近のフレームワークが分からないため、今更 SAStruts を選択。最近は何がメジャーなんだろうか・・・

とりあえず開発環境を最新版でそろえていく。
  • JDK 1.7.0_02
  • Maven 3.0.3
  • Eclipse 3.7 64bit(Pleiades のプラグイン + Maven プラグイン)
  • Tomcat 7.0.23 -> 6.0.35
Maven で SAStruts のプロジェクトを作成。
# mvn archetype:generate -DarchetypeRepository=https://www.seasar.org/maven/maven2/ \
  -DarchetypeGroupId=org.seasar.sastruts \
  -DarchetypeArtifactId=sa-struts-archetype -DarchetypeVersion=1.0.4-sp9.0 \
  -DgroupId=com.example.sample.sas -DartifactId=sas -Dversion=1.0.0 
Eclipse 用プロジェクト作成。
# cd sas
# mvn eclipse:eclipse -Dwtpversion=1.5
Eclise で「インポート」->「一般」->「既存プロジェクトをワークスペースへ」でインポート。が、ここで問題発生。
プロジェクトを右クリックしても Maven のメニューが出てこない・・・ Maven プラグインは入れたはずなのに。 昔はこれでいけてた気がしたが、バージョンが上がって変わったのだろうか。

色々検索したり、Maven のバージョン変えたりプラグインを再インストールしたりしてみたがうまくいかない。で、かなりして Eclipse のインポートメニューに Maven の項目を発見。
 mvn archietype:generate でプロジェクト作成後、mvn eclipse:eclipse は行わずに、Eclipse の「インポート」->「Maven」->「Existing Maven Project」でインポート。途中、「maven-antrun-plugin:1.3:run (1 errors)」 とエラーが出るがかまわず完了。これで、プロジェクトの右クリックメニューに Maven の項目が出た。

取り込み後、pom.xml に警告とエラーが出ているので潰していく。
まず、<project> タグで警告がでるため、クイック・フィックスで修正。

次に、maven-antrun-plugin の「Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-antrun-plugin:1.3:run (execution: delete-lib-dir, phase: initialize)」もクイック・フィックスの「Permanently mark goal run in pom.xml as ignored in Eclipse build」で修正する。

最後の、maven-dependency-plugin の「maven-dependency-plugin (goals "copyff-dependencies", "unpack") is not supported by m2e.」は、上記修正で追加された、pluginManagement/plugins/plugin/configuration/lifecycleMappingMetadata/pluginExecutions に設定を追加する。
<pluginExecution>
  <pluginExecutionFilter>
    <groupId>
      org.apache.maven.plugins
    </groupId>
    <artifactId>
      maven-dependency-plugin
    </artifactId>
    <versionRange>[1.3,)</versionRange>
    <goals>
      <goal>copy-dependencies</goal>
    </goals>
  </pluginExecutionFilter>
  <action>
    <ignore></ignore>
  </action>
</pluginExecution>
ついでに、build/plugins/plugin/artifactId が maven-compiler-plugin の source と target を 1.7 に変更。

プロジェクトを右クリックして 「Maven」 -> 「プロジェクト構成の更新」を実行して反映すればエラーと警告が消えた。

次に、WTP の設定。
プロジェクトを右クリックしてプロパティを開き、プロジェクト・ファセットを選択。
Convert to faceted from... をクリック。動的 Web モジュールにチェックを入れて、バージョンを確認すると、3.0 になっている。SAStruts は 3.0 で動くのだろうか・・・調べてみるとどうもダメっぽいので、2.5 に変更。よって Tomcat も 6 に落とす。
プロジェクト・ファセットの設定がなぜだか、1 回目だと失敗する。2 回やると通ったのでそのまま続けることにする・・・
次に、プロパティダイアログの Deployment Assembly を選択。/WebContent の行を削除。追加をクリックして、 「フォルダー」より src/main/webapp を追加。/WebConent のディレクトリは物理的に削除して大丈夫だと思われる。さらに、追加をクリックして、「Java Build Path Entries」より Maven 依存関係を追加。

src/main/webapp/WEB-INF/web.xml のバージョンが 2.4 になっているので 2.5 に変更。
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
  id="WebApp_ID" version="2.5">
dependencies/dependency の geronimo-jsp_2.0_spec を geronimo-jsp_2.1_spec に、バージョンを 1.0 から 1.0.1 に変更。
同じく、geronimo-servlet_2.4_spec を geronimo-servlet_2.5_spec に、バージョンを 1.0 から 1.2 に変更。

プロジェクトを右クリックして、「実行」->「サーバで実行」でサーバを起動すると特にエラーもなく無事起動。
だが、ブラウザで http://localhost:8080/sas/ にアクセスすると、「org.apache.jasper.JasperException: /WEB-INF/view/index.jsp(1,1) /WEB-INF/view/common/common.jsp(1,61) JARファイル "file:/ワークスペースのパス/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/sas/WEB-INF/lib/standard-1.1.2.jar" からTLD "META-INF/c.tld" を読み込めません: org.apache.jasper.JasperException: TagLibraryValidatorクラスのロード又はインスタンス化に失敗しました: org.apache.taglibs.standard.tlv.JstlCoreTLV 」と 500 エラーになる。 

これも結構嵌まったが、どうも pom.xml の provided の jar を読み込んでいる模様。
WTP 実行時に、pom.xml の povided を認識しないらしい。

検索してみると m2e-wtp なるものを発見。インストールしてみる。
「ヘルプ」->「Eclipse マーケットプレース」検索してインストール。
プロジェクトを右クリックして 「Maven」 -> 「プロジェクト構成の更新」を実行後、起動すると無事「Hello!」が表示された。

プラグインをインストールしたことでかなり飛ばせる手順がありそうだが、次回もこの手順でやれば同じ結果になるだろう・・・

2012年1月3日火曜日

財布購入

革の財布が欲しかったので、財布を買うなら正月かなということで商品券もあったことだし百貨店に行って来た。

近所の、伊勢丹、日本橋の三越本店へ。さらに、銀座の松坂屋と三越に行ってみた。 長財布で小銭入れ付かラウンドファスナーのタイプが欲しくて、気になったものはいくつがあったが、これ!というものがなかったので転々と。
最後の銀座三越で気に入ったものがあったが、予算より若干オーバー。しかも、コードバンとブライドルレザーの 2 種類あって悩むことに。店員さんの説明を聞いたりして長々と考えたが、悩んでる時点で買うことはほぼ確定していたんだろう。結局コードバンを買ってしまった。

GANZO のコードバンの長財布、小銭入れ付。影が写り込んでるが・・・
色はダークブラウン。38,850円だった。

 コードバンなので硬いのは当然だけが、カードを入れるのが結構大変。カード入れ全てにカードを入れるとパンパン。完全開くにも硬いので小銭や札を出すだけでも結構厄介。 ブライドルレザーのほうが少し軟らかく、完全に開いた上にさらに反対側に開いたので扱いやすいだろうなといったところでも迷ったわけだが。
まぁなじむだろうと期待してコードバンにしてみた。使い込んでいかないと。