File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Threads and Synchronization and the fly likes Unexpected object type returned from InheritableThreadLocal.get method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Unexpected object type returned from InheritableThreadLocal.get method" Watch "Unexpected object type returned from InheritableThreadLocal.get method" New topic

Unexpected object type returned from InheritableThreadLocal.get method

David Howie

Joined: Jan 26, 2010
Posts: 11
I have a class named UserHelper (source code included below) that puts a User object on the thread using the java.lang.InheritableThreadLocal API. The UserHelper class is part of a common Enterprise level JAR that is used by many applications throughout our company. The UserHelper class has been in use for the past 3+ years. Just this week one application reported a problem where they were receiving a java.lang.ClassCastException at line 20 of the UserHelper. The ClassCastException occurred attempting to cast from org.apache.log4j.Logger to

As you can see from the UserHelper.setUserOnThread method, only objects of type User can be set onto the thread by the helper class. The UserHelper.setUserOnThread method is invoked from a UserFilter class, which is an implementation of javax.servlet.Filter interface. The stack trace shown above is only a partial stack trace, the complete stack trace does show the UserFilter in the stack.

This is the first and only time a problem has been reported with the ThreadLocal implementation within our Enterprise APIs. Thus far the problem appears to be sporadic. It occurred on one JVM instance in the cluster, in which case they shutdown the JVM instance and restarted, then a day later it occurred on the second JVM instance in the cluster.

Our runtime environment is WebSphere Application Server v7.0.

I have no idea how our UserHelper implementation can be returning a Log4j Logger instance. Does anyone have an idea as to how such a thing could happen? Based upon my understanding of ThreadLocal implementations I believe our implementation is correct/appropriate. Do I have an improper ThreadLocal implementation?


I agree. Here's the link:
subject: Unexpected object type returned from InheritableThreadLocal.get method