2015/07/27(月)春M(SpringM)でSusie Plug-inが使用できない

2015/07/27 15:00 PC(全般)
春M(SpringM)で、Susieプラグインが使えなくなった問題。

以下前提。

SpringMの組み込み画像ビューア(pview)は、自動的にSusieプラグインを読み込んで使用してくれる。

プラグインのディレクトリはオプション等で指定出来ない。
SpringM上でハードコーディングされたSusieのレジストリを見にいっているようだ。

で、本題。

現在、Susieのサイトで更新されている最新β版Susie

Susie 0.50 beta3(Jan 15,2013)

は内部的にはSusie2扱いで、レジストリの場所・構造・生成タイミングが旧Susie(~0.47)と違う。

[~0.47]
HKEY_CURRENT_USER\Software\takechin\Susie
※起動初回に生成

[0.50~]
HKEY_CURRENT_USER\Software\takechin\Susie2
※インストール時に生成

SpringMは旧Susie(~0.47)のレジストリしか見に行かないため、SpringMでSusieプラグインを使用する場合は1度旧Susieを1回起動してやる必要がある。それから新Susie(0.50~)に更新するか、新Susieとは別に旧Susieを入れっぱなしにしておくかは任意。

幸にして、まだSusie32 ver0.47bが公開されているのでこれを利用すること。

一度旧Susieを起動してしまえば、レジストリには残りっぱなしなのでディレクトリ移動をしない限り問題は起きない。
Windows再インストールの時など、環境作り直し時にはまる可能性があるので注意。

2015/07/09(木)logbackでサイズローテートしない

logbackでログがファイルサイズでローテートしない問題。

Java1.7 + logback-1.1.3

条件は実行時間が短いバッチのようなプログラム。

もともと↓の記述にしていたのだが、ローテートしてくれなかった。
[logback.xml]
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>./logs/hoge.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
      <fileNamePattern>./logs/hoge.%i.log.zip</fileNamePattern>
      <minIndex>1</minIndex>
      <maxIndex>3</maxIndex>
    </rollingPolicy>
    
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
      <maxFileSize>5MB</maxFileSize>
    </triggeringPolicy>
    <encoder>
      <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger\(%F[%L]\) - %msg %n</pattern>
      <charset>Shift_JIS</charset>
    </encoder>
  </appender>
調べてみると、logbackのSizeBasedTriggeringPolicyはI/O負荷対策のためファイルサイズを毎度チェックしにいかない。デフォルトでは16回に1回であり、16回ログ出力して初めてサイズチェックに行く。ログ出力の頻度が多いと間隔を開け、頻度が少ないと間隔を狭める。

今回のプログラムは16回ログを出すフローがほとんどない。実行時間も短いため、間隔調整の恩恵も受ける暇がない。親切ではあるのだが、プロセス内の初回はチェックするなど対策が必要に思う。

このプログラムごく短時間で起動->終了し、ログの出力回数・起動頻度とも高くない。毎回チェックとしたい。

[logback.xml]
    <triggeringPolicy class="foo.bar.CustomSizeBasedTriggeringPolicy">
[カスタムクラス]
package foo.bar;

import java.io.File;

import ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy;
import ch.qos.logback.core.util.FileSize;

public class CustomSizeBasedTriggeringPolicy<E> extends SizeBasedTriggeringPolicy<E> {

	String maxFileSizeAsString = Long.toString(DEFAULT_MAX_FILE_SIZE);
	FileSize maxFileSize;

	public CustomSizeBasedTriggeringPolicy() {
	}

	public CustomSizeBasedTriggeringPolicy(final String maxFileSize) {
		setMaxFileSize(maxFileSize);
	}

	@Override
	public boolean isTriggeringEvent(final File activeFile, final E event) {
		//オリジナルのisTriggeringEventでは発火しないことがあるため、ログ書き出しごとにチェックする
		return (activeFile.length() >= maxFileSize.getSize());
	}

	@Override
	public String getMaxFileSize() {
		return maxFileSizeAsString;
	}

	@Override
	public void setMaxFileSize(String maxFileSize) {
		this.maxFileSizeAsString = maxFileSize;
		this.maxFileSize = FileSize.valueOf(maxFileSize);
	}
}
isTriggeringEventだけいじったクラスを作成してやって、logback.xmlでそちらを見るようにしてやる。

とりあえずこれで動くことは動く。

2015/07/09(木)LogbackでプロセスIDを出力

logbackでプロセスIDを出す方法。

Java1.7 + logback-1.1.3

あまりいい方法が見つからなかったが、とりあえず出りゃいいやまではできた。

起動コマンドなりスクリプトなりがいじれるのなら、SystemProperty経由で設定・取得する方法が使える。

[起動コマンド]
exec java -Dpid=$$ -jar /foo/bar.jar
[logback.xml]
<pattern>%d{yyyy/MM/dd HH:mm:ss} [${pid}] %level %msg%n</pattern>
-Dpid=$$で、プロパティ:pidにプロセスIDをセット、patternに${pid}と記述してやるとlobackの機能で出力できる。
もちろんUnix環境限定。

なお、シェル側のプロセスIDがほしい場合は、execを外し直接javaコマンドをたたく。
java -Dpid=$$ -jar /foo/bar.jar
Webアプリケーションで動いている場合は、何がしかプロセスIDに相当するものがSystemPropertyにいると思うので${}でそれを拾えばいい(はず)。

本当なら、ManagementFactory.getRuntimeMXBean()で取得するのが正解のようだが、その場合PatternLayoutをカスタムしてコンバータをいじって… とやらなければいけない気がする。規模によってはさすがに大仰か。

[参考]
Igor Minar's Blog: How a Java Application Can Discover its Process ID (PID)

2015/06/28(日)jessieで起動しない

2015/06/28 19:14 PC(Linux)
jessieにアップグレードした際に起動周りで色々問題が起きたのでメモ。

一部解決、かなり未解決。

段階的に修正していくしかなさそう。

grub起動時、コンソールにFile not foundが3回出力される

→解決
#grub-install /dev/sda
#update-grub 
で改善した(他に色々作業していたので、別の処置で改善した可能性も)

systemdで起動しない

→解決

jessieではgrubにsystemdとsysvinitが両方登録される。
wheezy時代には起動していたカーネルのsystemd版は起動しない。sysvinit版だと起動する。

jessieからinit周りがsystemdに切り替わるため、init.dでカスタマイズしたサービスが動かないとは聞いていたが起動しないとは想定外。

原因はfstabにあった。
どうやら、systemdではfstabの記述を厳密に解釈するらしい。usb外付けで繋いでいたドライブ(今は繋いでいない)のoptionsが
defaults
になっていた。
user,noauto
に修正して改善。

3.16.0-4-686-paeで起動しない

未解決解決

wheezyで入っていた3.2.0-4-686-paeは起動するのだが、3.16.0-4-686-paeで起動しない。
gave up waiting for root device 

alert /dev/disk/by-uuid/~~ does not exist
が出る。
busyboxのシェルであれこれ試してみると、
・/dev/disk/by-uuid/が無い
・そもそも/dev/sda1が無い
・cat /proc/modules は空

全くドライバが読めていないっぽい。

起動するカーネル(3.2.0-4-686-pae)のinitrdは12MB
起動しないカーネル(3.16.0-4-686-pae)のinitrdは4MB

lsinitramfsでのぞくと、3.16の方は/lib/modules/3.16.0-4-686-pae/kernel配下がまるごと無い

update-initramfs -uで症状変わらず
起動オプションrootdelay=90等で症状変わらず
depmod -a 3.16.0-4-686-paeでも症状変わらず
ここで今回の調査は断念。

initramfs-toolsのバグだか考慮漏れだかに当たっているような気がしている。

自分でカーネル作り直せば確実なのは分かっているが、そもそも管理コストを下げるためにカーネルもdebian標準にしたいというのが方針なので、しばらく標準でのinitrd正常化方策を探すことにする。といってもかなり色々試してはいるので、調べ方変えるか時間に解決してもらうかじゃないとちょっと無理そう。
[2015/07/28 追記]
時間が取れたので、ひたすら人力で調べてみた。

まずupdate-initramfs内で呼び出しているmkinitramfsを直に叩いてみるが、やはりmodulesが抜ける。
#mkinitramfs -o /boot/initrd.img-3.16.0-4-686-pae.new 3.16.0-4-686-pae
mkinitramfsをたどっていくと、/usr/share/initramfs-tools/hook-functions内のmanual_add_modulesでmodprobeの結果を元にループを回している箇所がある。ここが3.2では動いているのに3.16では動いていない。はて。

スクリプト内で使用しているコマンドをログインシェルで叩いてみるが、いずれのバージョンも問題がない。
#modprobe --all --set-version=3.2.0-4-686-pae --ignore-install --quiet --show-depends eql
insmod /lib/modules/3.2.0-4-686-pae/kernel/drivers/net/eql.ko

#modprobe --all --set-version=3.16.0-4-686-pae --ignore-install --quiet --show-depends eql
insmod /lib/modules/3.16.0-4-686-pae/kernel/drivers/net/eql.ko
とすると、mkinitfamfs内の環境変数が原因か。

で、調べたところ、
#export PATH=/usr/bin:/sbin:/bin
で動きが変わることが分かった。げーっ。実行ファイルゴースト問題だー。

結局のところ、modprobeもdepmodも/sbinと/usr/local/sbinの両方にありログインシェルでは/usr/local/sbinを見ていた。
/usr/local/sbinの方のタイムスタンプは2004年、うぉう。

あとは推測だが、aptでカーネルイメージを入れた際に/usr/local/sbinの古いdepmodを呼んでしまうようだ。古いdepmodは、/lib/modules/<< version >>/modules.dep.binを生成しない。同じく/usr/local/sbinの古いmodprobeはこれで動くのだが、新しい/sbinのmodprobeは
#/sbin/modprobe --all --set-version=3.16.0-4-686-pae --ignore-install --show-depends eql

modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/3.16.0-4-686-pae/modules.dep.bin'
となってしまう(quiet無しだとエラーが出る。ありだと何も出ない)。

3.2は何かのタイミングで新しいmodprobeを発火するタイミングがあった模様で、modules.dep.binがいた。そんな状態で良く動いてたな。

ということで、depmodもmodprobeも新しい方を使ってやればよい。
#/sbin/depmod -v 3.16.0-4-686-pae
これで
/lib/modules/3.16.0-4-686-pae/modules.dep.bin
ができた。

あとはこれでinitrdを作ってやる。
#update-initramfs -u -k 3.16.0-4-686-pae
丸々と太った健康そうな16MBのinitrdができた。

うーん、やっぱりwoodyのアップグレード&アップグレードじゃ限界あるなあ。

grub上でメニューいじったときにunaligned pointer 0x8が出る

→未解決

grub起動時にオプションをeで変えると、
unaligned pointer 0x8
が出る。

GRUBのバグかなあ。

デフォルト起動カーネル切り替え

ということで、しばらくwheezy時代のsysvinitカーネルを使用する。systemdにするためには洗い出しが必要なので3.16が動くようになってからにしたい。

/etc/default/grub
GRUB_DEFAULT="Debian GNU/Linux, with Linux 3.2.0-4-686-pae (sysvinit)"
最初上記形式で書いたが、update-grubしたらwarningが出たので、
/etc/default/grub
GRUB_DEFAULT="gnulinux-advanced-~~>gnulinux-3.2.0-4-686-pae-init-sysvinit-~~"
に変更して、update-grub。

これでとりあえず再起動しても特に操作せずに起動するようになった。
うーん、サーバつぶした方がいいんだろうか。
こういうドハマリは維持意欲を削ぐ。

このサーバはwoodyからの10年選手なので64bit化も含め再インストール時期ではあるのだが……

2015/04/12(日)https通信が出来なくなる

2015/04/12 15:20 PC(全般)
4/3くらいからWindows7(64bit)のhttps通信が死んでいた問題。
とりあえず、回復したのでメモだけ。

[症状]
・PC1では問題あり、PC2では問題なし
・Chrome, IE, OpenTween, Tween, Windows Update, リモートデスクトップで全https通信がタイムアウトする
・Firefox, Twitamaだと問題なし
・ChromeだとエラーメッセージERR_TIMED_OUT
・OpenTweenは起動後ハング
・リモートデスクトップは 「リモート接続を保護しています」の画面でハング
・セーフモードだと上記いずれもタイムアウトしない(!?)

[確認したこと]
・Windows Firewall問題なし
・アンチウイルスソフトON/OFF症状変わらず
・スパイウェア対策ソフトON/OFF症状変わらず
・最初証明書を疑ったが、証明書ではないっぽい
・ウイルス・マルウェアを疑ったが、とりあえず検出されずそれっぽい挙動も見えず
・パケットキャプチャすると、正規のプロセスがちゃんと通信し始めてるのだが、通信の途中で途絶してTCP/IPタイムアウトでRSTが走っている

[対処]
・デバイスマネージャーから"Realtek PCIe GBE Family Controller"を削除してOS再起動→自動認識させたところ、通信ができるようになった

[参考]
PC Gamer リスト更新中 : Chromeで一部サイトのみSSL接続がタイムアウトするようになってしまった

ちゃんとパケットキャプチャを取っておかなかったのだが、Windows Updateなどによりフレームの分割数・サイズがドライバのバグに当たった、もしくはドライバそのものが何かに感染したのだろうか。

なんとなく
Win7 -> WinXPファイルコピー問題
これと同様の問題の気配。

httpsだけというのははじめてだったのでかなりハマった。

蟹ドライバがevilだったかどうかは確定できなかったが、やっぱり蟹は極力視界から排除した方がいいように思う。

2014/11/24(月)よくわからないビデオカードの話

2014/11/24 17:01 PC(全般)
ビデオカードがよくわからない。

3Dゲーム性能は全く求めていないのでCPU内蔵でもいいかと思っていた。
が、PhotoShopやら動画再生やら考えたときにRADEONとか使うと改善するのでは? と思う場面があった。

その後紆余曲折あって、安物AMDビデオカード、nVidiaビデオカードと使ってみて、存外に動きが違う。しかもどれも一長一短。

どうすりゃいいのか分からないのでとりあえずメモっておく。

なお、完璧に環境揃えてテストしたわけではないので、誤認がある可能性あり。HD3000は細かく覚えてないので嘘がある可能性が高い。ドライバはその時点での最新版(非β)。
そもそも完璧に環境をフラットに出来なさそうではあるが……

試したのは3種。
・HD3000(i5 2500K内蔵)
・玄人志向 GF-GT520-LE1GH DDR3 1024MB(以下GT520)
・Sapphire HD6450 DDR3 512MB(bulk品型番不明、以下HD6450)
HD3000HD6450GT520
90°回転した拡張ディスプレイ間をまたぐWindowの描画正常かなり変
デジタル放送視聴ソフト複数使用時の"CPU"負荷普通普通ちょい重い
デジタル放送視聴ソフト複数使用時の"GPU"負荷普通軽い重い
PhotoShopでOpenGL ON+ブラシを使用遅延大遅延小
確認してるのは自分が使っていて気になっている項目。

上から順に。

90°回転した拡張ディスプレイ間をまたぐWindowの描画

マルチディスプレイで、拡張デスクトップ&サブディスプレイを縦に回転して使っている。資料なんかを置くには縦の方が見やすいので。

が、どうもウィンドウをディスプレイ間に置くと表示が乱れるカード(ドライバ?)が多い。

良く問題を生じるのがビデオ再生とかで、特にオーバーレイは鬼門(仕方ない気もするが)。
ウィンドウの境を左端として二重に描画してしまっているケースが多い。

GT520だとFireFoxですらこの症状が出る。HD6450は割と思った通りになる。

|デジタル放送視聴ソフト複数使用時のCPU/GPU負荷

デジタル放送視聴ソフトを4つ5つ立ち上げることがある。コーデックとかの設定は、EVR+AMD Video Decoderにしている。

CPU負荷では大きな差はなく、HD6450が少し軽いくらい。1窓当たり3~5%くらいのCPU負荷がかかる。どれも再生支援が順当に効いているのか、ビデオカードよりコーデックを変える方が影響がでかい。

問題はGPU負荷。process explorerのGPU usageとかで見ると、4窓でGT520は50%を超え、他のありとあらゆる描画に遅延が生じる。

HD6450だと20%台をうろうろで、特に重くなることはない。HD3000は測っていないが、GT520ほど重くない。

なお、コーデックをMicrosoft DTV-DVD Video Decoderにした方が数字上のCPU負荷は低いのだが、CPU負荷と関係なく、HD6450 + AMDコーデックは再生窓のドラッグが快適だったりするのでさらに厄介。

PhotoShopでOpenGL ON+ブラシを使用

最後にPhotoShopのブラシ。

Adobe PhotoShopはCS6(5だっけ?)からOpenGLによるキャンバスの回転やブラシの先端プレビュー、3D機能を実装した。

自分を含む一部の人には待望の機能だったのだが、HD6450だとブラシサイズが小さい場合でもかなり描画遅延する。描画がカーソルを遅れて付いてくる。先端プレビューを非表示にしても改善せず、OpenGLを切ると遅延はなくなる。ただ、キャンバスの回転が無くなるのが厳しい。GT520だと遅延は十分に小さく感じる。

まとめ

で。

こういうのはカタログスペックだとホントよくわからない。

ハードの問題か、ドライバーの問題か、OSの問題か、アプリケーションの問題か、あるいはウイルス対策ソフトが邪魔しているのか、自分の使い方の問題か、切り分けるのは極めて難しい。

もちろん内蔵と大して差がないような安いビデオカードでの比較なのであーだこーだ言い難いのだが、アップグレードとして何買ったらいいのかよくわからない。

再生支援が優秀なGeForce? アーキテクチャの新しいRADEON?

答えはなんだろ、あるいは答えはないのか。

とりあえず、来年Broadwell-KかSkylake買うだろうからその時にもう一回見直しかなあ……

2014/10/19(日)サーバ交換

2014/10/19 25:26 PC(Linux)
サーバが故障したので交換したという話。

故障したのはpanasonic CF-T8EC6AAS。

このシリーズはどうもファンが弱いらしい。中古で買ったものなので耐久性がどうとか言いづらいのだが、うちのは使用しはじめてから1年程度でファンが強烈な異音を発するようになってしまった。ネットにもファン故障の報告多数。

その前に使っていたnx6110は6年稼働していたので、ちょっとがっかり。

nx6110の故障箇所についてはメモって無くておぼろげなのだが、ファンか熱暴走を疑う症状だったように思う。

さて、とりあえず入れ替えなければいけないので秋葉原でノートPCを調達してきた。
今回はPC-VY14A/C-7のOS無しが比較的安く手に入ったのでそれで。

本当はHP 2510pか2530pが欲しかったのだが、予算オーバー気味なのと選べるほど弾がなかったので断念。この2機種1.8インチ HDDのモデルもあって、商品名だけではなかなか判別が付かない。HDDはある程度入れ替えできた方がいいので2.5インチモデルが欲しい。現物見ないで買うと失敗しそうだったので秋葉原に出向いてみたのだが残念だ。

入れ替えは、以下のような手順で実施。
[1]
CF-T8のHDDを取り外し、VY14AにUSBで接続してMiniTool Partition Wizardでディスクコピー。

このコピー、120GBにもかかわらず10時間程度かかった。USB接続が遅かったのか、MiniTool側の遅さなのか判断付かないが、VY14Aも開腹してHDDを取り出した上でドライブコピーした方が良かったかもしれない。

[2]
CF-T8を起動してみたら何となく想像してたけどMBR破損("j"とだけ表示されて止まる)。debianのインストールディスクをrescue modeで起動して/dev/sbaにgrubをインストール。

[3]
これで完了かと思ったらネットワークがつながらない。ifconfigしてもeth0が無い。
dmesg見てると、こんなのがある。
udev: renamed network interface eth0 to eth1
これが原因か。

NICのデバイス名(eth0とか)が変わったら? - Practice of Programming
ネットワ-クの基本設定などを確認(Linux版)

を参考に、/etc/udev/rules.d/70-persistent-net.rulesの旧NIC MACアドレスとehe0の紐付けをコメントアウトして再起動したところeth0が復帰した。

修正前の場合でもeth1は居て欲しい気がするのだが、interface周りを調べる時間がない。今回はこれで終わりにする。

作業中に気づいたが、このNICはBroadcom製だった。intelが良かったのだが、致し方なし。

VY14Aについては今のところ大きな不満はないが、HDD(Fujitsu MHZ2120BH)が結構鳴くので安定稼働してきたら結局入れ替えすることになるかも…

2014/08/25(月)HDDコピーメモ

2014/08/25 12:22 PC(全般)
2TB HDD -> 4TB HDD換装でちょっと手間取ったのでメモ。

やりたいことは、2TB HDDにある2TBシングルパーティション(MBR)のデータを、4TB HDDに4TBシングルパーティション(GPT)切ってそこに全部移すこと。

環境はWindows7 64bit SP1。
元のHDDがMBRであり、かつ換装先がパーティションの条件上GPTになることに注意。

最終的な手順は、

1.元の2TBを取り外す
2.KURO-DACHI/CLONE/U3 で、2TB HDDから4TB HDDにコピー
3.4TB HDDを取り付ける。
4.MiniTool Partition Wizard Home Editionで4TB HDDをMBR -> GPT変換
5.同ツールで4TB HDDの2TBパーティションを拡張して4TBに変更
6.セーフモードで再起動
7.4TBパーティション(4TB HDD)のドライブレターを元の2TBパーティション(2TB HDD)と同一のものに変更
8.再起動

1.で取り外す前にドライブレターを開放しておけば、6~7手順は不要かも。

2.ではKURO-DAICHIでコピーした。
コピー速度がかなり速いので取り外して作業できるときは最近これを採用してる。
PCと安物HDDコピーハードどっちが信用できるかというと難しいけど、速度はだいたい後者の勝ち。
昔PC上のHDD間コピーでbit化けしたトラウマがあるのでPCでのファイルコピーをちょっと信用してないのもある。
もちろん取り外して作業ができるのが前提。

・はまりポイント1
MBR->GPT変換の必要性を忘れていて大混乱。
パーティション拡張しようとして、こけたり変な状態になったり。
2TB超だからソフトが対応してないのかとか考えてしまったが、先に変換しておかないとだめなのだった。
当たり前である。

・はまりポイント2
Windowsは取り外したHDDのドライブレターを記憶していて、取り外し後に通常起動するとそのドライブレターを予約状態("次のドライブ文字を割り当てる"の変更先リストに出てこない)にする。
レジストリいじったりいろいろやってみたけど、直し方がわからなかった。
セーフモードで起動すればとりあえずリストに出てくるので、それで。

・悩みポイント
パーティション変更ツールの定番がわからない。
今回は最新のEASEUSとかAOMEIとか試して、MiniTool Partition Wizard Home Editionを使用した。

以下、悩みリスト。

1.見た目が似たようなツールがたくさんある(おそらくエンジンも共通)
2.バージョンアップで機能が追加されるとは限らない。減るケースもある(特に商用版との絡みと制限がややこしい)
3.Unix系の定番(Parted Magicとか)より勝るのか劣るのかよくわからない
4.インストーラが余計なツールを積極的にインストールしてくるものが多い(天下のOracleもやってるとはいえ)

特に私がめんどくさいと思ってるのは2。
ちゃんと進化してくんだったらどっかの段階で商用版買うんだけどね。

今回使用したのは、MiniTool Partition Wizard Home Edition。

現時点では、
○パーソナルユースなら無料で使える
○2TB超対応
○MBR -> GPT変換機能あり
○パーソナルユースの機能制限は比較的緩そう(Dynamic Disk使わない、Serverで起動しない限りほぼフル機能と思う)
○Windows上からGUIで操作できる
○パーティションサイズ拡張は高速だった
○インストーラで変なもの入れる警告はなかった(入れていないかどうかは精査していない)
×GPT変換前にパーティションサイズを4TBにしようとしたら、通ってしまった上にパーティションサイズがマイナスになる変な状態に(バグ?)

良ソフトの気配。

一方、現時点のEASEUSはインストール時にbaiduを入れてこよう(baiduが悪いってんじゃなく)とするあたりでかなり悪印象だし、パーティション拡張はMiniToolよりかなり時間かかりそうな感じだった(あまりに時間かかってたので途中でプロセス止めてHDDコピーしなおした)。

2014/08/12(火)TOMCAT + logbackで、logback.xmlを外出し

アプリケーションサーバ:TOMCAT、ログライブラリ:logbackの組み合わせで、
logback.xmlをwarの外に追い出そうとしたらプチハマリしたメモ。

環境は、
TOMCAT 7.0.54.0
logback 1.1.2

一応できた。ただし、すっきりとは書けない。

Context定義にVirtualWebappLoaderを追加する。
たとえば、WEB-INF以下にlogback.xmlを置いた場合以下のようになる。
<Context>
  <Loader
    className="org.apache.catalina.loader.VirtualWebappLoader"
    virtualClasspath="C:/foo/bar/WEB-INF"
  />
<Context/>
ここで注意。
必要なのがlogback.xmlだけの場合、ファイル名まで書いてやりたいので次のようにしがち。
    virtualClasspath="C:\foo\bar\WEB-INF\logback.xml"
しかしこの場合、VirtualWebappLoader側はlogback.xmlを認識するが、logbackがlogback.xmlを読みにいかない模様。
あくまでディレクトリパスを書く必要がある。

絶対パスなのがいまいちな場合、$tomcat.base or $tomcat.homeが使えるのでそれを使ってなんとか相対パスで書く。
(tomcat.home->catalina.homeかもしれないのでRTFM)。
    virtualClasspath="${tomcat.home}/webapps/foo/bar/WEB-INF"
このどっちもいまいちだと難しい。TOMCATではほかの手が見つからなかった。
アプリケーションサーバを切り替えたほうがいいかもしれない。

アプリケーションルート的な所から相対パスでアクセスしたいという要望はあると思う。

あとはメモ。
virtualClasspathの書き方としては、Windows環境下ではディレクトリ区切り子は"/"でも"\"でもよい。
ディレクトリパス指定時は末尾の区切りはいらない。

Context周りの仕様で怪しいところがあるなら本家ドキュメントで確認。Apache Tomcat 7 Configuration Reference (7.0.55) - The Context Container

Eclipseからプラグイン経由で使う場合、さらにいろいろ留意。

Eclipse+Tomcat Pluginでコンテキスト定義に追加する場合、プロジェクトのプロパティ->Tomcat->全般->その他の情報にLoaderセクションをべたっと貼り付けて、プロジェクト->右クリック->"コンテキスト定義を更新"でよい。

コンテキスト定義をMETA-INF/context.xmlなどで作っていても、現在のEclipseのTomcatプラグインは拾う機能がなさそう。コンテキスト定義更新で%CATALINA_BASE%/conf以下に反映されていないことに注意。META-INF側はconfより優先順位が低く参照されない。


こっから下はおまけ。
動作確認時に%CATALINA_HOME%/conf/logging.propertiesに、ログ出力を追加してTOMCATにログをはかせるようにした。
org.apache.catalina.loader.VirtualWebappLoader.level = ALL
org.apache.catalina.loader.VirtualWebappLoader.directory = ${catalina.base}/logs
なお、Eclipseから起動したTOMCATはcatalina.*.logとかははかないので注意。
ここら辺は"eclipse, tomcat, ログ"とかで検索してほしい。

2014/08/03(日)Acrobat ProのUpdateに失敗する

2014/08/03 14:47 PC(全般)
Acrobat ProのUpdate時に、
アップデートに失敗しました
キー\.xdp\AcroExch.XDPDoc\ShellNew を作成できません。そのキーへの十分なアクセス権を持っているかどうかを確認するか、またはサポート担当者へお問い合わせ下さい。
というメッセージが出て失敗する問題。

環境は、
Windows7 Professional SP1(64bit)
Acrobat Pro 10.1.9

どうも既存のレジストリと衝突している模様。

とりあえず、レジストリエディタで\HKEY_CLASSES_ROOT\.xdpを削除してアップデートしてやると通るようになる。

ただ、アップデート後に該当キーに対してシステム管理者でもアクセス拒否される。この状態が正常かどうか不明。

バックアップをとって、自己責任でよろしく。
OK キャンセル 確認 その他