Thanks for your help with this Andreas I put a bunch of debug statements in various places and found the WebappClassLoader was being used consistently throughout.
I still don't understand what was happening in this SQLException case, but I did end up finding my problem(s) stem from the use of a singleton class in the legacy code I am using that is effectively thwarting what I want to do anyway. Thanks again, charles On Jan 25, 2010, at 4:36 PM, Andreas Veithen wrote: > On Mon, Jan 25, 2010 at 22:15, Charles Galpin <[email protected]> wrote: >> Hi Andreas >> >> I tried setting the TCCL to both the class loader of the service context as >> well as the service group context before starting the threaD, but still no >> change. I guess this leaves me with a couple of questions. >> >> 1. Do subsequent threads spawned inherit the same TCCL? I'm pretty sure >> other threads are spawned by this thread which then go on to do the work. > > I think that the constructor of java.lang.Thread takes over the TCCL > from the current thread. The Javadoc of java.lang.Thread should give a > detailed explanation of this. > >> 2. How can I tell what class loader is being used? Just log whatever >> this.getClassLoader() returns anywhere I care? > > Thread.currentThread().getContextClassLoader() (not to be confused > with Class#getClassLoader()) > >> 3. Is init perhaps the wrong place to be firing this off? I originally tried >> in the startUp method but iirc member variables initialized here were not >> retained when the service methods were invoked. > > Unfortunately I'm not familiar enough with the lifecycle methods to > answer that question.
