[
https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44832#action_44832
]
Torsten Krah commented on WW-2523:
----------------------------------
Look at the failure stackTrace.
serviceAction on the Jsr168Dispatchter gots invoked.
Looking at this method it reads like this:
Dispatcher.setInstance(dispatcherUtils);
So the actual thread local gets overwritten with the local value of the
Jsr168Dispatcher everytime.
Later at the StackTrace look at prepareDispatcherAndWrapRequest of
FilterDispatcher.
There Dispatcher.getInstance() is used to get the actual ThreadLocal. Doing
this the first time this return null and the local FilterDispatcher dispatcher
value is used and ThreadLocal is set.
The snd time this is done, Jsr168 overwrites the actual ThreadLocal value and
the reference to the one created by the FilterDispatcher is lost.
Maybe someone can confirm this? Maybe i am wrong but thats what it looks to me.
> NPE in dispatcher cleanup when FilterDispatcher is used in a portlet
> --------------------------------------------------------------------
>
> Key: WW-2523
> URL: https://issues.apache.org/struts/browse/WW-2523
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter, Plugin - Portlet
> Affects Versions: 2.0.11, 2.1.0
> Environment: JBoss Portal 2.6.4, Struts 2.1.1
> Reporter: Nils-Helge Garli
> Fix For: Future
>
> Attachments: stackTrace_failure.txt, stackTrace_ok.txt
>
>
> When the FilterDispatcher is configured in web.xml, it does cleanup first,
> then JSR168Dispatcher does cleanup, and for some reason, the ThreadLocal
> variable (the actual ThreadLocal variable, not the value it contain) is null.
> I don't know if this is an issue only in JBoss.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
