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 <[email protected]> > 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. > -- Ivan
