Possible producer/provider/pluto/driver/PortletInvokerImpl bug

[ri...@peoplesoft.com]

We seem to have stumbled across an issue when a java portlet sets a newMode
or newWindowState inside a processAction (by calling
ActionResponse.setPortletMode or setWindowState). It seems it isn't being
returned to the remote consumer. The code in PortletInvokerImpl never
considers the ones set by the portlet when it builds the UpdateResponse. In
fact, the only things it seems to set are the navigationalState and
markupContext (the WSRPEngine sets the portletContext upon returning). All
other members are left in their initial state... (i.e. the sessionContext
seems to be untouched as well)

Is this analysis correct?

Here's the relevant fragment of the UpdateResponse generated stub:

public class UpdateResponse  implements java.io.Serializable {
    private oasis.names.tc.wsrp.v1.types.SessionContext sessionContext;
    private oasis.names.tc.wsrp.v1.types.PortletContext portletContext;
    private oasis.names.tc.wsrp.v1.types.MarkupContext markupContext;
    private java.lang.String navigationalState;
    private java.lang.String newWindowState;
    private java.lang.String newMode;

Thanks for your time.