なんでもブログ

JUnitでテストを行うと、ExceptionInInitializerErrorが発生。

見慣れないExceptionなのでググってみると、下記のブログを発見。
http://blog.goo.ne.jp/evergreen_1978/e/3837fa795bc6a48d333b32692ecd0b44

"実行環境"と"開発環境"のjarの依存関係が一致していないため起こった"
と推測しました。

これを見てピンと来た。
JUnit実行前に、AES256を使用できるようにするために、Javaのポリシーを置き換えました。
しかも、Java8用のポリシーをJava6、Java7に上書き保存・・・。
そりゃダメだ（＾＾；

正しいバージョンのポリシーで保存しなおし、Exceptionは発生しなくなりました。

AES256を使用するには下記サイトを参照。
Java6～8のポリシーをダウンロードする為のリンク先も記載されています。
https://qiita.com/mizuki_takahashi/items/cc26a7fd51aa04396e92

Webシステムの開発を行い、初めてGroovy + Gebで画面のテストケースを作成。
その際、JavaScriptの確認ダイアログ(confirm)を表示し、OKを押す処理にハマったのでメモ。

勘違いして下記のように間違った記述を行ってました。

（誤）
// ボタンをクリックし、確認ダイアログを表示する
$('.confirmBtn').click()
withConfirm(true) {
  // 確認ダイアログでOKが押された後の確認
  aseert (省略)
}

これだとダイアログがないと怒られる。
java.lang.AssertionError: no browser confirm() was raised

正しくは下記のように、withConfirm内で確認ダイアログを表示するイベントを実行する必要がありました。

（正）
withConfirm(true) {
  // ボタンをクリックし、確認ダイアログを表示する
  $('.confirmBtn').click()
}

// 確認ダイアログでOKが押された後の確認
aseert (省略)

作成しているWebアプリケーションで、Cookieに使っちゃいけない名前が使われてるぞ！！というエラーが発生。
java.lang.IllegalArgumentException: Cookie name "Path" is a reserved token

こちらの記事（HTTP通信でのセッションIDのCookieにSecure属性を付ける）で書いたように、
セッションIDにSecure属性を持たせるようにした為、DefaultCookieSerializerでエラーになっていました。
調べてみると、org.springframework.session.web.http.DefaultCookieSerializer.readCookieValues()で、HttpServletRequest.getCookies()を実行していました。
CookieのKeyに「Path」や「Domain」等の予約語が使われていると、HttpServletRequest.getCookies()で上記のエラーが発生するようです。

対策方法をググってみましたが、そもそもCookieに予約語を指定しているのが問題というわけで解決方法見つからず。
しかし、エラーになられてもウザいので対策することに。

【対応方法】

• DefaultCookieSerializerの中身を丸っとパクったクラスAを作成
• クラスA.readCookieValues()でgetCookies()を実行している部分の例外をキャッチ
• 例外が発生した場合はHttpServletRequest.getHeader("Cookie")で、ヘッダー内のクッキー情報を丸っと取得
• 丸っと取得したクッキー文字列を「;」と「=」でsplitして自前でクッキーを取得する処理を実装　※ヘッダーは「c1=xxx; c2=xxx;」という感じになっているので、Keyの方はtrim()も実施
• DefaultCookieSerializerの代わりにクラスAをnewして使用する

これで、不正な名前のCookieがセットされたリクエストでも正常に動くようになりました。

戻り値がStringで実装されているSpringのControllerを修正。
その際、別Controllerへフォワードする必要があった。

今までは、ModelAndViewを使ってリダイレクト、フォワードを実現していたので、戻り値がStringの場合、どうやってフォワードさせればいいんだ？となり調べてみる。

当然ながら、戻り値がStringのControllerでもリダイレクト、フォワードさせる方法はあって一安心。
分かりやすく纏めてくれている下記サイトを参考
https://qiita.com/tag1216/items/3680b92cf96eb5a170f0

SLF4J、logbackを使用し、別々のファイルに出力するLoggerを使用する必要があったので調査。
簡単に実現できました。

・logback.xmlに異なるファイルを定義したappenderを定義する
・Loggerを使いたいクラスで、使いたい方のLoggerを宣言するのみ。両方を同時に宣言して各処理で使い分けてもよし。

【logback.xml】※一部のみ抜粋
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <encoder>
            <pattern>%msg%n</pattern>　※パターンは好きなように定義
        </encoder>
        <file>/log/test.log</file>
    </appender>

    <appender name="FILE_2" class="ch.qos.logback.core.FileAppender">
        <encoder>
            <pattern>%msg%n</pattern>
        </encoder>
        <file>/log/test2.log</file>
    </appender>

    <logger name="jp.test" level="DEBUG">
        <appender-ref ref="FILE" />
    </logger>

    <logger name="TestLog" level="DEBUG">
        <appender-ref ref="FILE_2" />
    </logger>

【Java】
// test.logに出力する為のLogger
private static Logger logger = LoggerFactory.getLogger(Test.class);

// test2.logに出力する為のLogger
private static Logger logger2 = LoggerFactory.getLogger("TestLog");