If the exception is thrown in your own application, one way is to add a debug point there, and check the classloader of the each classloader of the both classes. After that, it will be easy to find what happens.
Hope it helps.

2011/8/26 KHAksnes <khaksnes@gmail.com>
First a little about my environment, I am using Geronimo 2.2.1 on Jetty,
developing a series of web services as annotated Stateless Session Beans.
Behind the scenes I am using JPA extensively, most of the logic are found in
my JPA packages. In addition there are one JAXB package used to define
arguments and return values of my web services.  This has worked quite well
for a year or so. A few weeks ago I had to switch to a new development
machine, when doing so I switched from 32bit vista to 64bit Windows 7, and
in the process I upgraded Eclipse to Indigo. At about the same time we
started introducing CI. Due to the CI integration and Eclipse upgrade I had
to do quite a lot of minor changes in some of my POMs mostly to the better
some of them due to new version of M2E in Indigo some to fix CI builds. I
also split the JAXB stuff out in a separate package.
Quite recently I had to do some minor functional changes, including a very
small and insignificant change in my XSD schema. (Adding one new simple
method to a web service, and adding an extra legal value for an attribute.)
My packages compiles OK. My EAR builds cleanly, but then things starts going
wrong. The EAR won't start due to class loader problems. I get attempted
duplicate class definition message for one of the JAXB classes during start
up. This is not a simple EAR structure problem, the shared jar packages are
installed under lib and the EARs at the top level and the EARs doesn't
contain their own copies of these jars.
I haven't had this kind of problem before and is quite unsure of what to do
next, hoping for some useful hints. I have seen some references to Jetty and
JAXB class loader problems at startup, but they have been related to a race
condition in Jetty's own use of JAXB to parse its configuration data.

It is  a small chance that I have the same problem as these JAXB classes are
used by a couple of timers possibly being executed almost immediately after
starting the EJBs, me being prevented from seeing the problem earlier due to
the slowness of 32bit Vista and our virtual test servers.

View this message in context: http://apache-geronimo.328035.n3.nabble.com/How-to-debug-classloader-problems-tp3286224p3286224.html
Sent from the Users mailing list archive at Nabble.com.