myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Freedman <>
Subject Re: [jira] [Commented] (PORTLETBRIDGE-214) BridgeImpl incorrectly cleans up after exceptions; retains contexts
Date Fri, 10 Jun 2011 20:01:44 GMT
  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 ...

On 6/10/2011 12:46 PM, Scott Oaks (JIRA) wrote:
>      [
> 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:
>>              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:

View raw message