Jenkins 用 Tool Labels Plugin

先日の RAD Studio Plugin に続き、調子に乗って Tool Labels Plugin を公開いたしました。

このプラグインの機能は、インストール済みツールによりノードに動的にラベルを追加するというものです。ツールのインストール有無によりビルドを実行するノードを限定するのが目的で製作しました。

実を言えば、RAD Studio Plugin の新機能として企画していたのですが、他のツールにも使えることに気づいて、急遽 独立したプラグインに仕立てたものなのですけどね。例えば、RAD Studio XE7 に bds15.0 というラベルを付けておくと、インストール済みノードに動的にこのラベルが付くので、ビルドを実行するノードを限定するのに使えるようになる訳です。

便利だと感じたらフィードバックをいただけるとありがたいです。

Java SE 8 の非互換性

まず Java SE 7 の java.lang.refrect.TypeVariable と Java SE 8 の java.lang.refrect.TypeVariable を比べてほしい。簡潔に書けば Java SE 8 で getAnnotatedBounds() が追加されたことが分かるはずである。

このように既存のインターフェースにメソッドが追加された場合、このインターフェースを実装するクラスはそのままでは Java SE 8 でコンパイルできなくなってしまう。通常なら追加されたメソッドの実装を追加すれば解決するのであるが、ここで getAnnotatedBounds() の戻り型 AnnotatedType[] に注目してほしい。java.lang.reflect.AnnotatedType は Java SE 8 で追加されたので、Java SE 7 には存在していない。つまり getAnnotatedBounds() を実装してしまうと Java SE 7 ではもうコンパイルできなくなってしまうのである。何という非互換性だろうか。

本来なら新しいメソッドを追加した別のインターフェースを追加するか、Java SE 7 のクラス実装のままでもコンパイル可能なようにデフォルト メソッドを提供するべきだったのでしょうが、そこまで気が回らなかったんでしょうかねえ。

 

GlassFish 構成の紹介

せっかく Jenkins が復旧したことなので、このサイトで使っている GlassFish の構成を紹介してみようと思います。

まず GlassFish の「ドメイン」には管理サーバーがあるわけですが、これは表に出していません。管理サーバーとは別にクラスター インスタンスと今回新たに追加したスタンドアローン インスタンスがそれぞれ別の java プロセスで動作していています。それぞれのインスタンスには AJP (mod_jk) 対応のリスナーが追加してあり、フロントエンドの Web サーバーから間接的にアクセスするように設定しています。

結局 3 個の Java プロセスが動いているということになるわけですが、運用の勉強のつもりで動かしているクラスターは、実際にクラスターを組めるほどのインスタンス数がないので、将来的にはスタンドアローン インスタンスに一元化してしまうかもしれません。

Jenkins 復旧

GlassFish アップデートで障害発生から止まっていた Alfa.linuxfront.com の Jenkins がようやく復旧しました。

何が問題を起こしていたのかを簡潔に書けば、GlassFish 4.1 のクラスター インスタンスに配置していたために Jenkins初期化に失敗していたということでした。単一のスタンドアローン インスタンスに配置替えをしたことにより初期化に失敗することもなくなり、ひとまず平常運転に戻れそうです。

不思議なのは、前バージョンの GlassFish 4.0 ではクラスター インスタンスでも動いてたってことなんですよね。4.1 で動作が変わったのでしょうか。

GlassFish アップデートで障害発生

このサイトで稼働させてきた GlassFish 4.0 を新しい 4.1 にアップデートしたら Jenkins が動かなってしまいました。

GlassFish 4.0 は 4.1 のスナップショットより不安定だとか話があったので、Update Tool を使って 4.1 にアップデートして起動したら…動かない…あれ?

そんな訳で、コンフィギュレーションをゼロから作り直したり、必要もないのに (1台でw) クラスターにしていたのをシングル サーバーに変えたりとか、試行錯誤してみた結果、WordPress は復旧したものの Jenkins はどうやっても初期化エラーで動かないという問題が解消できませんでした。クラス ローダーの挙動に影響されてるように見えるんですがねえ。

PHP について

どうでも良い話ですが、私は個人的に PHP が嫌いなのです。それが Quercus で WordPress を動かしている一つの理由。

それでも WordPress を使う理由は、PHP 以外で書かれた WordPress に匹敵するソフトウェアが見つけられなかったこと。全くどういうわけか、広く使われている Web アプリケーションの多くが PHP で書かれているので避けては通れない。

避けて通れないなら、別の方法 (Quercus) を使ってやろうというのがせめてもの抵抗であるわけです。

Quercus で動かす WordPress で見つかった問題点 2

Quercus で使うときの問題点はまだあったな。忘れてた。

タイムゾーン設定で Asia/Tokyo を選択すると、それ以降の設定項目が表示されなくなりました。とりあえず UTC+9 に設定して回避したけども、一度この状態になっちゃうと Web からは修復できなくなるので MySQL を直接叩いて直すはめになります。