[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Freedman resolved PORTLETBRIDGE-185. -------------------------------------------- Resolution: Fixed Fix Version/s: 2.0.1 Turns out the actual use case that caused this occurred because of a concurrency interaction inside a series of requests that occur after a renderredirect and include an concurrent render and resource request. The use case problem is the bridge was creating the scopeId early in the render but not actually giving it a representation in the ScopeMap until later. When a concurrent resource request is run -- it can hit this case where it picks up this new scopeId but doesn't find the entry. Fix was actually quite involved -- in that it also showed that in this use case the bridge was overally aggressively creating new scopes. So now the scope activation/resolution has been reworked to make this work/simpler. > Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map > ------------------------------------------------------------------------ > > Key: PORTLETBRIDGE-185 > URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-185 > Project: MyFaces Portlet Bridge > Issue Type: Bug > Components: Impl > Affects Versions: 2.0.0 > Reporter: Michael Freedman > Assignee: Michael Freedman > Fix For: 2.0.1 > > > In handling a resource request we reacquire the bridge request scope. If we > find the scopeId to use but the scope has since been removed from the > ScopeMap (or never put there in the first place) you get an NPE. This happen > because the code (getResourceRequestScopeId() in BridgeImpl) dereferences the > (Map) object pulled from the scopeMap using the scopeId key without checking > first if this object is null (wasn't found). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira