October 19, 2010 by huionn
Today I got ClassCastException when lookup RMI stub in local JNDI (same JVM but different WAR) in JBoss. I thought it was due to my mistake. However after much googling and trial & error, the problem still persisted.
Then I read from JBoss forum that ClassCastException can be caused by duplicate class in different JARs. Although this is not the cause in my case, it inspired me to check the classloader of RMI stub and local class. It showed that both classes have different classloader. The classloader of RMI stub is BaseClassLoader for another web application.
Then I started reading about JBoss ClassLoader architecture. Actually, JBoss uses call-by-ref optimization by default. It works if both web applications share common RMI stub class in class loading repository. At the moment, I want each web app to have separate copy of classes (this is going to change when I apply EAR deployment). So I choose the alternative solution – call-by-value. call by value is 10x slower, but this cost is insignificant as there a very little RMI calls.
I believe that to most Java developers, Java classloading is a mystery. But the understanding of it is required to solve <2% of uncommon problems. For example, in Java SE class loading delegation is parent first, but in Java EE class loading delegation is child first.