All of the following Liferay forum threads appear to closely relate to this issue, and are all considered unresolved:
Especially as Liferay further encourages adoption of JSF (with Liferay Faces, etc.) - which I agree, is a desired and necessary goal - I believe this issue requires renewed and priority attention, for what shouldn't be too complex of a fix.
This issue is actually not specific to the MVCPortlet, and applies to any JSR-286 portlet implementation.
I am not currently aware of an acceptable work-around for this, but would be interested in any temporary work-arounds that Liferay may have to offer.
Here is the beginnings of a test case that should be possible:
import java.io.IOException;
import java.io.PrintWriter;
import javax.portlet.Event;
import javax.portlet.EventRequest;
import javax.portlet.EventResponse;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletException;
import javax.portlet.ProcessEvent;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class PortletDemo extends GenericPortlet{
protected static final Logger LOGGER = LoggerFactory.getLogger(PortletDemo.class);
@ProcessEvent(name="test-event")
public void handleContactEvent(EventRequest request, EventResponse response) throws PortletException, IOException{
Event e = request.getEvent();
LOGGER.info("Got test-event: {}", e);
request.setAttribute("test-event", e);
}
@Override
protected void doView(RenderRequest request, RenderResponse response) throws PortletException,
IOException{
PrintWriter pw = response.getWriter();
pw.println("<p>test-event: " + request.getAttribute("test-event") + "</p>");
}
}
As-is, this does not work, due to the issue reported here. Even setting "javax.portlet.actionScopedRequestAttributes" to true does not help.
One naive approach that I am starting to see as a common work-around is to add an instance variable, e.g. "protected Object testEvent;" - which is assigned to from the event method, and read from the "doView" method. However, this is not thread-safe, and will lead to issues under a loaded system. Another approach may be to use a ThreadLocal - which will solve the thread safety concerns, but could lead to memory leaks, and/or accidental re-use of any stored events due to thread pooling/re-use.
Bug
Closed
All of the following Liferay forum threads appear to closely relate to this issue, and are all considered unresolved:
Especially as Liferay further encourages adoption of JSF (with Liferay Faces, etc.) - which I agree, is a desired and necessary goal - I believe this issue requires renewed and priority attention, for what shouldn't be too complex of a fix.
This issue is actually not specific to the MVCPortlet, and applies to any JSR-286 portlet implementation.
I am not currently aware of an acceptable work-around for this, but would be interested in any temporary work-arounds that Liferay may have to offer.
Here is the beginnings of a test case that should be possible:
As-is, this does not work, due to the issue reported here. Even setting "javax.portlet.actionScopedRequestAttributes" to true does not help.
One naive approach that I am starting to see as a common work-around is to add an instance variable, e.g. "protected Object testEvent;" - which is assigned to from the event method, and read from the "doView" method. However, this is not thread-safe, and will lead to issues under a loaded system. Another approach may be to use a ThreadLocal - which will solve the thread safety concerns, but could lead to memory leaks, and/or accidental re-use of any stored events due to thread pooling/re-use.