[kenfinni]

László,

You'd be able to use 3.3.1.Final directly by including it in your WAR and then setting a web.xml context-param:

<context-param>

    <param-name>org.gatein.portletbridge.WAR_BUNDLES_PORTLETBRIDGE</param-name>

    <param-value>true</param-value>

</context-param>

Obviously doing this would make it unsupported, at least with JBoss Portal Platform 6.1

If you upgraded to 6.1.1, when it's available, then you would get the supported version of 3.3.1.Final as part of that release.

Another option is contacting support to see if your support contract enables you to get a patched 3.2.1 version with the feature I described

[mputz]

@Ken: thanks for your input.

@László: we can discuss the support options in our support ticket, but JPP 6.1.1 is literally across the corner.

Overall, great to see the progress made in this thread!

-Martin

[laszlovandenhoek]

Martin, good of you to jump in on the conversation. Did @mentioning you do the trick?

I tried using 3.1.1.Final, adding the web.xml fragment that Ken provided. Initially, this resulted in the error message "Can't detect bridge implementation class name" upon deployment. Then I realized I was packaging only the API and not the implementation.

Adding the corresponding portletbridge-impl to the WAR fixed that problem, but now the Portlet is behaving as I would expect it to, but WITHOUT resetting state as I wanted. Interestingly, this means my mystery NullPointerExceptions and spontaneous view/state resets are gone...

To be clear, I currently don't have anything else configured to reset state; I'm using the plain GenericFacesPortlet, I've disabled the PhaseListener, and I haven't yet implemented Martin's public render parameter approach.

Thanks,

László

[laszlovandenhoek]

I have deleted my latest message because it contained information that appeared to be false on closer inspection. The view reset is not working, and I am still occasionally receiving stack traces. I'm going to try and drill down into this problem so I can share a reproducer.

[kenfinni]

Did you mean 3.3.1.Final and not 3.1.1.Final?

[laszlovandenhoek]

Yes, sorry, I meant 3.3.1.Final.

In the mean time, I have created a new RH support ticket, 01026203, concerning the unpredictable exceptions and unexpected navigations that I mentioned earlier (which appear unrelated to the view/state reset attempts). I won't burden this thread with the details of it because I strongly doubt that it has anything to do with the portlet bridge. Rather, it's more likely than not caused by the rest of our funky setup... After the issue is resolved, however, I will revisit the view/state reset issue and report back here.

Thanks,

László

[laszlovandenhoek]

Alright, I seem to have everything working now, using JPP 6.1.0, with the platform-provided Portlet Bridge 3.2.1.

Before I spend time uploading a working example to GitHub, I'm going to wait and see what happens to this ticket:

https://bugzilla.redhat.com/show_bug.cgi?id=1032715

However, here's a summary:

- in portlet.xml, add an init-param named "outcomeForReset" which has the navigation case for the "initial" page that you want to reset the view state to

- from the portlet class, in doView(request, response):

- save the outcome to the request: request.setAttribute("outcomeForReset", getInitParameter("outcomeForReset"))

- reset any bean state: request.getPortletSession().invalidate()

- from a PhaseListener (registered in faces-config.xml), implement beforePhase(event) something like this (making "outcomeForReset" a constant is recommended):

    public void beforePhase(PhaseEvent e) {
        if (e.getPhaseId() != getPhaseId()) {
            return;
        }

        // Get request.
        FacesContext facesContext = e.getFacesContext();
        Object orr = e.getFacesContext().getExternalContext().getRequest();

        // JSF in portlet?
        if (orr instanceof RenderRequest) {

            // Check if the portlet is to be reset.
            RenderRequest rr = (RenderRequest) orr;
            String outcome = (String) rr.getAttribute("outcomeForReset");

            if (StringUtils.isNotBlank(outcome)) {
                BridgeContext currentBridge = BridgeContext.getCurrentInstance();
                if (currentBridge != null) {
                    LOGGER.info("removing request scopes for bridge " + currentBridge);
                    currentBridge.getBridgeRequestScopeManager().removeRequestScopesByPortlet(currentBridge);
                    rr.getPortletSession().invalidate();
                } else {
                    LOGGER.warn("BridgeContext.getCurrentInstance() returned null, not resetting");
                }

                LOGGER.debug(String.format("Reset detected: navigate to '%1s'.", outcome));
                facesContext.getApplication().getNavigationHandler().handleNavigation(facesContext, "", outcome);

            }
        }
    }

[logesh.ragupathy]

Hi laszlovandenhoek,

I am trying to reset the portlets view to defaultviewid specified in portlet.xml

I am using your PhaseListener Solution to reset the portlet outcome to default viewid. I am just not sure about what to be returned in the method getPhaseId().

I am using JPP 6.1.1 and portletbridge-api:3.3.1Final-redhat-1.

Please suggest what has to be returned on calling getPhaseId()