読者です 読者をやめる 読者になる 読者になる

大規模開発における、NoSuchMethodException

NoSuchMethodErrorだったかも。

今日(昨日?)あったこと。


現在、外部結合試験(?)中のソースを修正することになりました。
修正内容としては、JavaBeans?(ValueObjectとかDTOとか呼ばれる、Getter,Setterを持つクラス)に、
インスタンスフィールドを追加し、Getter,Setterも追加する。
んで、EJB内でDB読んで、Setterで値を入れて、条件によっては値を変更して、Getterで読みにいって、DBに再度書く。


フツーに、修正して、単体テストして、内部結合環境で疎通してもらって、外部結合環境にリリースしてもらいました。
で、その環境でテストしてもらったところ、NoSuchMethodExceptionが発生。
Setterが見つからないらしい。
でも、コンパイルは通ったらしい。


・・・?
意味不明。で、リリースが正しく行われているかとか、それ以前にちゃんと修正したものを提出しているかとか、いろいろ調べたけど、ちゃんとリリースされているらしい。


諦めきれずに、実際に環境にデプロイされているEARファイルを頂いてきて、解凍。
んで、出てきたJARを全部Eclipseに入れて、ビルドパスに通しました。
コンパイラが既に入っていたので、修正したクラスを逆コンパイルしても、ちゃんと修正された物が入ってる。
ちゃんとリリースされていることが確認できたわけなんだけど、例外の原因が不明。


で、感のいい人ならここまでしなくても分かったのかもしれないけど、ここでようやく気づく。
Ctrl+Shift+Tで、クラス検索。
修正したBeanを検索したところ、2つある。
片方は自分が修正したもので、追加したGetter,Setterがちゃんと存在している。
で、もう片方は、追加する前の状態。


ナニコレ?

で、思い出したのが、このクラス、外部の部品とのインターフェースになっておりました。
そのため、その部品をコンパイルするためにそのBeanが必要。
だからコピーされてたらしい。(ってか、知らされてないし
で、クラスロードの際に、その部品内のBeanの方が優先され、コンパイルは通るけど、メソッドが見つからないという状態。
無事原因がわかってめでたしめでたし。


※ただし、対応方法が、「外部の部品の方にも同様のGetter,Setterを追加する」でした。
なんだか腑に落ちない。
まずもって、なんで部品のインターフェースオブジェクトが、部品を呼ぶ側に定義されてるんだろう・・・
まぁ、それを提案されて、却下出来なかった私も悪いんだけど・・・