You are the Scott Oaks at Oracle, right? If so, let's continue the
conversation/debugging directly for the moment until we get more
detail. I can create a patched jar for you that will log the exception
instead of throwing the fault -- but unfortunately I am not back in the
office until Tuesday. If you want to get to this sooner, build off the
2.0.0 trunk (its on a branch now) -- merely change the offending line to
use the local data member referencing the portletContext. There should
either be a data member mPortletContext or mPortletConfig (I don't have
access to the code at the moment). If mPortletContext use
mPortletContext.log if mPortletConfig use
mPortletConfig.getPortletContext().log. This is all I will do you
anyway ...
-Mike-
On 6/10/2011 12:46 PM, Scott Oaks (JIRA) wrote:
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047398#comment-13047398
]
Scott Oaks commented on PORTLETBRIDGE-214:
------------------------------------------
Unfortunately, the testbed in question is production-mode; it is a little hard
to get access. I will see what we can do -- if there is something we can catch
after the fact it works better (e.g. I expect that lots of things call
FacesContext.release() so we can't just generally try and trace that; the bug
may happen once a day on a moderately-used server). If we knew the underlying
exception that triggered the bug, it would likely help, so maybe as a first
step we can just fix the NPE issue in the exception handler and see what
information that gets us as to what triggers the release.
I do see that the doFacesRequest(RenderRequest request, RenderResponse
response) reacquires the context in the exception clause (where
doFacesRequest(ResourceRequest... doesn't). So I guess you are saying that the
premature release in this case didn't come from the renderRedirect() method as
I thought it must have, because that would have been a different entry point?
That is certainly possible; I should have made clear that I was just looking
for possible explanations at that point, and that seemed a likely one to me,
though I don't have an understanding of what is actually going on.
BridgeImpl incorrectly cleans up after exceptions; retains contexts
-------------------------------------------------------------------
Key: PORTLETBRIDGE-214
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-214
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0
Reporter: Scott Oaks
Assignee: Michael Freedman
Attachments: stack.txt
The exception handling of BridgeImpl.doFacesRequest() is incorrect, which leads
to contexts not being released after an exception.
When an exception is thrown to the doFacesRequest() method, it ends up in this
code:
try {
...
} catch (Exception e) {
...
context.getExternalContext().log("Exception thrown in
doFacesRequest:resource", e); // line 1168
...
} finally {
...
context.release();
...
}
The first problem is that whatever error is getting thrown to us is lost
because line 1168 is generated a NullPointerException from
context.getExternalContext().log(). So that NPE gets thrown from the exception
block and the original, actual root-cause, exception is lost.
The reason that this code fails is that context.getExternalContext() returns
null -- the processing has been redirected, and this context has already been
released in redirectRender(). Which leads to the much more serious issue -- the
new context established by redirectRender() is never released in the exception
handling: the context.release() call in the finally block of doFacesRequest()
is the original, already released context.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
