log4j 1.2 の圧縮指定について

Log4jの記事をちらちら見てますが、日本語のページでは圧縮指定に関する記事は大体XMLを

利用したものしか載っていないので少し探してみた。

以下は英語ですが、圧縮設定方法が書いてある。

log4j 1.2.15以降で利用可能みたいです。

I'm trying to get org.apache.log4j.rolling.RollingFileAppender from the log4j extras companion working, since the documentation suggests this is best for production environments.

I have both the main log4J library (log4j-1.2.15.jar) and the log4j extras library (apache-log4j-extras-1.1.jar) on the classpath.

I have the following configuration for the appender in the log4j.properties file:

### SOAP Request Appender
log4j.appender.request=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.request.File=SOAPmessages.log
log4j.appender.request.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.request.RollingPolicy.ActiveFileName =SOAPmessages-%d.log
log4j.appender.request.RollingPolicy.FileNamePattern=SOAPmessages-%d.log.zip
log4j.appender.request.layout = org.apache.log4j.PatternLayout
log4j.appender.request.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

参考：http://stackoverflow.com/questions/5117758/configuring-rollingfileappender-in-log4j

ログなんて何かあった時にしか見ない運用の場合は、圧縮しない理由なんかないんじゃないかと

思います。

なぜ、ローテーションは勝手に圧縮する機能にはなってくれないのだろうか。

CalendarContract を利用したイベントのタイムゾーンについて

取得したイベントのタイムゾーンが頭のなかで整理できなかったので書きだしてみる。

終日のイベントを取り出したところ、タイムゾーンはUTCだった。

日時データは 開始はイベント当日の09:00。そして、終了日時は、次の日の 09:00だった。

Andoroid のリファレンスには、書き込む際、終日のイベントはUTCで記載しなければならない。と書かれている。

If allDay is set to 1 eventTimezone must be TIMEZONE_UTC and the time must correspond to a midnight boundary.

次に、時間指定のイベントを取得。

タイムゾーンは Asia/Tokyo。イベントの日時はJSTでカレンダー記載通りに取得できている。

Googleカレンダーでは、終日は朝9時から次の日の9時までということなんだろうか。

しかし、なんで書き込みがUTCなんだろう・・・。

終日データの9:00ってどこから来るのだろうか。
カレンダーを記載するときに、終日。とした場合には、UTCで記載する。
多分この時、UTC時刻で00:00～次の日の00:00って書くんだろうな。

それで、取り出すときに、UTCで00:00だから・・・　+9で、9:00となる？
もしそうなら。。。格納するときもタイムゾーン指定でいいんじゃないかな・・とおもったり思わなかったり。

UTCから + の方にタイムゾーンがある場合、 UTCで当日の00:00を指せば、UTCと同じ日付になるけど　- のタイムゾーンだったら。。UTCで00:00ってことは前日になってしまうのでは？

それとも、UTCの00:00を書き込むのが間違いで、JSTの00:00をUTCに変換して格納するとか？
そしたらGoogleカレンダーの作りこみに問題があることに。。。
そんなわけはないだろうと思う。。

java.util.Dateの仕様の勘違いかな。（私の）
Date.getTime()はUTCの経過時刻を返却する仕組みとなっている。
Dateインスタンス生成のときは、GMTの経過時刻を渡す仕組み。
当然、気を利かせて現在のロケールに変換してくれるのだから、UTCで経過時刻を渡せば、
+9してくれるので、00:00ではなく、09:00となる。

こうやって考えると、納得。少しスッキリしたかも。


勝手に納得してても、あとで忘れるのでメモ。


■整理できたこと

• java.util.Date は UTC を基準とした日付を扱うクラス。ただし、自動でJavaVMの動作するタイムゾーンに合わせるので、JSTに変換される。
• CalendarContractで取得するイベントには次の2種類がある。
• 時間指定のイベント：格納するデータはJavaVMの動作するTimeZone。従って日本ではJSTとなる。
• 終日のイベント：格納するデータはUTCで時刻を指定する必要がある。

■今日、混乱していたこと

• 終日のイベントの日付を java.util.Date クラスに渡したところ、 +9時間 で表示された。原因はUTCの00:00時刻を渡したため、JSTに変換された。UTCを渡すつもりなら Timezoneのオフセットを考慮する必要がある(TimeZone#getRawOffset()など)。

間違っていなければいいんだけど・・・

AndroidのCursorLoaderのコンストラクタ引数

用語が頭のなかで結びつかないので、知っている用語に置き換えてみる。

public CursorLoader (Context context, Uri uri, String[] projection, String selection, String[] selectionArgs, StringsortOrder)

※参考：
http://developer.android.com/reference/android/content/CursorLoader.html#CursorLoader(android.content.Context, android.net.Uri, java.lang.String[], java.lang.String, java.lang.String[], java.lang.String)

• Context ：　知っているもの該当なし。Activityを渡す。
• Uri　：　接続先
• projection　：　SQLのカラム指定
• selection　：　SQLのWHERE句
• selectionArgs　：　selectionに?を使った場合に、指定する(SQLのPreparedStatmentみたいな使い方）
• sortOder　：　ソート順

置き換えてみたけど、全部ここに書いてあった。。。

http://developer.android.com/reference/android/content/ContentResolver.html#query(android.net.Uri, java.lang.String[], java.lang.String, java.lang.String[], java.lang.String)

汚い日本語に変換しただけでした。