[
https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44828#action_44828
]
Torsten Krah commented on WW-2523:
----------------------------------
Some more details:
At init level all is fine.
FilterDispatcher and Jsr168 got its own dispatcher Instance.
But at the first Request it fails here:
protected HttpServletRequest
prepareDispatcherAndWrapRequest(HttpServletRequest request, HttpServletResponse
response) throws ServletException {
Dispatcher du = Dispatcher.getInstance();
// Prepare and wrap the request if the cleanup filter hasn't already,
cleanup filter should be
// configured first before struts2 dispatcher filter, hence when its
cleanup filter's turn,
// static instance of Dispatcher should be null.
if (du == null) {
Dispatcher.setInstance(dispatcher);
// prepare the request no matter what - this ensures that the
proper character encoding
// is used before invoking the mapper (see WW-9127)
dispatcher.prepare(request, response);
} else {
dispatcher = du;
}
At init time Dispatcher du = Dispatcher.getInstance() is null, so the
dispatcher instance is used which was created before and gets set to the
instance var.
But at first request time Dispatcher.getInstance(), called in FilterDispatcher
not the Jsr168 one, is returning the actual instance which was created by the
Jsr168 Dispatcher - i don't know why but thats what the debugger told.
Both Dispatchers are working with the same instance and all is working fine -
but only until destroy is called, because both modify the same instance, which
must fail if it is done a second time.
The other instance which is dangeling around gets not cleaned up and the app
fails do undeploy.
The only thing i am missing is - hm i need to read more about those
ThreadLocals - why getInstance does deliver the same instance ...
> 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
>
>
> 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.
