Thursday, May 17, 2007

Classpath conflicts

One problem kept bugging me for three weeks. It was quite irrational - I couldn't extend the functionality of the application, because changes in services (that were EJB3 session beans) were not visible. The problem occurred when deploying to embedded OC4J, but, surprisingly, not when deploying to OC4J standalone...

After getting lots of JBO-25221 (method not supported) and java.lang.NoSuchMethodError I thought I would investigate the class used at runtime. I found that the method that should be there wasn't there at runtime. So I decided to find out where did the class come from. Bertrand Delacretaz has an example of checking when was a Java class compiled. Small modifications to his example and the mysterious class is unmasked:

MyClass.class.getResource( "MyClass.class" ).openConnection().getURL().toString()

I was shocked when I saw the output - it turned out that another project that should have a small 2-class jar in my application had packed also a bunch of classes from the same model. The model was referenced by both projects as a dependency and the deployment profile had a magic checkbox selected:

That resulted in a silent classpath conflict I was not aware of... Finally, the problem is gone :)

1 comment:

Anonymous said...

RpgQed [url=]MCM iphoneケース[/url] WteSmk MowNnd [url=]MCM バッグ[/url] XxiOat TwvTxn [url=]MCM キーケース[/url] LlvJtt ApfFxs [url=]MCM 長財布[/url] HaaMps DkwPuc [url=]MCM[/url] AppOvr YdzAez IcwLmt [url=]クロエ アクセサリー[/url] YckK WjmKD [url=]トゥミ[/url] EgnDfI OflDdSV [url=]TUMI 26108[/url] FgfOoz [url=]MCM 店舗[/url] OuxXxw [url=]MCM 通販[/url]