リスナーポートとアクティベーションスペックの切り替えに失敗（バイディングのマージにご用心）
アプリケーションを「更新」で置き換えると発生するのだと思う。
ログメッセージには、ibm-ejb-jar-bnd.xmlの
resource-refだとかresource-env-refだとか3種類くらいのうちからなんか書けという感じ。
僕は確かにejb-jar.xmlやibm-ejb-jar-bnd.xmlが過去に動いていたと言われている内容で、
それがアクティベーションスペックで動かすつもりのものであることを確認しとるので、
そんな物が何故求められるのか分からない。
ただ、アプリケーションをインストールするにあたり、
目の前で再現された手順は「更新」によるインストールである点が稀有なだけか。
まずおかしいと感じたのは果たしてそこだろうか？
いや、違うなー。
ログメッセージに出てくるXMLの行番号と文字列位置についての情報を見て、
その行番号が
この瞬間に自分はxmlが違うという可能性が頭に浮かんでいたはずなのに、
とりあえず再現手順において簡略な画面遷移を見守った感じ。
ただ見守っただけなんだけど、その時、頭に浮かんでいたのは、
「果たして詳細な設定手順で進めたら、リスナーポートかアクティベーションスペックかのラジオボタンやテキストボックスに、どのような情報が埋め込まれて表示されるのだろうか」という妄想。（こういうところが宇宙人かも）
次に僕が取った行動は管理コンソールからのEARエクスポートである。
それを解凍して、xmlを見たわけだ。
そこには書いてあるはずのないリスナーポートの設定が混ざっていた。
どういう理屈でいつそこに混ざったのかは知らない。
事件はローカル端末で起きてるんじゃない、デプロイ中に起きてるんだ。
事実確認っつーのは可能な限り発生時点に近い資材を見ることが大事。
念のため、インストール直前のEARも見る。
うむ、やはり無いはずのものが増えてる。
行番号の不思議は不思議ではなくなった。
では、もうひとつの妄想は、仮説に変わる。
仮説はこうだ。
「あのページでは、古いリスナーポートのバインディングも、新しいアクティベーションスペックのバインディングも表示される。」
「更新」において詳細な設定手順を踏む。
そしてはそれは証明された。
次に要らないリスナーポートのバインディング情報を消して、結果期待通りに動くに至る。
そして今、自分がどのように考えてどのように確認していったかを振りかえっているところ。
そしてオフィシャルドキュメントの確認が抜けているので探してるところ。
コンソールを使用したエンタープライズ・アプリケーションの更新
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/trun_app_upgrade_console.html
「インストールのステップには、新規バージョンと旧バージョンのバインディング情報のマージが含まれるという点に注意してください。」という部分があるので、きっとこれだ。
オフィシャルドキュメントにもそれっぽい記述が見つけられた。
「更新」なんてホットデプロイ操作はオイラは正式な操作だと思ってないので、問い合わせる気にもならない。
