project_key: JBEPP see issue GTNPORTAL-2347
Link: Added: This issue depends GTNPORTAL-2347
We need to also check the Portal RequestContext parameter list for the resource id, since it can sometimes be specified here. This issue should fix a bunch of problems retrieving resources over the portlet bridge and wsrp.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: == IS THIS ISSUE FOR EPP 5.2.1, AND DOES IT REQUIRE RN ==
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1,7 @@ -== IS THIS ISSUE FOR EPP 5.2.1, AND DOES IT REQUIRE RN ==+Cause: We were missing a location to check for resourceIds when setting the resourceID for the portlet invocation. + +Consequence: The resourceIds would sometimes be null, resulting in resources not being properly fetched. + +Fix: also check the Portal ResourceContext for resourceIDs + +Result: resources work much better, especially when using the portlet bridge over wsrp.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,7 +1 @@ -Cause: We were missing a location to check for resourceIds when setting the resourceID for the portlet invocation. +It was discovered that ResourceIDs were sometimes lost when serving portlet resources because there was no way to check for resourceIds when setting the resourceID for the portlet invocation. The resourceIds would sometimes be null, resulting in resources not being properly fetched. The fix implements logic changes that now additionally check the Portal ResourceContext for resourceIDs. Resources now function more reliably, particularly when using the portlet bridge over WSRP.- -Consequence: The resourceIds would sometimes be null, resulting in resources not being properly fetched. - -Fix: also check the Portal ResourceContext for resourceIDs - -Result: resources work much better, especially when using the portlet bridge over wsrp.
Updated the release notes to make it a bit more clear. There was a way for us to check the resourceIds, we were just not looking in all the right places for it. The Portal ResourceContext is an internal class, and I don't think we should be mentioning it (as its not something a normal user would even know about).
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -It was discovered that ResourceIDs were sometimes lost when serving portlet resources because there was no way to check for resourceIds when setting the resourceID for the portlet invocation. The resourceIds would sometimes be null, resulting in resources not being properly fetched. The fix implements logic changes that now additionally check the Portal ResourceContext for resourceIDs. Resources now function more reliably, particularly when using the portlet bridge over WSRP.+It was discovered that ResourceIDs were sometimes lost when serving resources during a portlet invocation. The would cause the resourceIds to be null, resulting in resources not being properly fetched. The fix implements logic changes that now provide additional checks within the portal for resourceIDs. Resources now function more reliably, particularly when using the portlet bridge over WSRP.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -It was discovered that ResourceIDs were sometimes lost when serving resources during a portlet invocation. The would cause the resourceIds to be null, resulting in resources not being properly fetched. The fix implements logic changes that now provide additional checks within the portal for resourceIDs. Resources now function more reliably, particularly when using the portlet bridge over WSRP.+It was discovered that ResourceIDs were sometimes lost when serving resources during a portlet invocation. This would cause the resourceIds to be null, resulting in resources not being properly fetched. The fix implements logic changes that now provide additional checks within the portal for resourceIDs. Resources now function more reliably, particularly when using the portlet bridge over WSRP.