きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

マニフェスト属性でワーニング

フレームワークをやってると色々な問い合わせを受ける。


そんなこんなで、今日は大変地味な作業をコツコツ繰り返して切り分けを行った。


WebSphereの共用ライブラリがいくつかあって、インストール済みオプションパッケージのマニフェスト属性がどうのこうのでオーバーライドしましたと、SystemOut.logにワーニングが出ている。


そんなことは9ヶ月前から知っている。一部の人を除いて気にも止めてなかったようだ。僕は「誰かが良しとしている可能性」を考えて何もしなかったが、なんか最近偉い人たちに指摘されたんだとか。ワーニングどころか、エラーも出てたから仕方ないかもね。気付けるようになってください、と。


どのライブラリが、どのライブラリのマニフェスト属性をどうのこうのでオーバーライドという情報はあっても、どのJarがという情報はない。IBMに是非とも改善してほしい。


だから何十個もあるJarを共用ライブラリに登録してはサーバ再起動の手順を繰り返した。


40回は再起動したと思う。


たくさんあるJarのうち、使ってるcommonsのなかの9つのJarで起こることが分かった。

また、Extension-nameとImplementation-version(だったかな?)の両方が書かれているという点が共通点のようだ。


「オプションパッケージのバージョン管理」の「Java Plug-inの更新規則」が関係していそうな感じだった。


セルに定義してることが関係するかは特に切り分けを行ってない。
セルに定義されたいくつかの共用ライブラリに重複して登録されているJar、そして先ほどのマニフェスト属性にマッチした場合にワーニングになってるようだ。


マニフェスト仕様はほとんど知らない。くわしく書こうと思ったことがない。知らなくても知らないなりに切り分けを出来たつもり。


重複して登録されてないならワーニングは出ない。じゃあ、IBMに聞いてよ、と投げ出した。
あるライブラリが別のライブラリのマニフェスト属性に干渉されるというのは如何な仕様だろう。。。


これくらいのことまでは切り分ける気概を持って欲しいよな。
まあ、誰もが自分と同じでは無いと思うようにしたいのだが、自分だって発展途上のJava屋なんだし、周りにエキスパート性を求めたくもなるのもまた事実だ。



別の問い合わせで、スタックエレメントが0件配列で、ArrayIndexOutOfBoundsExceptionが起きてしまったというものがあった。
それを聞いた時に、0件で来る場合もあるというのはすぐに思い出した。どうしようもないね。質問した人もJavaAPIを読んでいてその事は把握されていた。仕様なんだから仕方ないが、お目にかかるのは初めてだ。障害時にこういう確認を怠らない人を好ましく思う。配列サイズ確認して、欲しい情報が取れない場合の特殊な処理をするしかないさと、相互に納得して終り。ちゃんと調べてる人と話せば数分で終わる話さ。あとはやるだけさ。


僕というオプションが付いてる点で、いいフレームワークを採用したと言って貰えるのは嬉しい事だが、いつまでも今の部署に居ると思わないでね。。。