You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Nils-Helge Garli (JIRA)" <ji...@apache.org> on 2008/03/02 12:28:07 UTC
[jira] Created: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
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
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.
[jira] Updated: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nils-Helge Garli updated WW-2523:
---------------------------------
Affects Version/s: 2.0.11
2.1.0
> 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46118#action_46118 ]
Nils-Helge Garli commented on WW-2523:
--------------------------------------
This might be related to https://issues.apache.org/bugzilla/show_bug.cgi?id=37956
>From reading that, it seems there's a system property 'org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES' that controls this behaviour. Try setting it to "false" and see if that makes any difference.
> 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: FilterDispatcher.diff, 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44827#action_44827 ]
Torsten Krah commented on WW-2523:
----------------------------------
Could this be raised to blocker priority please?
Fixing this in future versions is really a no go because portlet spec v 1.0 (struts 2.0.11.2 implements) does require to use servlets to deliver resources like images, css or other resource stuff.
You can use FilterDispatcher and Jsr168Dispatcher and its working - but only until you want to stop - restart or redeploy your webapp - the container get stuck because the app cannot be undeployed.
This is more than a major problem because the complete container (and in a portlet environment there you got many other apps than your own providing portlets) needs to be killed and "restarted".
> 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46117#action_46117 ]
Nils-Helge Garli commented on WW-2523:
--------------------------------------
It's still beyond my understanding how the 'instance' thread-local variable suddenly turns null... I have tried doing a null check, but aparently the 'dispatcherListeners' static variable is also suddenly null. So for some reason, the static fields of the class are set to null somewhere... I'm guessing there's some sort of cleanup happening in the container that causes this.
> 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: FilterDispatcher.diff, 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated WW-2523:
-----------------------------
Attachment: stackTrace_ok.txt
StackTrace ok.
> 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44555#action_44555 ]
Torsten Krah commented on WW-2523:
----------------------------------
This is a issue to with Pluto 1.1.5 and e.g. Tomcat 6.0.13.
I am facing this problem too on JBoss (4.0.5, Tomcat 5.5.20, Liferay 5.x).
> 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.
[jira] Issue Comment Edited: (WW-2523) NPE in dispatcher cleanup
when FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44555#action_44555 ]
tkrah edited comment on WW-2523 at 10/8/08 1:15 AM:
-----------------------------------------------------------
This is a issue to with Pluto 1.1.5 and e.g. Tomcat 6.0.13 and Pluto 1.1.6 with Tomcat 6.0.18.
I am facing this problem too on JBoss (4.0.5, Tomcat 5.5.20, Liferay 5.x).
Version 2.0.11.2 (latest stable Release) is affected too.
I think this is a critical flaw as you cannot undeploy or redeploy the webapp and are forced to restart the container every time.
Imho this should be fixed in 2.0 branch too.
was (Author: tkrah):
This is a issue to with Pluto 1.1.5 and e.g. Tomcat 6.0.13 and Pluto 1.1.6 with Tomcat 6.0.18.
I am facing this problem too on JBoss (4.0.5, Tomcat 5.5.20, Liferay 5.x).
> 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.
[jira] Updated: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated WW-2523:
-----------------------------
Attachment: FilterDispatcher.diff
Workaround.
If an IllegalStateException is thrown, catch it because the Jsr168 Dispatcher has already cleaned things up (but log it).
In this case the private variable initialDispatcher holding a reference to the dispatcher which was created through init() method needs to be cleaned up.
More than a hack than a real fix, but i am not a struts2 source code hacker. It solves the container problem and i can redeploy, restart and stop my webapp / container without those annoying need to "kill" the whole thing.
It may have side effects, but i did not have found anyone yet.
Comments appreciated.
> 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: FilterDispatcher.diff, 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46119#action_46119 ]
Nils-Helge Garli commented on WW-2523:
--------------------------------------
I downloaded Jboss Portal 2.7.2 and tested the system property there. Without setting it, I experienced the same error. But when setting it to false, I no longer got the NPE.
> 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: FilterDispatcher.diff, 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46116#action_46116 ]
Nils-Helge Garli commented on WW-2523:
--------------------------------------
I can only reproduce the NPE in JBoss portal. Pluto seems to undeploy without problems.
> 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: FilterDispatcher.diff, 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44843#action_44843 ]
Nils-Helge Garli commented on WW-2523:
--------------------------------------
I think the best would be if the FilterDispatcher and the Jsr168Dispatcher had it's own actual instance of the Dispatcher. I'm not sure how easy that is to achieve though.
> 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: FilterDispatcher.diff, 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44849#action_44849 ]
Torsten Krah commented on WW-2523:
----------------------------------
Yes this would be the best idea. JBoss is doing undeployment first for FilterDispatcher, so you have to patch Jsr168 one too ... that can't be the right solution.
However i don't know how to patch both so everyone got its own actual instance, if someone can provide me with some more details how it might be done, i might be able to write a patch.
> 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: FilterDispatcher.diff, 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.
[jira] Issue Comment Edited: (WW-2523) NPE in dispatcher cleanup
when FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44555#action_44555 ]
tkrah edited comment on WW-2523 at 8/13/08 4:47 AM:
-----------------------------------------------------------
This is a issue to with Pluto 1.1.5 and e.g. Tomcat 6.0.13 and Pluto 1.1.6 with Tomcat 6.0.18.
I am facing this problem too on JBoss (4.0.5, Tomcat 5.5.20, Liferay 5.x).
was (Author: tkrah):
This is a issue to with Pluto 1.1.5 and e.g. Tomcat 6.0.13.
I am facing this problem too on JBoss (4.0.5, Tomcat 5.5.20, Liferay 5.x).
> 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.
[jira] Updated: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Torsten Krah updated WW-2523:
-----------------------------
Attachment: stackTrace_failure.txt
Failure Trace.
> 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.
[jira] Commented: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Torsten Krah (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (WW-2523) NPE in dispatcher cleanup when
FilterDispatcher is used in a portlet
Posted by "Nils-Helge Garli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nils-Helge Garli resolved WW-2523.
----------------------------------
Resolution: Won't Fix
Aparently, this is caused by Tomcat aggressively setting static fields to null when the context is stopped. This behaviour can be configured with the org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES system property. Setting it to 'false' prevents this error (-Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false).
> 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: FilterDispatcher.diff, 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.