Re: [S2] - FilterDispatcher and ActionContextCleanup (WW-2240 FileUploadInterceptor causes null pointer exception)
I'm not sure why it's a problem in WL, but I don't think it's a WL
bug. It's more likely that it has something to do with container
dependent handling of requests/threads. I don't remember the exact
order of events, and I don't have time right now to debug it again,
but the bottom line is that the nested filter dispatcher invocation
clears the action context when it's not supposed to do so, unless you
have configured the ActionContextCleanup filter. It might be one of
those cases when things blow up in your face when you least expect it.
This is code I'm not very familiar with, so I may be totally wrong,
and that's why I wanted a second opinion. If anyone wants to debug,
just download WL and the example war in the issue. It should be easy
to reproduce.
Nils-H
On Thu, Feb 21, 2008 at 8:03 AM, Al Sutton [EMAIL PROTECTED] wrote:
Is this only a WebLogic issue (has anyone seen it in another container)?, if
so is it purely a WL 10 issue?, is the problem fixed in WL 10.1? If it's
only a WL issue I think that a temp patch is fine until BEA sort out
whatever is causing it to occur.
As a side note, rather than doing an isInfoEnabled check, wouldn't it be
better to do the following before the loop;
Locale loggingLocale;
if( ActionContext.getContext() == null ) {
loggingLocale = Locale.getDefault();
} else {
loggingLocale = ActionContext.getContext().getLocale();
}
and then in the loop do;
LOG.info(getTextMessage(struts.messages.removing.file, new
Object[]{inputValue, currentFile}, loggingLocale));
My reason for suggesting this is that with the current patch I would guess
that info logging was enabled the NPE would still occurr, so we're basically
saying that WL 10 users can't use info level logging or below, which seems a
bit harsh. It also has the benefit of not having a conditional test in each
loop iteration, which, as a bit of a performance freak, makes me happy.
What do people think?
Al.
- Original Message -
From: Nils-Helge Garli Hegvik [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Tuesday, February 19, 2008 11:30 PM
Subject: Re: [S2] - FilterDispatcher and ActionContextCleanup (WW-2240
FileUploadInterceptor causes null pointer exception)
Since we're getting close to a 2.1.1 release, I thought I should bring
this one up again. I'm still not sure what to do about this issue. I
committed a patch that is a temp work around, but the real issue has
not been resolved.
https://issues.apache.org/struts/browse/WW-2240
Nils-H
On Jan 23, 2008 5:43 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote:
I would really like a second opinion on this issue. Please let me know
if something I wrote was unclear.
Nils-H
On Jan 20, 2008 1:03 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED]
wrote:
Hi!
I've been debugging WW-2240 (had to install WebLogic 10 to reproduce
it) and have seen some strange behavior (at least I think so) in
the ActionContext initialization and cleanup performed by the
FilterDispatcher. The problem is that the cleanup of the ActionContext
(ActionContext.setContext(null)) happens before the
FileUploadInterceptor is finished executing, so when a log statement
in the interceptor tries to access a value in the ActionContext, it
fails with an NPE. I think I've traced it down to this:
In the FilterDispatcher a call to ActionContextCleanUp.cleanUp(req) is
invoked in the finally block. In ActionContextCleanup.cleanUp, the
request is checked for a COUNT request attribute to see if the context
should be cleaned up. And in this case, this attribute is always null,
since it's only set and incremented in ActionContextCleanUp.doFilter
(which in this case is not configured in web.xml). So it seems strange
to me that the FilterDispatcher tries to clean up the context when it
apparently does not keep track of if it should be cleaned or not
(nested invocation)?
Is this an actual bug, or am I just overlooking something?
I could only reproduce this in WebLogic 10. So it's apparently
container dependent how this is handled.
Nils-H
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] - FilterDispatcher and ActionContextCleanup (WW-2240 FileUploadInterceptor causes null pointer exception)
Is this only a WebLogic issue (has anyone seen it in another container)?, if
so is it purely a WL 10 issue?, is the problem fixed in WL 10.1? If it's
only a WL issue I think that a temp patch is fine until BEA sort out
whatever is causing it to occur.
As a side note, rather than doing an isInfoEnabled check, wouldn't it be
better to do the following before the loop;
Locale loggingLocale;
if( ActionContext.getContext() == null ) {
loggingLocale = Locale.getDefault();
} else {
loggingLocale = ActionContext.getContext().getLocale();
}
and then in the loop do;
LOG.info(getTextMessage(struts.messages.removing.file, new
Object[]{inputValue, currentFile}, loggingLocale));
My reason for suggesting this is that with the current patch I would guess
that info logging was enabled the NPE would still occurr, so we're basically
saying that WL 10 users can't use info level logging or below, which seems a
bit harsh. It also has the benefit of not having a conditional test in each
loop iteration, which, as a bit of a performance freak, makes me happy.
What do people think?
Al.
- Original Message -
From: Nils-Helge Garli Hegvik [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Tuesday, February 19, 2008 11:30 PM
Subject: Re: [S2] - FilterDispatcher and ActionContextCleanup (WW-2240
FileUploadInterceptor causes null pointer exception)
Since we're getting close to a 2.1.1 release, I thought I should bring
this one up again. I'm still not sure what to do about this issue. I
committed a patch that is a temp work around, but the real issue has
not been resolved.
https://issues.apache.org/struts/browse/WW-2240
Nils-H
On Jan 23, 2008 5:43 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote:
I would really like a second opinion on this issue. Please let me know
if something I wrote was unclear.
Nils-H
On Jan 20, 2008 1:03 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED]
wrote:
Hi!
I've been debugging WW-2240 (had to install WebLogic 10 to reproduce
it) and have seen some strange behavior (at least I think so) in
the ActionContext initialization and cleanup performed by the
FilterDispatcher. The problem is that the cleanup of the ActionContext
(ActionContext.setContext(null)) happens before the
FileUploadInterceptor is finished executing, so when a log statement
in the interceptor tries to access a value in the ActionContext, it
fails with an NPE. I think I've traced it down to this:
In the FilterDispatcher a call to ActionContextCleanUp.cleanUp(req) is
invoked in the finally block. In ActionContextCleanup.cleanUp, the
request is checked for a COUNT request attribute to see if the context
should be cleaned up. And in this case, this attribute is always null,
since it's only set and incremented in ActionContextCleanUp.doFilter
(which in this case is not configured in web.xml). So it seems strange
to me that the FilterDispatcher tries to clean up the context when it
apparently does not keep track of if it should be cleaned or not
(nested invocation)?
Is this an actual bug, or am I just overlooking something?
I could only reproduce this in WebLogic 10. So it's apparently
container dependent how this is handled.
Nils-H
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] - FilterDispatcher and ActionContextCleanup (WW-2240 FileUploadInterceptor causes null pointer exception)
Since we're getting close to a 2.1.1 release, I thought I should bring this one up again. I'm still not sure what to do about this issue. I committed a patch that is a temp work around, but the real issue has not been resolved. https://issues.apache.org/struts/browse/WW-2240 Nils-H On Jan 23, 2008 5:43 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: I would really like a second opinion on this issue. Please let me know if something I wrote was unclear. Nils-H On Jan 20, 2008 1:03 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Hi! I've been debugging WW-2240 (had to install WebLogic 10 to reproduce it) and have seen some strange behavior (at least I think so) in the ActionContext initialization and cleanup performed by the FilterDispatcher. The problem is that the cleanup of the ActionContext (ActionContext.setContext(null)) happens before the FileUploadInterceptor is finished executing, so when a log statement in the interceptor tries to access a value in the ActionContext, it fails with an NPE. I think I've traced it down to this: In the FilterDispatcher a call to ActionContextCleanUp.cleanUp(req) is invoked in the finally block. In ActionContextCleanup.cleanUp, the request is checked for a COUNT request attribute to see if the context should be cleaned up. And in this case, this attribute is always null, since it's only set and incremented in ActionContextCleanUp.doFilter (which in this case is not configured in web.xml). So it seems strange to me that the FilterDispatcher tries to clean up the context when it apparently does not keep track of if it should be cleaned or not (nested invocation)? Is this an actual bug, or am I just overlooking something? I could only reproduce this in WebLogic 10. So it's apparently container dependent how this is handled. Nils-H - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] - FilterDispatcher and ActionContextCleanup (WW-2240 FileUploadInterceptor causes null pointer exception)
I would really like a second opinion on this issue. Please let me know if something I wrote was unclear. Nils-H On Jan 20, 2008 1:03 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Hi! I've been debugging WW-2240 (had to install WebLogic 10 to reproduce it) and have seen some strange behavior (at least I think so) in the ActionContext initialization and cleanup performed by the FilterDispatcher. The problem is that the cleanup of the ActionContext (ActionContext.setContext(null)) happens before the FileUploadInterceptor is finished executing, so when a log statement in the interceptor tries to access a value in the ActionContext, it fails with an NPE. I think I've traced it down to this: In the FilterDispatcher a call to ActionContextCleanUp.cleanUp(req) is invoked in the finally block. In ActionContextCleanup.cleanUp, the request is checked for a COUNT request attribute to see if the context should be cleaned up. And in this case, this attribute is always null, since it's only set and incremented in ActionContextCleanUp.doFilter (which in this case is not configured in web.xml). So it seems strange to me that the FilterDispatcher tries to clean up the context when it apparently does not keep track of if it should be cleaned or not (nested invocation)? Is this an actual bug, or am I just overlooking something? I could only reproduce this in WebLogic 10. So it's apparently container dependent how this is handled. Nils-H - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] - FilterDispatcher and ActionContextCleanup (WW-2240 FileUploadInterceptor causes null pointer exception)
Hi! I've been debugging WW-2240 (had to install WebLogic 10 to reproduce it) and have seen some strange behavior (at least I think so) in the ActionContext initialization and cleanup performed by the FilterDispatcher. The problem is that the cleanup of the ActionContext (ActionContext.setContext(null)) happens before the FileUploadInterceptor is finished executing, so when a log statement in the interceptor tries to access a value in the ActionContext, it fails with an NPE. I think I've traced it down to this: In the FilterDispatcher a call to ActionContextCleanUp.cleanUp(req) is invoked in the finally block. In ActionContextCleanup.cleanUp, the request is checked for a COUNT request attribute to see if the context should be cleaned up. And in this case, this attribute is always null, since it's only set and incremented in ActionContextCleanUp.doFilter (which in this case is not configured in web.xml). So it seems strange to me that the FilterDispatcher tries to clean up the context when it apparently does not keep track of if it should be cleaned or not (nested invocation)? Is this an actual bug, or am I just overlooking something? I could only reproduce this in WebLogic 10. So it's apparently container dependent how this is handled. Nils-H - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
