]
Juraci Paixão Kröhling commented on GTNPORTAL-3524:
---------------------------------------------------
I've just submitted another set of branches for a more permanent solution. Note that
this needs to be verified and validated by QE, but would be interesting to get the
customer's feedback as well (after QE runs at least a smoke test).
Branches:
Custom portals cannot use remote portlets
-----------------------------------------
Key: GTNPORTAL-3524
URL:
https://issues.jboss.org/browse/GTNPORTAL-3524
Project: GateIn Portal
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: WSRP integration
Reporter: Juraci Paixão Kröhling
Assignee: Juraci Paixão Kröhling
Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts,
meaning that a PortletInvoker responsible for local portlets was the same on
"portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was
also shared.
This caused the problems described in 3291 and 2700 and a fix was issued in that each
context would have it's own FederatingPortletInvoker .
With local portlets, each context having its own FederatingPortletInvoker is not a big
issue, because the query is made at the JCR level for which portlets are available.
With remote portlets, it's a problem, as WSRP registers the consumers only once, for
the "portal" context. This means that the consumer invokers are not available
for non-"portal" contexts. With this, a call from the context
"sample-portal" to the FederatingPortletInvoker, requesting portlet
"selfv2.bla" would fail, as there's no way to find this portlet on this
particular invoker tree.
While the producers are also started for the "portal" context, the fact that
producers have their own servlet context makes it immune from this bug, as all HTTP calls
to the producers reaches a context whose invoker *knows* about the requested portlet. In
other words: producers are not affected by this bug.