geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: How to debug classloader problems
Date Fri, 26 Aug 2011 09:17:37 GMT
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 <>

> 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:
> Sent from the Users mailing list archive at


View raw message