[
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
