[JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.pl... ]
Peter Palaga updated GTNPORTAL-3524:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 3.9.0.Final
Resolution: Done
> Custom portals cannot use remote portlets
> -----------------------------------------
>
> Key: GTNPORTAL-3524
> URL: https://issues.jboss.org/browse/GTNPORTAL-3524
> Project: GateIn Portal
> Issue Type: Bug
> Components: WSRP integration
> Reporter: Juraci Paixão Kröhling
> Assignee: Juraci Paixão Kröhling
> Fix For: 3.9.0.Final
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.pl... ]
Peter Palaga updated GTNPORTAL-3524:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/gatein/gatein-portal/pull/891
> Custom portals cannot use remote portlets
> -----------------------------------------
>
> Key: GTNPORTAL-3524
> URL: https://issues.jboss.org/browse/GTNPORTAL-3524
> Project: GateIn Portal
> Issue Type: Bug
> Components: WSRP integration
> Reporter: Juraci Paixão Kröhling
> Assignee: Juraci Paixão Kröhling
> Fix For: 3.9.0.Final
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months