Hi Mark,
Jersey does not store anything into ThreadLocal properties
in this case. The only case is if you use the JAXB context to configure
JAXB/JSON and use the natural notation. Then IIRC JAXB uses
some ThreadLocal stuff.
Could you please confirm that is the case?
Thanks,
~Jakub
P.S.Cross-posting also to the JAXB mailing list.
On 03/16/2011 01:53 AM, Mark Petrovic wrote:
> I'm thinking this is a JAXB bug, but I'm not sure.
>
> On Tue, Mar 15, 2011 at 3:06 PM, Mark Petrovic<mspetrovic_at_gmail.com> wrote:
>> Hi. Tomcat 7 has memory leak detection, and I'm seeing these sorts of
>> messages when I redeploy an app that uses a JAXBContext instance as a
>> @Provider:
>>
>> @Provider
>> public class JAXBContextResolver implements ContextResolver<JAXBContext> {
>> ...
>> }
>>
>>
>> Mar 15, 2011 10:23:36 AM org.apache.catalina.loader.WebappClassLoader
>> checkThreadLocalMapForLeaks
>> SEVERE: The web application [/fooapp] created a ThreadLocal with key
>> of type [com.sun.xml.bind.v2.runtime.Coordinator$1] (value
>> [com.sun.xml.bind.v2.runtime.Coordinator$1_at_77198eb6]) and a value of
>> type [java.lang.Object[]] (value [[Ljava.lang.Object;@2ee88bd0]) but
>> failed to remove it when the web application was stopped. Threads are
>> going to be renewed over time to try and avoid a probable memory leak.
>>
>> Is Jersey placing things in a persistent ThreadLocal that perhaps are
>> not being removed when a webapp is redeployed? If yes, how can I
>> manually remove these instances?
>>
>>
>> --
>> Mark
>>
>
>