[PORTLETSPEC3-60] Portlet Analogs for new Servlet Response Methods Created: 01/Sep/15  Updated: 01/Sep/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

My proposals for handling the ServletResponse and HttpServletResponse methods added since servlet version 2.4 appear below in the table cell adjacent to the servlet response method name. The description in the code example box (grey) is that of the original servlet method.


setContentLengthLong add ResourceResponse#setContentLengthLong method

    void setContentLengthLong(long len)

    Sets the length of the content body in the response In HTTP servlets, this method sets the HTTP Content-Length header.

    Parameters: len - a long specifying the length of the content being returned to the client; sets the Content-Length header
    Since: Servlet 3.1

getStatus add ResourceResponse#getStatus method

    int getStatus()

    Gets the current status code of this response.

    Returns: the current status code of this response
    Since: Servlet 3.0

getHeader add PortletResponse#getProperty method; returns only property for current portlet

    String getHeader(String name)

    Gets the value of the response header with the given name.

    If a response header with the given name exists and contains multiple values, the value that was added first will be returned.

    This method considers only response headers set or added via setHeader(java.lang.String, java.lang.String), addHeader(java.lang.String, java.lang.String), setDateHeader(java.lang.String, long), addDateHeader(java.lang.String, long), setIntHeader(java.lang.String, int), or addIntHeader(java.lang.String, int), respectively.

    Parameters: name - the name of the response header whose value to return
    Returns: the value of the response header with the given name, or null if no header with the given name has been set on this response
    Since: Servlet 3.0

getHeaders add PortletResponse#getProperties method; returns only values added / set by current portlet

    Collection<String> getHeaders(String name)

    Gets the values of the response header with the given name.

    This method considers only response headers set or added via setHeader(java.lang.String, java.lang.String), addHeader(java.lang.String, java.lang.String), setDateHeader(java.lang.String, long), addDateHeader(java.lang.String, long), setIntHeader(java.lang.String, int), or addIntHeader(java.lang.String, int), respectively.

    Any changes to the returned Collection must not affect this HttpServletResponse.

    Parameters: name - the name of the response header whose values to return
    Returns: a (possibly empty) Collection of the values of the response header with the given name
    Since: Servlet 3.0

getHeaderNames add PortletResponse#getPropertyNames method; returns only properties for current portlet.

    Collection<String> getHeaderNames()

    Gets the names of the headers of this response.

    This method considers only response headers set or added via setHeader(java.lang.String, java.lang.String), addHeader(java.lang.String, java.lang.String), setDateHeader(java.lang.String, long), addDateHeader(java.lang.String, long), setIntHeader(java.lang.String, int), or addIntHeader(java.lang.String, int), respectively.

    Any changes to the returned Collection must not affect this HttpServletResponse.

    Returns: a (possibly empty) Collection of the names of the headers of this response
    Since: Servlet 3.0





[PORTLETSPEC3-59] Portlet Analogs for new Servlet Request Methods Created: 01/Sep/15  Updated: 01/Sep/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following ServletRequest and HttpServletRequest methods have been added since v2.4. I've added my suggestions for how they should be dealt with when mapped to portlets in the table cell adjacent to the servlet request method name. The description in the code example box (grey) is that of the original servlet method.


getContentLengthLong add ClientDataRequest#getContentLengthLong method

    long getContentLengthLong()

    Returns the length, in bytes, of the request body and made available by the input stream, or -1 if the length is not known. For HTTP servlets, same as the value of the CGI variable CONTENT_LENGTH.

    Returns: a long containing the length of the request body or -1L if the length is not known
    Since: Servlet 3.1


getServletContext add portlet support - ?? - not exactly sure of use case. might only be useful if we also add dynamic portlet registration.

    ServletContext getServletContext()

    Gets the servlet context to which this ServletRequest was last dispatched.

    Returns: the servlet context to which this ServletRequest was last dispatched
    Since: Servlet 3.0

startAsync no support, throws IllegalStateException

    AsyncContext startAsync() throws IllegalStateException

    Puts this request into asynchronous mode, and initializes its AsyncContext with the original (unwrapped) ServletRequest and ServletResponse objects.

    Calling this method will cause committal of the associated response to be delayed until AsyncContext.complete() is called on the returned AsyncContext, or the asynchronous operation has timed out.

    Calling AsyncContext.hasOriginalRequestAndResponse() on the returned AsyncContext will return true. Any filters invoked in the outbound direction after this request was put into asynchronous mode may use this as an indication that any request and/or response wrappers that they added during their inbound invocation need not stay around for the duration of the asynchronous operation, and therefore any of their associated resources may be released.

    This method clears the list of AsyncListener instances (if any) that were registered with the AsyncContext returned by the previous call to one of the startAsync methods, after calling each AsyncListener at its onStartAsync method.

    Subsequent invocations of this method, or its overloaded variant, will return the same AsyncContext instance, reinitialized as appropriate.

    Returns: the (re)initialized AsyncContext
    Throws: IllegalStateException - if this request is within the scope of a filter or servlet that does not support asynchronous operations (that is, isAsyncSupported() returns false), or if this method is called again without any asynchronous dispatch (resulting from one of the AsyncContext.dispatch() methods), is called outside the scope of any such dispatch, or is called again within the scope of the same dispatch, or if the response has already been closed
    Since: Servlet 3.0
    See Also: AsyncContext.dispatch()

startAsync no support, throws IllegalStateException

    AsyncContext startAsync(ServletRequest servletRequest, ServletResponse servletResponse) throws IllegalStateException

    Puts this request into asynchronous mode, and initializes its AsyncContext with the given request and response objects.

    The ServletRequest and ServletResponse arguments must be the same instances, or instances of ServletRequestWrapper and ServletResponseWrapper that wrap them, that were passed to the service method of the Servlet or the doFilter method of the Filter, respectively, in whose scope this method is being called.

    Calling this method will cause committal of the associated response to be delayed until AsyncContext.complete() is called on the returned AsyncContext, or the asynchronous operation has timed out.

    Calling AsyncContext.hasOriginalRequestAndResponse() on the returned AsyncContext will return false, unless the passed in ServletRequest and ServletResponse arguments are the original ones or do not carry any application-provided wrappers. Any filters invoked in the outbound direction after this request was put into asynchronous mode may use this as an indication that some of the request and/or response wrappers that they added during their inbound invocation may need to stay in place for the duration of the asynchronous operation, and their associated resources may not be released. A ServletRequestWrapper applied during the inbound invocation of a filter may be released by the outbound invocation of the filter only if the given servletRequest, which is used to initialize the AsyncContext and will be returned by a call to AsyncContext.getRequest(), does not contain said ServletRequestWrapper. The same holds true for ServletResponseWrapper instances.

    This method clears the list of AsyncListener instances (if any) that were registered with the AsyncContext returned by the previous call to one of the startAsync methods, after calling each AsyncListener at its onStartAsync method.

    Subsequent invocations of this method, or its zero-argument variant, will return the same AsyncContext instance, reinitialized as appropriate. If a call to this method is followed by a call to its zero-argument variant, the specified (and possibly wrapped) request and response objects will remain locked in on the returned AsyncContext.

    Parameters: servletRequest - the ServletRequest used to initialize the AsyncContext
        servletResponse - the ServletResponse used to initialize the AsyncContext
    Returns: the (re)initialized AsyncContext
    Throws: IllegalStateException - if this request is within the scope of a filter or servlet that does not support asynchronous operations (that is, isAsyncSupported() returns false), or if this method is called again without any asynchronous dispatch (resulting from one of the AsyncContext.dispatch() methods), is called outside the scope of any such dispatch, or is called again within the scope of the same dispatch, or if the response has already been closed
    Since: Servlet 3.0

isAsyncStarted no support, returns false

    boolean isAsyncStarted()

    Checks if this request has been put into asynchronous mode.

    A ServletRequest is put into asynchronous mode by calling startAsync() or startAsync(ServletRequest,ServletResponse) on it.

    This method returns false if this request was put into asynchronous mode, but has since been dispatched using one of the AsyncContext.dispatch() methods or released from asynchronous mode via a call to AsyncContext.complete().

    Returns: true if this request has been put into asynchronous mode, false otherwise
    Since: Servlet 3.0

isAsyncSupported no support, returns false

    boolean isAsyncSupported()

    Checks if this request supports asynchronous operation.

    Asynchronous operation is disabled for this request if this request is within the scope of a filter or servlet that has not been annotated or flagged in the deployment descriptor as being able to support asynchronous handling.

    Returns: true if this request supports asynchronous operation, false otherwise
    Since: Servlet 3.0

getAsyncContext no support, throws IllegalStateException

    AsyncContext getAsyncContext()

    Gets the AsyncContext that was created or reinitialized by the most recent invocation of startAsync() or startAsync(ServletRequest,ServletResponse) on this request.

    Returns: the AsyncContext that was created or reinitialized by the most recent invocation of startAsync() or startAsync(ServletRequest,ServletResponse) on this request
    Throws: IllegalStateException - if this request has not been put into asynchronous mode, i.e., if neither startAsync() nor startAsync(ServletRequest,ServletResponse) has been called
    Since: Servlet 3.0

getDispatcherType add PortletRequest#getDispatcherType

    DispatcherType getDispatcherType()

    Gets the dispatcher type of this request.

    The dispatcher type of a request is used by the container to select the filters that need to be applied to the request: Only filters with matching dispatcher type and url patterns will be applied.

    Allowing a filter that has been configured for multiple dispatcher types to query a request for its dispatcher type allows the filter to process the request differently depending on its dispatcher type.

    The initial dispatcher type of a request is defined as DispatcherType.REQUEST. The dispatcher type of a request dispatched via RequestDispatcher.forward(ServletRequest, ServletResponse) or RequestDispatcher.include(ServletRequest, ServletResponse) is given as DispatcherType.FORWARD or DispatcherType.INCLUDE, respectively, while the dispatcher type of an asynchronous request dispatched via one of the AsyncContext.dispatch() methods is given as DispatcherType.ASYNC. Finally, the dispatcher type of a request dispatched to an error page by the container's error handling mechanism is given as DispatcherType.ERROR.

    Returns: the dispatcher type of this request
    Since: Servlet 3.0
    See Also: DispatcherType

====
changeSessionId add PortletRequest#changeSessionId

    String changeSessionId()

    Change the session id of the current session associated with this request and return the new session id.

    Returns: the new session id
    Throws: IllegalStateException - if there is no session associated with the request
    Since: Servlet 3.1


authenticate add PortletRequest#authenticate method ?

    boolean authenticate(HttpServletResponse response) throws IOException, ServletException

    Use the container login mechanism configured for the ServletContext to authenticate the user making this request.

    This method may modify and commit the argument HttpServletResponse.

    Parameters: response - The HttpServletResponse associated with this HttpServletRequest
    Returns: true when non-null values were or have been established as the values returned by getUserPrincipal, getRemoteUser, and getAuthType. Return false if authentication is incomplete and the underlying login mechanism has committed, in the response, the message (e.g., challenge) and HTTP status code to be returned to the user.
    Throws: IOException - if an input or output error occurred while reading from this request or writing to the given response
        IllegalStateException - if the login mechanism attempted to modify the response and it was already committed
        ServletException - if the authentication failed and the caller is responsible for handling the error (i.e., the underlying login mechanism did NOT establish the message and HTTP status code to be returned to the user)
    Since: Servlet 3.0

login add PortletRequest#login method ?

    void login(String username, String password) throws ServletException

    Validate the provided username and password in the password validation realm used by the web container login mechanism configured for the ServletContext.

    This method returns without throwing a ServletException when the login mechanism configured for the ServletContext supports username password validation, and when, at the time of the call to login, the identity of the caller of the request had not been established (i.e, all of getUserPrincipal, getRemoteUser, and getAuthType return null), and when validation of the provided credentials is successful. Otherwise, this method throws a ServletException as described below.

    When this method returns without throwing an exception, it must have established non-null values as the values returned by getUserPrincipal, getRemoteUser, and getAuthType.

    Parameters: username - The String value corresponding to the login identifier of the user.
        password - The password String corresponding to the identified user.
    Throws: ServletException - if the configured login mechanism does not support username password authentication, or if a non-null caller identity had already been established (prior to the call to login), or if validation of the provided username and password fails.
    Since: Servlet 3.0

logout add PortletRequest#logout method ?

    void logout() throws ServletException

    Establish null as the value returned when getUserPrincipal, getRemoteUser, and getAuthType is called on the request.

    Throws: ServletException - if logout fails
    Since: Servlet 3.0

getParts add ClientDataRequest#getParts method

    Collection<Part> getParts() throws IOException, ServletException

    Gets all the Part components of this request, provided that it is of type multipart/form-data.

    If this request is of type multipart/form-data, but does not contain any Part components, the returned Collection will be empty.

    Any changes to the returned Collection must not affect this HttpServletRequest.

    Returns: a (possibly empty) Collection of the Part components of this request
    Throws: IOException - if an I/O error occurred during the retrieval of the Part components of this request
        ServletException - if this request is not of type multipart/form-data
        IllegalStateException - if the request body is larger than maxRequestSize, or any Part in the request is larger than maxFileSize, or there is no @MultipartConfig or multipart-config in deployment descriptors
    Since: Servlet 3.0
    See Also: MultipartConfig.maxFileSize(), MultipartConfig.maxRequestSize()

getPart add ClientDataRequest#getPart method

    Part getPart(String name) throws IOException, ServletException

    Gets the Part with the given name.

    Parameters: name - the name of the requested Part
    Returns: The Part with the given name, or null if this request is of type multipart/form-data, but does not contain the requested Part
    Throws: IOException - if an I/O error occurred during the retrieval of the requested Part
        ServletException - if this request is not of type multipart/form-data
        IllegalStateException - if the request body is larger than maxRequestSize, or any Part in the request is larger than maxFileSize, or there is no @MultipartConfig or multipart-config in deployment descriptors
    Since: Servlet 3.0
    See Also: MultipartConfig.maxFileSize(), MultipartConfig.maxRequestSize()

upgrade no support, throws ServletException - Revisit, as this would be for web socket support, for example.

    <T extends HttpUpgradeHandler> T upgrade(Class<T> handlerClass) throws IOException, ServletException

    Create an instance of HttpUpgradeHandler for an given class and uses it for the http protocol upgrade processing.

    Parameters: handlerClass - The HttpUpgradeHandler class used for the upgrade.
    Returns: an instance of the HttpUpgradeHandler
    Throws: IOException - if an I/O error occurred during the upgrade
        ServletException - if the given handlerClass fails to be instantiated
    Since: Servlet 3.1
    See Also: HttpUpgradeHandler, WebConnection





[PORTLETSPEC3-58] Remove unneeded chapters and appendices from the Portlet Specification Created: 13/Aug/15  Updated: 13/Aug/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I propose removing the following JSR 286 chapters from the specification:

JSR 286 Chapter Name Reason
Chapter 13 Resource Serving Contains redundant information; moved unique information to other portions of the document
Chapter 14 Serving Fragments through Portlets Contains redundant information; moved unique information to other portions of the document; will be addressed more completely in Portlet hub chapter
Chapter 21 User Information not used
Chapter 27 Leveraging JAXB for Event payloads content added to chapter "Coordination between Portlets"
Chapter 28 Technology Compatibility Kit Requirements Should be contained in TCK documentation; no comparable section in other Java EE specifications
Appendix C CSS Style Definitions not used
Appendix D User Information Attribute Names not used
Appendix E Deployment Descriptor Version 1.0 no value add; available in 2.0 spec
Appendix F TCK Assertions Should be contained in TCK documentation





[PORTLETSPEC3-57] Add "doHeaders" as a full-fledged portlet lifecycle method Created: 12/Aug/15  Updated: 12/Aug/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As discussed in an EG call, the single thing that bothers me the most in the portlet architecture right now is the split "render part" mechanism for handling header rendering separately from markup rendering. For review see the JSR 286 (not 362!!) document section PLT.11.1.4.3 "The Render Part Request Attribute for Setting Headers in the Render Phase".

The story is basically that streaming portal implementations send the portlet response directly to the output stream rather than buffering it. The response is therefore committed when the portlet render method is called to generate output. This means that the portlet has no chance of setting cookies, HTTP headers, or adding markup to the document head section (such as META tags or stylesheets). To make it possible for portlets running on a streaming portal to set such values, a mechanism was defined whereby the render method is called to set header information before the response is committed with the RENDER_PART request attribute set to RENDER_HEADERS, and called a second time to create markup with the RENDER_PART request attribute set to RENDER_MARKUP. This mechanism is activated by setting a portlet container runtime option.

I tried to encapsulate this mechanism somewhat in the @HeaderMethod definition, see the JSR 362 Draft 1 document. Actually, I would like to go farther than that and define "doHeaders" as a portlet lifecycle method in its own right. I would propose defining the following interface:

public interface HeadersPortlet {
   public void renderHeaders(RenderRequest req, RenderResponse resp) 
                  throws PortletException, java.io.IOException;
}

and then move the dispatching mechanism for doHeaders that is currently in GenericPortlet into the portlet container. I believe it would make the architecture in that are much more clear.

However, if we did so, it would be difficult to make "HeadersPortlet" support optional.

Could the "HeadersPortlet" idea potentially be useful for non-streaming portals?






[PORTLETSPEC3-56] Add device attribute-based dispatching to @RenderMethod, @HeaderMethod, and @ServeResourceMethod Created: 12/Aug/15  Updated: 12/Aug/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add two string elements, deviceAttribute and deviceMatch to each of these annotations.

The deviceAttribute element specifies the name of an attribute that can be obtained through the javax.ccpp.Profile#getAttribute method. The deviceMatch element specifies a regular expression used to match the attribute value. To perform a device match, the portlet container retrieves the device attribute named by deviceAttribute and matches it against the regular expression provided by deviceMatch. If the outcome is true, the device matches for request dispatching purposes.






[PORTLETSPEC3-55] Rename 'ParameterCopyOption' on MimeResponse to 'Copy' Created: 12/Aug/15  Updated: 12/Aug/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Rename the long, ugly Enum and Enum member names to short, cute names as shown in the table below:

Old New
MimeResponse.ParameterCopyOption MimeResponse.Copy
COPY_NO_PARAMETERS NONE
COPY_PUBLIC_RENDER_PARAMETERS ALL
COPY_RENDER_PARAMETERS PUBLIC





[PORTLETSPEC3-54] Add Configuration Annotations for Custom Portlet Mode & Window State Created: 06/Aug/15  Updated: 06/Aug/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It should be possible to configure supported portlet modes and window states as well as custom portlet modes and custom window states through annotations.

I propose the addition of the following annotations:

@Supports analog to portlet.xml <supports> element
@CustomPortletMode to be used within @PortletConfiguration annotation
@CustomWindowState to be used within @PortletConfiguration annotation

These should be added as elements of the @PortletConfiguration annotation. This would allow these elements to be configures as in the following example.

@PortletConfiguration(portletName="ConfigTestPortlet",
                      supports = {
                            @Supports(locale="en", portletModes="help"),
                            @Supports(locale="de", 
                               portletModes={"help", "print"},
                               windowStates={"half_page"}),
                            @Supports(locale="fr", portletModes={"help", "edit"})
                      },
                      customPortletModes = {
                            @CustomPortletMode(description="Mode for printing", name="print")
                      },
                      customWindowStates = {
                            @CustomWindowState(name="half_page")
                      })
public class ConfigTestCustomMode {

}






[PORTLETSPEC3-53] New Methods for PortletContext Created: 05/Aug/15  Updated: 05/Aug/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: Neil Griffin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

1. Should the portlet container runtime options be configurable through annotations?

The current annotations proposal does not include the portlet container runtime options because the annotations are all portlet-specific while the deployment descriptor allows runtime options to be declared at both the portlet application and portlet levels.

However, it might be good to allow portlet-level portlet container runtime options to be specified through annotations.

2. Many new methods were added to ServletContext since Servlet v2.4. These primarily allow servlets to be defined dynamically which might be good for framework or test purposes.

Do we want to provide analogous methods for the portlet context? The following table shows my initial guess. The Method column lists the method from the ServletContext. The Version column lists the servlet version that introduced the new method.

Method Version Comments
String getContextPath() 2.5 yes
int getEffectiveMajorVersion() 3.0 yes
int getEffectiveMinorVersion() 3.0 yes
boolean setInitParameter(String name, String value) 3.0 yes
ServletRegistration.Dynamic addServlet(String servletName, String className) 3.0 ?
ServletRegistration.Dynamic addServlet(String servletName, Servlet servlet) 3.0 ?
ServletRegistration.Dynamic addServlet(String servletName, Class<? extends Servlet> servletClass) 3.0 ?
<T extends Servlet> T createServlet(Class<T> clazz) 3.0 ?
ServletRegistration getServletRegistration(String servletName) 3.0 ?
Map<String,? extends ServletRegistration> getServletRegistrations() 3.0 ?
FilterRegistration.Dynamic addFilter(String filterName, String className) 3.0 ?
FilterRegistration.Dynamic addFilter(String filterName, Filter filter) 3.0 ?
FilterRegistration.Dynamic addFilter(String filterName, Class<? extends Filter> filterClass) 3.0 ?
<T extends Filter> T createFilter(Class<T> clazz) 3.0 ?
FilterRegistration getFilterRegistration(String filterName) 3.0 ?
Map<String,? extends FilterRegistration> getFilterRegistrations() 3.0 ?
SessionCookieConfig getSessionCookieConfig() 3.0 ?
void setSessionTrackingModes(Set<SessionTrackingMode> sessionTrackingModes) 3.0 ?
Set<SessionTrackingMode> getDefaultSessionTrackingModes() 3.0 ?
Set<SessionTrackingMode> getEffectiveSessionTrackingModes() 3.0 ?
void addListener(String className) 3.0 ?
<T extends EventListener> void addListener(T t) 3.0 ?
void addListener(Class<? extends EventListener> listenerClass) 3.0 ?
<T extends EventListener> T createListener(Class<T> clazz) 3.0 ?
JspConfigDescriptor getJspConfigDescriptor() 3.0 ?
ClassLoader getClassLoader() 3.0 yes
void declareRoles(String... roleNames) 3.0 ?

3. Please review section on "7.4.4 Runtime Option javax.portlet.actionScopedRequestAttributes".






[PORTLETSPEC3-52] Clarify Method Description for PortletResponse#setProperty Created: 08/Jul/15  Updated: 08/Jul/15

Status: Open
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A clarification should be added to the method description for the PortletResponse#setProperty method. This method can be used to set HTTP header values for the response. It is currently unclear as to whether the portlet code calling the method should encode the input value, or whether the portlet container does the encoding.

The corresponding servlet method is ServletResponse#setHeader. This method requires the caller to properly encode the input data. The method description contains a corresponding notice.

Similarly, the caller to setProperty should perform the encoding. An appropriate notice should be added to the method description.

Current method description:

 void setProperty(java.lang.String key,
                 java.lang.String value)

    Sets a String property to be returned to the portal.

    Response properties can be viewed as header values set for the portal application. If these header values are intended to be transmitted to the client they should be set before the response is committed.

    This method resets all properties previously added with the same key.

    Parameters:
        key - the key of the property to be returned to the portal
        value - the value of the property to be returned to the portal 
    Throws:
        java.lang.IllegalArgumentException - if key is null.

Updated method description:

 void setProperty(java.lang.String key,
                 java.lang.String value)

    Sets a String property to be returned to the portal.

    Response properties can be viewed as header values set for the portal application. If these header values are intended to be transmitted to the client they should be set before the response is committed.

    This method resets all properties previously added with the same key.

    Parameters:
        key - the key of the property to be returned to the portal
        value - the value of the property to be returned to the portal. The value should be encoded according to RFC 2047 (http://www.ietf.org/rfc/rfc2047.txt)
    Throws:
        java.lang.IllegalArgumentException - if key is null.






[PORTLETSPEC3-51] Change PortletURLGenerationListener Declaration to allow for backward compatibility Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current interface declaration for the PortletURLGenerationListener requires arguments of type PortletURL for both the Action URL and render URL arguments. This is inconvenient for V3 portlet developers, as it would require a cast to get the ActionURL and RenderURL objects, respectively.

On the other hand, we need to retain source & binary backward compatibility with existing JSR 286 portlets that use such a listener.

I suggest we change the interface declaration as follows to address both problems:

public interface PortletURLGenerationListener 
      <T extends PortletURL & RenderURL, U extends PortletURL & ActionURL>{

	public void filterActionURL(U actionURL);
	public void filterRenderURL(T renderURL);
	public void filterResourceURL(ResourceURL resourceURL);
}

Through type erasure, this is binary compatible with the existing declaration, and V2 portlets run unchanged. V2 portlets can be recompiled against the V3 API library, so source compatibility is achieved as well.

The V3 portlet developer has access to the new ActionURL and RenderURL interfaces, and would implement the interface as follows:

public class URLFilter implements PortletURLGenerationListener<RenderURL, ActionURL> {

   @Override
   public void filterActionURL(ActionURL actionURL) {
      // do something
   }

   @Override
   public void filterRenderURL(RenderURL renderURL) {
      // do something
   }

   @Override
   public void filterResourceURL(ResourceURL resourceURL) {
      // do something
   }

}





[PORTLETSPEC3-50] Updates from the V3 Prototype Implementation Created: 25/Feb/15  Updated: 25/Feb/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

During implementation of the V3 prototype some changes in the Portlet Specification
v3.0 API definitions and javadoc seemed necessary and/or prudent. This issue lists
those changes.

1) Change the method signatures of MimeResponse#createRenderURL and
MimeResponse#createActionURL to allow for backward compatibility. Without these
changes, V2.0 portlets would not run unchanged.

Old Signatures:

    public RenderURL createRenderURL();
    public ActionURL createActionURL();

New signatures:

   public <T extends PortletURL & RenderURL> T createRenderURL();
   public <T extends PortletURL & ActionURL> T createActionURL();

2) The MutablePortletParameters#set() method returns a MutablePortletParameters
object rather than a PorletParameters object.

    public MutablePortletParameters set(PortletParameters params);

3) The MutablePortletParameters#add() method returns a MutablePortletParameters
object rather than a PorletParameters object.

    public MutablePortletParameters add(PortletParameters params);

4) The PortletParameters interface does not extend Cloneable as originally
envisioned. It was too difficult to make it work properly, as the PortletParameters#clone()
method returns a MutablePortletParameters object.

5) Added a size() method to PortletParameters, defined as follows:

  /**
   * Returns the number of parameters in this object.
   *
   * @return  the number of parameters in this object
   * 
   * @since    3.0
   */
  public int size();

6) Added new methods to the PortletURLGenerationListener taking specific URL
types defined as follows:

(This needs revisiting - reviewing this, I think I introduced an incompatibility!)

	/**
	 * Callback being called by the portlet container
	 * before <code>toString</code> or <code>write</code>
	 * are executed on action URLs.
	 * 
	 * @param actionURL  action URL to be generated
	 */
	public void filterActionURL(ActionURL actionURL);

	/**
	 * Callback being called by the portlet container
	 * before <code>toString</code> or <code>write</code>
	 * are executed on render URLs.
	 * 
	 * @param renderURL  render URL to be generated
	 */
	public void filterRenderURL(RenderURL renderURL);

7) Updated the Portlet Hub Javascript action() function to return a Promise
that is resolved with no argument when the action completes. This allows a
portlet client to be implemented in such a manner that the portlet UI doesn't
allow further input until the action completes.

See the following links to view the updates:

Updated Javadocs

Updated Jsdocs






[PORTLETSPEC3-49] Add createRedirectURL() method to javax.portlet.ActionResponse interface and javax.portlet.filter.ActionResponseWrapper class Created: 19/Feb/15  Updated: 12/Aug/15

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Portlet 2.0 API provides the ActionResponse.redirect(String) method in order to support redirection during the ACTION_PHASE of the portlet lifecycle. However, frameworks like JSF need to determine the redirect URL (typically a String representation of a render URL) before they can call the redirect method. The problem is that the createRenderURL() method is only available in the Portlet 2.0 javax.portlet.MimeResponse interface.

Since it is not appropriate for javax.portlet.ActionResponse to extend javax.portlet.MimeResponse, this issue serves as a proposal for adding the following method to the javax.portlet.ActionResponse interface and javax.portlet.filter.ActionResponseWrapper class:

public PortletURL createRedirectURL();


 Comments   
Comment by msnicklous [ 12/Aug/15 ]

Neil,

creating a render URL during the action request processing would preclude subsequent event processing because the generated URL would not contain state changes resulting from event processing.

I would propose an alternative method defined as follows:

public void setRedirect(boolean redirectFlag)

Indicates to portlet container that a redirect to the render URL resulting from completion of the current action phase should occur. The target render URL should contain all state changes resulting from action and event request processing for the current action phase.

If the argument is set to true, the portlet requests that a redirect will occur at the end of the action phase. If set to false, indicates that the portlet does not require a redirect.

Would this be an acceptable solution?





[PORTLETSPEC3-48] Support @Inject for portlet lifecycle objects such as PortletConfig, PortletRequest, and PortletResponse Created: 17/Feb/15  Updated: 17/Feb/15

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Neil Griffin Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In a jsr371-experts thread titled Initial Work & Feedback, co-spec-lead Santiago Pericas-Geertsen mentioned that JAX-RS (and MVC indirectly since it depends on JAX-RS) supports injection of
HttpServletRequest/HttpServletResponse.

It is my best understanding that this requirement actually falls on the CDI implementation (i.e.: Weld, OpenWebBeans, CanDI), and that JAX-RS/MVC simply benefit from that.

Santiago went on to write:

it should be fairly simple to support injection of Portlet-specific types for portlet applications

I think that this responsibility would fall on the portlet container implementation. Therefore this issue serves as a feature for implementing injection of portlet lifecycle objects such as javax.portlet.PortletConfig, javax.portlet.PortletRequest, and javax.portlet.PortletResponse.






[PORTLETSPEC3-47] Portlet JSP taglib namespace needs to be updated to 3_0 Created: 10/Feb/15  Updated: 25/Feb/15  Resolved: 25/Feb/15

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Neil Griffin Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JSP_SPEC_PUBLIC-188 Change XMLNamespace for all files tha... Open

 Description   

Portlet 2.0 JSPs require the following namespace for usage of JSP tags like <portlet:renderURL />:

xmlns:portlet="http://java.sun.com/portlet_2_0” 

But this needs to be upgraded for Portlet 3.0 JSPs to the following:

xmlns:portlet="http://xmlns.jcp.org/portlet_3_0” 


 Comments   
Comment by keilw [ 10/Feb/15 ]

Would it still be

xmlns:portlet="http://java.sun.com/portlet_3_0”

for historic reasons, even 5 years after the Oracle takeover?

Comment by Neil Griffin [ 11/Feb/15 ]

I had a conversation with Ed Burns of Oracle and he indicated that moving forward, xmlns.jcp.org is the namespace hostname for documents that use namespaces in JCP specifications. I have update the description of this issue accordingly.

Comment by msnicklous [ 17/Feb/15 ]

I like this because it's concise. Would anything speak against using the following namespaces:

For portlets:
xmlns:portlet="http://xmlns.jcp.org/portlet/portlet_3_0”

example:
<portlet-app xmlns="http://xmlns.jcp.org/portlet/portlet_3_0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/portlet/portlet_3_0 http://xmlns.jcp.org/portlet/portlet-app_3_0.xsd"
version="3.0">

For JSPs:
xmlns:portlet="http://xmlns.jcp.org/jsp/portlet_3_0”

example:
<%@ taglib uri="http://xmlns.jcp.org/jsp/portlet_3_0" prefix="portlet" %>

Comment by Neil Griffin [ 17/Feb/15 ]

The portlet.xml namespace is discussed in PORTLETSPEC3-46. In all examples of Java EE I see that /xml/ns/ is included in the namespace.

Regarding JSP, I do see examples in JSTL that include /jsp/ in the namespace.

Comment by msnicklous [ 25/Feb/15 ]

After reflecting, I agree with Neil's original suggestion. The V3 prototype of the Pluto reference implementation, available for download here, is implemented so that the JSP namespace can be specified as follows:

<%@ taglib uri="http://xmlns.jcp.org/portlet_3_0"  prefix="portlet" %>




[PORTLETSPEC3-46] Portlet XML namespace needs to conform to Java EE 7 pattern Created: 06/Feb/15  Updated: 25/Feb/15  Resolved: 25/Feb/15

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Neil Griffin Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When a developer creates a WEB-INF/portlet.xml descriptor its contents typically looks like this:

<portlet-app
  xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
  version="2.0">

But according to the Java EE: XML Schemas for Java EE Deployment Descriptors page, for Portlet 3.0 + Java EE 7 alignment we should use "xmlns.jcp.org" in the namespace. For example:

<portlet-app
  xmlns="http://xmlns.jcp.org/xml/ns/portlet/portlet-app_3_0.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/portlet/portlet-app_3_0.xsd http://xmlns.jcp.org/xml/ns/portlet/portlet-app_3_0.xsd"
  version="3.0">

However, unless there is some technical problem (such as the ability to deploy Portlet 2.0 and 3.0 portlets on the same page), I would like to suggest that we improve the syntax a little, in order to make it more consistent with other Java EE usage (such as a descriptor like WEB-INF/web.xml):

<portlet-app
  xmlns="http://xmlns.jcp.org/xml/ns/portlet"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/portlet http://xmlns.jcp.org/xml/ns/portlet/portlet-app_3_0.xsd"
  version="3.0">

For more examples, see Antonio Goncalves' blog entry titled Java EE 7 Deployment Descriptors.



 Comments   
Comment by msnicklous [ 25/Feb/15 ]

I agree with Neil's suggestion. From what I gather, the best practice is not to include version information in the namespace, but rather put the version in a separate attribute. So far, I haven't run into a technical problem that would stand in the way.

In the V3 prototype reference implementation, available for download here, I implemented the portlet namespace so that it can be specified as follows:

<portlet-app xmlns="http://xmlns.jcp.org/xml/ns/portlet" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/portlet http://xmlns.jcp.org/xml/ns/portlet/portlet-app_3_0.xsd" 
   version="3.0">




[PORTLETSPEC3-45] Questions about Public Render Parameters Created: 14/Jan/15  Updated: 14/Jan/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While implementing the Portlet Hub on Pluto, some questions came up about Public Render Parameters.

1) Pluto matches PRPs between portlets based on the identifier. The PRP QName is ignored.

According to the JSR 286 specification, the QName should be used as a unique identifier for the PRP. Also, the spec contains the following text describing how the public render parameters are to be shared between portlets:

It is up to the portal implementation to decide which portlets may share the same public render parameters. The portal should use the information provided in the deployment descriptor, like the name, qname, alias names and description, in order to perform such a mapping between public render parameters of different portlets. It is also an implementation choice of the portal whether different portlet windows of the same portlet will receive the same public render parameters. An example where different portlet windows may not want to share the same render parameters is a generic viewer portlet that takes as public render parameter the news article ID to display. The user may have several of this viewer portlets on her pages that may be connected to different content systems.

While leaving a great deal of room for implementation flexibility, the 'identifier' field from the portlet descriptor is not mentioned in the criteria for mapping public render parameters.

Taken together, I believe that the public render parameter mapping should not be based on the identifier, but rather on the QName. This would mean that the Pluto implementation is in error and should be corrected.

See: PLUTO-642

Portlets for testing this behavior can be found in the Pluto TCK in the two modules TestModule3-portlet1 and TestModule3-portlet2. The portlets contain four Public Render Parameter tests. These tests have been pushed to the master as well as to the PortletHub branches of the repository.

If you feel that the mapping should be done based on the identifier, please make your arguments known, thanks!

2) The second problem has to do with aliases for Public Render Parameters. The spec does not describe the use of aliases in detail, but the portlet deployment descriptor schema allows aliases to be specified.

I believe that there are problems associated with the concept of aliases for public render parameters that render it of little use.

For example, what should happen when aliases for a PRP refer to two different, but valid, public render parameter QNames? Which one should be used?

It is also possible to construct configurations through use of QNames where the configuration for the individual portlets is ok, but the overall configuration produces a logical inconsistency.

For these reasons, I propose clarifying the specification by completely removing the idea of aliases for Public Render Parameters from the document and also from the deployment descriptor schema (for version 3).






[PORTLETSPEC3-44] Using Client side(Jquery/ ..) internationalization in portal Created: 09/Jul/14  Updated: 09/Jul/14

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: murali101 Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All portal supported servers



 Description   

Since various portal vendors using the different internationalization / localization , better to use light weight client side language...






[PORTLETSPEC3-43] In the Portlet State proposal, shorten the method names in the PortletParameters and MutablePortletParameters classes Created: 03/Jun/14  Updated: 03/Jun/14

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Portlet State proposal defines the PortletParameters and MutablePortletParameters classes for reading and updating parameters. Many of the method names in these classes have the word "Parameter" in their signature:

getParameter(String)
getParameterNames()
getParameterValues(String)
setParameter(String, String)
setParameter(String, String...)

These names are very long and also redundant, since both classes deal exclusively with parameters. The method names should be shortened.



 Comments   
Comment by msnicklous [ 03/Jun/14 ]

The following naming would shorten the method names and reduce redundancy. This suggestion also makes the getter & setter naming more symmetrical and more in line with bean naming conventions.

getValue(String)
getNames()
getValues(String)
setValue(String, String)
setValues(String, String...)




[PORTLETSPEC3-41] Some minor changes for the Portlet State proposal Created: 27/May/14  Updated: 27/May/14  Resolved: 27/May/14

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I received a few comments about the portlet state proposal.

1) Refers to issue PORTLETSPEC3-13. The current proposal adds four methods to handle fragment identifiers: getFragmentIdentifier, setFragmentIdentifier, isFragmentIdentifierPermitted, and setFragmentIdentifierPermitted. The intention of the "permitted" methods is to be able to suppress a fragment identifier set by the portal. A better way to accomplish that goal would be to drop both of the "permitted" methods and redefine the "get" method to return either the fragment identifier previously set
by the portal, or that set by the portlet. The portlet could then use the setter to set the value to "null" if no fragment identifier is desired.

2) Refers to issue PORTLETSPEC3-21. The "write" methods on BaseURL that take an Appendable argument should be renamed to "append" and should return the modified Appendable input object in order to allow for chaining.

3) In the new MutablePortletParameters#setParameter(String, String[]) method, a null value for the array or an empty array should be allowed.

4) Add a new MutablePortletParameters#getParameterNames(String) method that returns a Set, overriding the corresponding PortletParameters method. In the mutable case, removing a parameter from the set will remove that parameter from the PortletParameters object.



 Comments   
Comment by msnicklous [ 27/May/14 ]

I don't believe these changes are critical, so I just went ahead and fixed them. Naturally, I'm open for comments / concerns on them anyway.

See:

RenderURL.html#getFragmentIdentifier()
BaseURL.html#append(java.lang.Appendable)
BaseURL.html#append(java.lang.Appendable,%20boolean)
PortletParameters.html#getParameterNames()
MutablePortletParameters.html#getParameterNames()
MutablePortletParameters.html#setParameter(java.lang.String,%20java.lang.String...)
MutablePortletParameters.html#add(javax.portlet.PortletParameters)





[PORTLETSPEC3-40] Add new javax.portlet.ResourceComparator annotation in order to identify duplicate resources Created: 13/Dec/13  Updated: 13/May/14

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Neil Griffin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I would like to propose the following annotation, which
would allow portlet developers (and JSF portlet bridge implementors)
to provide a way to inform the portlet container of duplicate
resources. This is a common problem with JSF portlets, since each
JSF portlet on the portal page needs the "jsf.js" resource:

package javax.portlet;
/**
* Annotation for marking a class that compares resource URLs. Such classes are
* discovered by the portlet container at startup and are required to
* implement the {@link java.util.Comparator} interface in order to compare
* resources represented as type {@link java.lang.String}. If the
* {@link java.util.Comparator#compare(Object, Object)} method returns 0, then
* the portlet container will consider the resources to be identical and will include
* only the first resource in the &lt;head/&gt; section of the rendered portal page.
*
* @since 3.0
*/
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ResourceComparator {
}

Here is an example that a JSF portlet bridge could use in order to prevent duplicate JSF resources:

public interface FacesResource {

	public enum TYPE {
		HREF, LINK, SCRIPT
	}
	
	public TYPE getType();
	
	public String getName();
	
	public String getLibrary();
}
@ResourceComparator
public class FacesResourceComparator implements Comparator<String> {

	public int compare(String resourceURL1, String resourceURL2) {

		if (isFacesResource(resourceURL1) && isFacesResource(resourceURL2)) {
				
				FacesResource facesResource1 = new FacesResourceImpl(resourceURL1);
				FacesResource facesResource2 = new FacesResourceImpl(resourceURL2);

				if (facesResource1.equals(facesResource2)) {
					return 0;
				}
				else {
					return -1;
				}
		}
		else {
			return -1;
		}
	}

	protected boolean isFacesResource(String url) {
		return ((url != null) && url.contains("javax.faces.resource"));
	}
}


 Comments   
Comment by kito75 [ 14/Jan/14 ]

Sounds good to me. Would we need a default implementation?

Comment by Ed Burns [ 13/May/14 ]

This seems like a tough problem to solve in the absence of a component based rendering model.

Comment by Ed Burns [ 13/May/14 ]

I would need to see more context to be able to critique this. I don't know enough about the portlet runtime to understand who would be instantiating the FacesResourceComparator and when it would be getting invoked, for example.

Comment by Neil Griffin [ 13/May/14 ]

After each portlet on a page has undergone the RENDER_PHASE of the portlet lifecycle, the portal server is responsible for assembling a complete HTML document. When it comes time for the portal server to build up the contents of the <head>...</head> section, the portal server would invoke classes marked with @ResourceComparator in order to let individual portlets determine whether or not two resources are essentially identical. One example would be a portal page with two or more JSF portlets. Each JSF portlet would attempt to add jsf.js to the <head>...</head> section. The JSF Portlet Bridge could have a class annotated with @ResourceComparator that would be able to identify duplicate jsf.js inclusions. The portal server would then know that it should only include the first instance of jsf.js in the <head>...</head> section.





[PORTLETSPEC3-39] Ajax: Improve version specification for dependencies / resources Created: 13/Dec/13  Updated: 13/Dec/13

Status: Open
Project: portletspec3
Component/s: Stateful Ajax Support
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reference: Ajax Proposal 2b

The current proposal for dependencies calls for either the specification of an exact resource version through use of the <version> tag or a minimum version through the <minVersion> tag.

Instead, the <minVersion> should be dropped, and a version specification similar to what maven (and OSGi, as I understand it) uses should be provided through the <version> tag.

Details to be provided ... I think we should use a subset of what is described under the maven link.






[PORTLETSPEC3-38] Ajax: Change name "JavaScript Portlet" to ... something less confusing Created: 13/Dec/13  Updated: 14/Jan/14

Status: Open
Project: portletspec3
Component/s: Stateful Ajax Support
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reference: Ajax Proposal 2b

The term "JavaScript Portlet" for client-side code is confusing as it sounds as though the portlet would actually be running in JavaScript on the client, which is not the case.

Instead, the "JavaScript Portlet" is a piece of JavaScript code provided by the portlet for handling the portlet UI.

I understand the conflict, but don't have a good naming proposal right offhand, so please provide better suggestions.



 Comments   
Comment by kito75 [ 14/Jan/14 ]

How about JavaScript Portlet UI?





[PORTLETSPEC3-37] Ajax: Add support for form submission to the portlet hub action method Created: 13/Dec/13  Updated: 13/Dec/13

Status: Open
Project: portletspec3
Component/s: Stateful Ajax Support
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reference: Ajax Proposal 2b

The proposal allows for an action method that accepts an array of action parameters as a parameter:

action(actionParameters)

This assumes that the JavaScript Portlet can always represent an action request as parameters, which is not always the case when a form is to be submitted. To allow for general form submission, an optional form parameter should be added to the method signature:

action(actionParameters, form)

where "form" is the DOM element representing the form to be submitted. If a form parameter is present on an action call, the portlet hub would submit the form to the portal.






[PORTLETSPEC3-36] Ajax: Remove ability for portlets to provide resources Created: 13/Dec/13  Updated: 14/Jan/14

Status: Open
Project: portletspec3
Component/s: Stateful Ajax Support
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: msnicklous Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reference: Ajax Proposal 2b

The current proposal allows both the portal and individual portlets to contribute resources for sharing with other portlets.

There is concern that this may lead to improper behavior if different portlets use the same name for different resources. For example, portlet A might provide a certain library at a certain version level. Portlet B might provide that same library at the same version level, but in reality, portlet B's library might be slightly modified as compared to that from portlet A (a fix or debug code might be added by one portlet but not the other, etc).

This could potentially lead to a situation where the behavior of the portlets on the page depends on the order in which the portlets appear on the page, or on the algorithm used by the portal for selecting resources when more than one resource of the same name is available. Bugs resulting from such a situation could be very hard to find.

It might be safer to allow portlets to only specify the resources they depend on. The actual resources themselves would always be provided by the portal - individual portlets would not be able to contribute resources for consumption by other portlets.

The manner in which resources are configured in the portal would remain unspecified and implementation-specific.



 Comments   
Comment by Neil Griffin [ 13/Dec/13 ]

Portlets developed against the existing Portlet 2.0 standard can contribute resources to the rendered page via the following syntax:

@Override
public void doView(RenderRequest request, RenderResponse response) {
    renderResponse.setProperty(MimeResponse.MARKUP_HEAD_ELEMENT, element);
}

See: http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/MimeResponse.html#MARKUP_HEAD_ELEMENT

Resources that are contributed in this manner end up in the <head>...</head> section of the rendered portal page by default, and are by nature "shared" with other portlets.

Because of this, it seems like it would be OK to permit portlets to serve up their own resources using a feature similar to the JSF ResourceHandler. It wouldn't introduce any type of potentially troublesome behavior that doesn't already exist in Portlet 2.0.

Comment by kito75 [ 14/Jan/14 ]

I agree with Neil – some sort of registration mechanism makes sense. This does mean, however, that resources referenced manually without registration should be disallowed.





[PORTLETSPEC3-35] Errata: apidoc description of MimeResponse.setContentType() needs to specify exception Created: 21/Aug/13  Updated: 22/Aug/13  Resolved: 22/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The portlet specification in section 12.5.1 Content Type states:

For the render response the setContentType method must throw an IllegalArgumentException if the content type set does not match (including wildcard matching) any of the content types returned by the getResponseContentType method of the PortletRequest objectcxii.

However, this is not reflected in the apidocs for the method.

void setContentType(String type)

Sets the MIME type for the response. The portlet should set the content type before calling getWriter() or getPortletOutputStream(). If the content type is not the PortletRequest.getResponseContentType() value is set as response content type by the portlet container.

Calling setContentType after getWriter or getOutputStream does not change the content type.

Parameters:
type - the content MIME type
See Also:
PortletRequest.getResponseContentTypes(), getContentType()

We need to add a "Throws" section to the description. I would also use the opportunity to fix the description ... seems to be worded strangely. I believe the following captures the intention:

void setContentType(String type)

Sets the MIME type for the response. The portlet should set the content type before calling getWriter() or getPortletOutputStream(). If the content type is not set using this method, the preferred content type as returned by PortletRequest.getResponseContentType() is used.

Calling setContentType after getWriter or getOutputStream does not change the content type.

Parameters:
type - the content MIME type
See Also:
PortletRequest.getResponseContentTypes(), getContentType()
Throws:
IllegalArgumentException - if the content type is invalid.



 Comments   
Comment by msnicklous [ 22/Aug/13 ]

Updated description to MimeResponse.setContentType to add exception that is thrown when the content type is invalid and to clarify the description of that method.





[PORTLETSPEC3-34] More tutorial content for API changebars Created: 16/Aug/13  Updated: 25/Aug/13  Resolved: 25/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes


 Description   

Scott,

Thanks for applying the changebars to a few more classes, specifically:

MimeResponse
RenderResponse
StateAwareResponse

This issue will cause a pull request that will apply some changes to those classes that you appear to have missed, assuming the goal is to achieve parity with the multi-level system we use in JSF.



 Comments   
Comment by Ed Burns [ 16/Aug/13 ]

Sent pull request.

https://github.com/edburns/portletspec3/commit/49faade0e70a3f03145dcac6019da9d43b52d547

Comment by msnicklous [ 25/Aug/13 ]

Proposed changes have been assimilated.





[PORTLETSPEC3-33] API changebars Created: 13/Aug/13  Updated: 16/Aug/13  Resolved: 16/Aug/13

Status: Closed
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour


 Description   

Apply JSF style color coded change bars to portlet spec.



 Comments   
Comment by Ed Burns [ 13/Aug/13 ]

Sent request to pull https://github.com/edburns/portletspec3/branches/PORTLETSPEC3-33





[PORTLETSPEC3-32] Change the parameter handling on the action URL to match the parameter handling on the render URL Created: 31/Jul/13  Updated: 29/Aug/13  Resolved: 29/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This addresses the differences in parameter handling on URLs created through the MimeResponse createActionURL() and createRenderURL() methods. It would be logical for the behavior to be the same for both URL types, since both are represented by a PortletURL object. Currently, the parameter handling differs in only one area - the handling of public render parameters.

A public render parameter can be set on a render URL. When the render URL is activated, the public render parameter is set to the new value, so the code in the render request will behave as follows:

// returns the public render parameter as set on the render URL (or the first value of a multi-valued parameter)
String value = renderRequest.getParameter("myPublicRenderParameter");    

// returns an array containing the value or values of the public render parameter as set on the render URL
String[] values = renderRequest.getParameterValues("myPublicRenderParameter");

// returns the current value of the public render parameter as set on the render URL
Map<String, String[]> parms = renderRequest.getPublicParameterMap();

However, when a parameter with the same name as a public render parameter is set on an action URL, an action parameter by that name is set on the URL. During action request processing, BOTH the action parameter value AND the public render parameter value are available under the same parameter name, so the code in the action request will behave as follows:

// returns the action parameter (or the first value of a multi-valued parameter)
String value = actionRequest.getParameter("myPublicRenderParameter");    

// returns an array containing the value or values of the action parameter followed by the value or values of the public render parameter
String[] values = actionRequest.getParameterValues("myPublicRenderParameter");

// will return the current value of the public render parameter (which may have been set in the past by this or another portlet,
// or which may have been removed)
Map<String, String[]> parms = actionRequest.getPublicParameterMap();

From the point of view of the getParameter() and getParameterValues() methods, the action URL parameter handling behavior is confusing. It seems that there might not be many use cases that would count on this behavior. In fact, a negative use case might be more common - the programmer sets a parameter on an action URL, believing that a public render parameter is being set. But in reality, the actual public render parameter ever gets set.

The proposal calls for making action URL behavior in this area to be identical to the render URL behavior.

However, it would represent a change in specified behavior as compared to JSR 286, so it needs to be considered carefully.



 Comments   
Comment by andre.hagemeier [ 31/Jul/13 ]

A colleague of mine just reported an issue, which I am pretty sure, is related to this. He set a public render parameter and during the procession of a preprocessor, he somehow retrieved two parameters with the same name.
Surely, there was some problem with the implementation as well, but as Scott already mentioned, the negative use cases could be more common than positive side effects.

I wonder, how you would want to adjust the action behavior to behave similar to the render behavior. In your example, would setting the prp on the action request update the prp from the renderrequest?

Comment by msnicklous [ 01/Aug/13 ]

Yes, that's the proposal - change the implementation so that setting a public render parameter on an action URL will result the public render parameter being set when the URL is activated.

This would require changes to the appropriate section of the spec, to the RI, and to the TCK.

Comment by Neil Griffin [ 06/Aug/13 ]

+1 This is the way Liferay already works

Even though some of our other PortletBox tests cover this, here is a new tester portlet that contains minimal code for testing this particular issue:
https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-32-portlet

Comment by msnicklous [ 29/Aug/13 ]

Resolved by updating API descriptions with accompanying spec update. See:

MimeResponse.createActionURL(UrlFlag)
MimeResponse.createActionURL()
Spec update, section on Portal URLs





[PORTLETSPEC3-31] Provide a mechanism to automatically copy render parameters to the StateAwareResponse during action requests and event requests Created: 31/Jul/13  Updated: 16/Aug/13

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A common portlet programming use case is to copy the render parameters representing the portlet state from the ActionRequest or EventRequest to the ActionResponse or EventResponse (StateAwareResponse), respectively. To improve the portlet API usability, a mechanism should be implemented that would allow the render parameters to be automatically added to the StateAwareResponse to that programmers would only need to set parameters to reflect the changes that need to take place due to action or event request handling.

This represents a break compared with the JSR 286 programming model, so a runtime option to control this behavior should be added as well.

javax.portlet.copyRenderParametersToResponse
TRUE - The render parameters are automatically copied to the response
FALSE - The render parameters are not copied to the response, implementing the JSR 286 behavior.

Use of this parameter would make migration of JSR 286 portlets to the JSR 362 programming model easier.

We would need to decide on the default setting for this parameter.

1) On the one hand, the portlet container could recognize the portlet version based on the deployment descriptor. The portlet container could (logically) set the parameter to TRUE when a JSR 362 portlet is loaded and to FALSE when a JSR 286 portlet is loaded. For the migration case where a major JSR 286 portlet application is migrated to JSR 362 in order to use new features, but it would be too much work to change the parameter handling, the programmer could explicitly set the runtime setting to FALSE in the deployment descriptor to facilitate migration.

2) On the other hand, an experienced portlet programmer might not realize that there is a major difference in this area, and be completely surprised and irritated by the new behavior. To prevent such surprises, it might be better to have the default setting to always be FALSE, and allow programmers who wish to take advantage of the new behavior to explicitly set the runtime option in the deployment descriptor to TRUE.



 Comments   
Comment by andre.hagemeier [ 31/Jul/13 ]

Generally I would always favor stable backwards compatibility over new features, but in this case I'd vote for 1. As Scott stated, the container could evaluate the portlet version and it the behavior could be overridden with this parameter. If a developer gets surprised by this new behavior while intentionally developing a jsr362 portlet, it would be about time to read the spec.

Comment by Neil Griffin [ 06/Aug/13 ]

+1 for option #1. Moving forward, I think we should consider enabling new Portlet 3.0 features by default when the portlet.xml descriptor indicates "3.0" or higher. Developers would have to disable container-runtime-options in order to get backwards compatibility.





[PORTLETSPEC3-30] Add createActionURL & createRenderURL methods that allow for automatically copying parameters Created: 31/Jul/13  Updated: 29/Aug/13  Resolved: 29/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There should be two new methods in MimeResponse for creating action URLs and render URLs that conditionally allow for copying the current render parameters when the URL is created. The current createActionURL() and createRenderURL() methods would remain unchanged.

The proposal would add the following fields and methods to MimeResponse:

COPY_NO_PARAMETERS
Specifies that no parameters are to be copied when a URL is created.
COPY_RENDER_PARAMETERS
Specifies that the render parameters set for the current request be copied to the URL when it is created.

PortletURL createActionURL(int copyFlag)

Creates a portlet URL targeting the portlet. If no portlet mode, window state or security modifier is set in the PortletURL the current values are preserved. If a request is triggered by the PortletURL, it results in an action request.

The new action URL will contain private render parameters from the current request as specified by the copyFlag parameter.

The returned URL can be further extended by adding portlet-specific action parameters and portlet modes and window states. Any parameter added to the action URL is automatically an action parameter.

Public render parameters do not need to be explicitly added to the new action URL. Any public render parameters associated with the portlet will automatically be available during action request processing resulting from activation of the URL.

If an action parameter has the same name as a public render parameter, then both the action parameter value(s) and the render parameter value(s) will be available when the action request is triggered. The action parameter value(s) will appear before the render parameter value(s) in the parameter values array.

Parameters:
copyFlag - Specifies how current parameters are to be copied to the URL
Returns:
a portlet action URL
Since:
3.0
See Also:
COPY_NO_PARAMETERS, COPY_RENDER_PARAMETERS

PortletURL createRenderURL(int copyFlag)

Creates a portlet URL targeting the portlet. If no portlet mode, window state or security modifier is set in the PortletURL the current values are preserved. If a request is triggered by the PortletURL, it results in a render request.

The new render URL will contain private render parameters from the current request as specified by the copyFlag parameter.

The returned URL can be further extended by adding portlet-specific render parameters and portlet modes and window states. Any parameter added to the render URL is automatically a render parameter.

Public render parameters do not need to be explicitly added to the new render URL, unless the public render parameter value is to be changed. Any public render parameters associated with the portlet will automatically be available during render request processing resulting from activation of the URL.

If a public render parameter value is changed on a render URL, then the public render parameter will be set to the new value when the URL is activated.

Parameters:
copyFlag - Specifies how current parameters are to be copied to the URL
Returns:
a portlet render URL
Since:
3.0
See Also:
COPY_NO_PARAMETERS, COPY_RENDER_PARAMETERS



 Comments   
Comment by andre.hagemeier [ 31/Jul/13 ]

Very helpful idea. Still, the default must remain COPY_NO_PARAMETERS to verify existing implementations still work

Comment by msnicklous [ 01/Aug/13 ]

The idea is to add two new methods and leave the current ones in place. People using the JSR 286 methods will get the same behavior that they are used to. People using the new JSR 362 methods with the parameter set appropriately will get the new behavior.

So I think it should be pretty safe - developers will have to make a conscious effort in order to get the new functionality.

Comment by Neil Griffin [ 06/Aug/13 ]

+1 from Liferay, but since there are only two possible values for copyFlag, recommend renaming it to copyRenderParameters as a boolean (default false).

Comment by msnicklous [ 29/Aug/13 ]

Resolved by adding the proposed methods. See:

MimeResponse.createRenderURL(UrlFlag)
MimeResponse.createActionURL(UrlFlag)

No spec update was necessary for this issue.





[PORTLETSPEC3-29] P3PUserInfos may need clarification and could be outdated in some areas Created: 28/May/13  Updated: 30/Aug/13

Status: Open
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: clarification, identity, privacy

 Description   

First of all there seems to be an issue and missing documentation of the PortletRequest.P3PUserInfos enum.

Aside from similar observations for containers like Liferay this was discussed and answered for WebSphere Portal in late 2008
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014161216

IBM support engineer Jim Barnes replied:
>I talked with dev on this and it seems this is a errata in the spec and the toString must be called, and this will be pushed in the next >errata for the spec
>
>Jim

Specifying and documenting this properly is the minimum requirement I'd see we should cover in this JSR.

Beside I'd like to raise the question, to what extent the enum attributes are still relevant.
Fields like: USER_HOMEINFO_TELECOM_PAGER_NUMBER
while other obvious ones like
USER_HOMEINFO_ONLINE_TWITTER (or _FACEBOOK, etc.) are clearly missing in today's world.

The EG of JSR-351, Identity Management for Java discussed similar challenges, including the problem of enums and their limited extensibility as well as an often changing set of Identity Attributes that this enum and the Portlet 2.0 spec hoped to cover somehow.
I may propose synergies with JSR-351 in the "extensions" component, but wanted to mention it here, too. Potentially an area where 351 could help, but at the very least the enum vs. toString() problem should be resolved and the enum better documented. Where appropriate some attributes may be added others at least deprecated.



 Comments   
Comment by andre.hagemeier [ 31/Jul/13 ]

I wonder whether adding more fields would be the right way to go. From my point of view, custom data is retrieved by other means. I assume vendors provide APIs to access user data, like WebSPhere Portal does with PUMA. These APIs would be more powerful and flexible then any enum retrieved from the portlet request could ever be.
In the portlet4.0 spec, people might wonder, why we added twitter and facebook, because other they ceased to exist. I think, if any, the most important user features should be part of the enum (given name, last name, email, phone, birthday, etc) and the rest should be deprecated.

Comment by msnicklous [ 30/Aug/13 ]

I think we should keep this one open for now and discuss this issue when we talk about device support.





[PORTLETSPEC3-28] Add setStatus method on ResourceResponse Created: 21/May/13  Updated: 26/Aug/13  Resolved: 26/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: julien_viet Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to PORTLETSPEC3-26 Errata: Clarify that certain methods ... Resolved

 Description   

Resource serving can provide an HTTP response status with the ResourceResponse.HTTP_STATUS_CODE property. Adding a setStatus (like in javax.servlet.http.HttpServletResponse) method on the ResourceResponse that would simply delegate to the status code property would be more explicit and developer friendly, instead of:

response.addProperty(ResourceResponse.HTTP_STATUS_CODE, "404");

we would have:

response.setStatus404);



 Comments   
Comment by msnicklous [ 19/Aug/13 ]

I agree that we should add this helper method.

Comment by msnicklous [ 26/Aug/13 ]

Added method ResourceResponse.setStatus(int sc)





[PORTLETSPEC3-27] Errata: PortletMode and WindowState request during resource serving wit FULL cacheability Created: 20/May/13  Updated: 22/Aug/13  Resolved: 22/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: julien_viet Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

During a resource serving with cacheability FULL a portlet cannot access the window state and portlet mode (neither the render parameters).

The specification says is vague and say: "Thus the portlet should not access the portlet mode, window state, or render parameters in the serveResource call."

The current Javadoc does not specify anything particular , for example PortletRequest#getPortletMode() say "Returns the current portlet mode of the portlet" .

I think we lack of clarity as we don't specify what PortletRequest#getPortletMode() and PortletRequest#getWindowState() should return in this case.

I believe it should return null and we should say it clearly in the Javadoc, for example we could redeclare those methods in the ResourceRequest interface and add to the javadoc that in case of FULL cacheability then null is returned.



 Comments   
Comment by msnicklous [ 19/Aug/13 ]

See the test portlet PORTLETSPEC3_26 in portletbox for tests that exercise the setting of header information and getting the WindowState and PortletMode (issue PORTLETSPEC3-27) in the resource phase.

As it turns out, both WebSphere and Pluto return the PortletMode and WindowState information regardless of the cacheability setting on the URL.

With the parameters, it's more complicated, and there is a difference between Pluto & WebSphere.

Both portals provide the resource parameters (as opposed to render parameters) to serveResource() regardless of the cacheability setting. If cacheability is set to PORTLET or PAGE, both portals provide the public and private render parameters to serveResouce() as well.

However, if cacheability is set to FULL, WebSphere provides neither the public nor the private render parameters to serveResource(), while Pluto provides ONLY the public render parameters to serveResource(). I think this is a bug in the Pluto implementation.

But the big question is: How do we want it to be?

Is it really necessary to suppress the render parameters, the PortletMode, and the WindowState when cacheability is set to FULL? Are there use cases that require that behavior? Or does it in some manner make it easier for a portal implementation if this information is not required to be present on a resourceURL with cacheability set to FULL?

The current wording of the spec states:

FULL – The resource URL does not need to contain the current state of the page or the current render parameters, portlet mode, or window state of the portlet.

So it does not require this information to be present on a ResourceURL, but it does not forbid it, either.

Shouldn't we just require it to be present, so that the parameter, window state, and portlet mode handling would not be dependent on the cacheability setting?

I think we should answer these questions before making a clarification for this issue.

Comment by Ed Burns [ 20/Aug/13 ]

In general, I'm not fond of returning null. It's like throwing away valuable semantic information and getting back to a C-language type approach.

Maybe it's better to add a new value to the PortletMode enum?

Comment by msnicklous [ 22/Aug/13 ]

To start off with, I answered my own question - on a resource URL will cache level set to FULL, neither the render parameters nor the portlet mode or window state should be present, as their presence would reduce the ability of the URL to be cached.

Following Ed's suggestion to add a new value to the PortletMode and WindowState enum classes rather than return null, the values PortletMode.UNDEFINED and WindowState.UNDEFINED were added.

The method definitions ResourceRequest.getPortletMode() and ResourceRequest.getWindowState() were added to ResourceRequest, overriding the corresponding definitions in PortletRequest, in order to add the description about the return value when the cache level is set to FULL.

I went ahead and made the change without first posting a detailed proposal, because I felt the basic issue was clear. Naturally, if there would be reasons to modify the change, we can reopen the issue.





[PORTLETSPEC3-26] Errata: Clarify that certain methods that modify headers can only be called prior to writing to the response Created: 15/May/13  Updated: 20/Aug/13  Resolved: 20/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to PORTLETSPEC3-28 Add setStatus method on ResourceResponse Resolved

 Description   

ResourceResponse.setContentLength(int) must be set before the response is written.

The same technically holds true for:

resourceResponse.setProperty(ResourceResponse.HTTP_STATUS_CODE, Integer.toString(statusCode));

Does this merit any changes to the JavaDoc?



 Comments   
Comment by Neil Griffin [ 28/May/13 ]

If PORTLETSPEC3-28 is implemented as an improvement, then I think that this issue (PORTLETSPEC3-26) applies there as well.

Comment by msnicklous [ 19/Aug/13 ]

I agree that we should make a clarification. I'll implement a proposal and put it out for review. I would try to use descriptions similar to those provided for the corresponding HTTPServletResponse methods.

Note that the setProperty description in MimeResponse contains the following description:

void setProperty(String key,
String value)

Sets a String property to be returned to the portal.

Response properties can be viewed as header values set for the portal application. If these header values are intended to be transmitted to the client they should be set before the response is committed.

This method resets all properties previously added with the same key.

In spite of that, I'll explicitly note that the status code must be set before the response is committed in the field description for HTTP_STATUS_CODE.

I agree that this would be applicable if we implement PORTLETSPEC3-28.

See the test portlet PORTLETSPEC3_26 in portletbox for tests that exercise the setting of header information and getting the WindowState and PortletMode (issue PORTLETSPEC3-27) in the resource phase.

It's interesting that WebSphere works slightly differently than Pluto. Both allow HTTP header information to be changed after getWriter() is called and after data is written, but that is probably an accident of implementation rather than design. There are two significant differences between the Pluto and the WebSphere implementations:

1) WebSphere allows an undefined, but "good" 2xx status code (such as "235"), to be set and sent back to the client, while Pluto converts it to "200", even if the status code is set before a call to getWriter().

I think the Pluto implementation is wrong in this area, since the HTTP spec states that the status codes are to be extensible. The client is required by the HTTP spec to understand unknown 2xx status codes as being equivalent to 200.

2) Pluto doesn't seem to allow a Locale with a variant string to be set. The variant portion never gets into the HTTP content-language header.

I think Pluto is wrong here, as well.

Comment by msnicklous [ 20/Aug/13 ]

Updated apidocs with suggested changes to the following ResourceResponse fields / methods:

HTTP_STATUS_CODE
setContentLength
setLocale





[PORTLETSPEC3-25] Errata: Clarify when & how parameters are removed Created: 15/May/13  Updated: 05/Aug/13  Resolved: 26/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: Neil Griffin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This issue was split off from "PORTLETSPEC3-8 Errata: Clarify inconsistencies regarding getting and setting parameters"

  1. Under which cases (if any) should setting a parameter to a value of null remove the parameter?
  2. In which cases are public render parameters removed?


 Comments   
Comment by Neil Griffin [ 15/May/13 ]

Under which cases (if any) should setting a parameter to a value of null remove the parameter?

In both Pluto and Liferay, calling StateAwareResponse.setRenderParameter("paramName", (String) null) causes an IllegalArgumentException to be thrown, even though the JavaDocs for StateAwareResponse.setRenderParameter(String name, String value)

So with these two portlet containers, the only way remove a private render parameter (from the request map) is to remove ALL of them by calling StateAwareResponse.setRenderParameters(Map) with an empty map.

In which cases are public render parameters removed?

In Pluto and Liferay, the only way to remove a public render parameter (from the request map) is by calling StateAwareResponse.removePublicRenderParameter(String) or by removing ALL public and private by calling StateAwareResponse.setRenderParameters(Map) with an empty map.

Comment by Neil Griffin [ 15/May/13 ]

I did some additional testing, and in both Pluto and Liferay, calling StateAwareResponse.setRenderParameter("publicRenderParameter", "") works, and actually REMOVES the public render parameter from the maps. I believe that this is the expectation that Julien had during our 14 May conference call.

On Pluto, calling StateAwareResponse.setRenderParameter("privateRenderParameter", "") REMOVES the private render parameter from the maps.

On Liferay, calling StateAwareResponse.setRenderParameter("privateRenderParameter", "") sets the underlying map value to new String[]

{""}

Also during our 14 May conference call, I mentioned that JSF has a web.xml context-param feature named javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL that permits empty string request parameter values.

I don't think that any of the proposed changes would cause a problem. In general, we just need to make sure that we don't introduce incompatibilities with this JSF feature.

Comment by msnicklous [ 19/Jul/13 ]

WebSphere works like Liferay does - a null string ("") is allowed.

The Pluto behavior of removing a parameter by setting it to the null string is not described in the spec anywhere, while removing a parameter by setting it to null is described in the javadocs for StateAwareResponse.setRenderParameter(String name, String value).

I believe that a null string ("") should be allowed as a valid parameter value, while setting a private parameter to null should remove the parameter.

Public render parameters may be set through the setParameter and setRenderParameter calls, but they may not be removed by setting them to null. To remove a public render parameter, the removePublicRenderParameter method must be used.

Comment by Neil Griffin [ 23/Jul/13 ]

+1 This would mean that with both Pluto and Liferay, calling StateAwareResponse.setRenderParameter("paramName", (String) null) should not cause IllegalArgumentException to be thrown, but rather that the parameter should be removed.

Comment by msnicklous [ 26/Jul/13 ]

reworked apidocs for the set parameter methods on BaseURL and StateAwareResponse.

Comment by msnicklous [ 02/Aug/13 ]

reviewed on 20130730 and can be closed.

Comment by Neil Griffin [ 05/Aug/13 ]

@Scott: Have you pushed the JavaDoc updates to your origin? I'm not seeing them here:
http://msnicklous.github.io/portletspec3/javax/portlet/BaseURL.html#setParameter(java.lang.String, java.lang.String)
http://msnicklous.github.io/portletspec3/javax/portlet/StateAwareResponse.html#setRenderParameter(java.lang.String, java.lang.String)

Comment by Neil Griffin [ 05/Aug/13 ]

Please disregard my previous comment. I see the changes there now. Thanks Scott.





[PORTLETSPEC3-24] GenericPortlet.doHeaders(RenderRequest, RenderResponse) should throw javax.portlet.PortletException Created: 14/May/13  Updated: 10/Oct/13

Status: Reopened
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In order for a JSF 2 portlet to work in a streaming portal, the JSF lifecycle must be run from the GenericPortlet.doHeaders(RenderRequest, RenderResponse) method in order to determine the JSF 2 <script> and <link> resources that are to be included in the <head>...</head> section of the rendered portal page.

Unfortunately the signature for GenericPortlet.doHeaders(RenderRequest, RenderResponse) does not throw an exception, so if there is a problem running the JSF lifecycle, there is no way report any exceptions other than by printing the stacktrace or throwing a RuntimeException.



 Comments   
Comment by msnicklous [ 24/Aug/13 ]

Resolved this by adding IOException and PortletException to the method signature. The method doHeaders() now has the same documented exceptions as the related doDispatch(), doView(), doHelp(), and doEdit() methods that can be called during render() processing.

Also corrected a number of typos and missing/falsely named closing HTML tags that were adversely affecting the javadoc page formatting for the GenericPortlet class.

Comment by msnicklous [ 10/Oct/13 ]

I think we should talk about this one again. I got feedback that adding "throws IOException, PortletException" to the GenericPortlet.doHeaders(RenderRequest, RenderResponse) method would be an incompatible change that would break existing portlets (binary incompatibility). We probably shouldn't do that.

As an alternative, we might want to introduce a new method with a different signature like maybe:

GenericPortlet.doHeaders(HeaderRequest, HeaderResponse) throws IOException, PortletException

to accomplish the goal of allowing exceptions to be thrown.





[PORTLETSPEC3-23] Errata: Issue in GenericPortlet Exception Handling for Annotations Created: 13/May/13  Updated: 19/Aug/13  Resolved: 19/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The doView Method is defined to throw two exceptions - a PortletException
and a java.io.IOException.

-------------------------
protected void doView(RenderRequest request, RenderResponse response)
throws PortletException, java.io.IOException

{ ... }

-------------------------

However, the annotation handling code in the GenericPortlet doDispatch() method
wraps all exceptions from an annotated method as a PortletException so that
effectively a potential java.io.IOException is never thrown.

-------------------------
try {
// check if mode is cached
if ( renderModeHandlingMethodsMap.containsKey(mode) )

{ renderModeHandlingMethodsMap.get(mode).invoke(this, request, response); return; }
} catch (Exception e) { throw new PortletException(e); }
-------------------------

the processAction() and processEvent() code wraps all exceptions from annotated
methods as PortletExceptions in the same manner. The corrected exception handling
code should be something like:

Corrected:
-------------------------
try {
// check if mode is cached
if ( renderModeHandlingMethodsMap.containsKey(mode) ) { renderModeHandlingMethodsMap.get(mode).invoke(this, request, response); return; }


} catch (InvocationTargetException ex) {
// root cause
final Throwable th = ex.getCause();
// fallthru
if (th instanceof PortletException)

{ throw (PortletException) th; }

else
if (th instanceof IOException)

{ throw (IOException) th; }

else
if (th instanceof RuntimeException)

{ throw (RuntimeException) th; }

else

{ // rethrow throw new PortletException(ex); }

}
-------------------------



 Comments   
Comment by msnicklous [ 19/Aug/13 ]

updated GenericPortlet.java. Code change only; no apidoc change. See: GenericPortlet.java

Test portlet: PORTLETSPEC3_23 from portletbox.





[PORTLETSPEC3-22] Use varargs when it is possible Created: 10/May/13  Updated: 25/Aug/13  Resolved: 25/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: julien_viet Assignee: msnicklous
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Some methods of the API uses array based last argument like in BaseURL:

public void setParameter (String name, String[] values);

I suggest we could replace this by a varargs, providing the same signature and improving the usability of the API to:

public void setParameter (String name, String... values);



 Comments   
Comment by Neil Griffin [ 14/May/13 ]

+1 great flexibility

Comment by andre.hagemeier [ 31/Jul/13 ]

+1

Comment by msnicklous [ 24/Aug/13 ]

I can find the following methods where this would be useful:

BaseURL.setParameter (String name, String[] values)
PortletPreferences.setValues(String key, String[] values)
StateAwareResponse.setRenderParameter(String key, String[] values)

did I miss any?

How do you actually document a vararg argument in the javadoc comments? For example, the first line of BaseURL.setParameter reads

Sets the given String array parameter to this URL.

Should we just leave it like that?

"Sets the String vararg ..." sounds weird to me.

Comment by msnicklous [ 25/Aug/13 ]

Changed String[] parameter to String... parameter on the methods BaseURL.setParameter StateAwareResponse.setRenderParameter PortletPreferences.setValues.

I decided to call them multi-valued parameters, as in:

"Sets a multi-valued String parameter for the render request."

Hope this terminology is found to be appropriate.





[PORTLETSPEC3-21] Add a method for writing a BaseURL to a java.lang.Appendable Created: 10/May/13  Updated: 23/Aug/13  Resolved: 23/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: julien_viet Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current BaseURL interface provides capability to write to a java.io.Writer .

It would be a good thing to add the same method for a java.lang.Appendable as the appendable is an abstraction implemented by java.io.Writer but also by many other objects such as java.lang.StringBuilder.



 Comments   
Comment by Neil Griffin [ 14/May/13 ]

I suppose that the standard approach would be to @Deprecate the java.io.Writer methods, but since java.io.Writer implements java.lang.Appendable, the method signatures could simply be changed to:

BaseURL.write(java.lang.Appendable out);
BaseURL.write(java.lang.Appendable out, boolean escapeXML);

All existing code would still compile...

Comment by julien_viet [ 14/May/13 ]

We need to keep the existing method otherwise it will create binary incompatible classes for classes compiled with JSR 286 jar and executed with this API change by throwing a NoSuchMethodError on write(Ljava/io/Writer

Comment by Neil Griffin [ 14/May/13 ]

@julien_viet: You're right – I was thinking of source-compatible and not binary-compatible. Need to keep things binary compatible.

Comment by msnicklous [ 23/Aug/13 ]

Added the proposed BaseURL.write(Appendable) methods.

I did not deprecate the write(Writer) methods due to feedback that we should make it obvious to people that a method accepting a Writer exists and should be used when possible to avoid overhead associated with String / CharSequence processing.





[PORTLETSPEC3-20]  Errata: Clarification in Javadoc for an illegal scope use in PortletSession methods Created: 07/May/13  Updated: 17/Aug/13  Resolved: 17/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: julien_viet Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Some PortletSession attribute get methods do not specify their behavior when they are invoked with an unknown container scope:

  • PortletSession#getAttribute(String,int)
  • PortletSession#getAttributeNames(int)
  • PortletSession#getAttributeMap(int)
  • PortletSession#removeAttribute(String,int)

There are other methods of the PortletSession interface that must throw an IllegalArgumentException when the parameter null is provided such as PortletSession#setAttribute(String,Object,int): "java.lang.IllegalArgumentException if name is <code>null</code> or scope is unknown to the container."

We should change clarify how the getAttribute

The possible correction are:
1. the methods should fail fail with throwing an `IllegalArgumentException`
2. the methods should ignore it (return null or empty map)

The removeAttribute method should likely be corrected to 1. as the setAttribute(String,Object,int) says clearly "If the value is <code>null</code>, this has the same effect as calling
removeAttribute()".

The three other methods could use 1 or 2.



 Comments   
Comment by msnicklous [ 13/May/13 ]

I agree that this should be corrected. I think an IllegalArgumentException should be thrown in whenever the scope is unknown to the container.

Note that in the JSR 286 Javadoc for:

PortletSession#getAttribute(String,int)
PortletSession#getAttributeNames(int)

it states:

----------
Throws:
java.lang.IllegalStateException - if this method is called on an invalidated session*, or the scope is unknown to the container.*
----------

so we would be changing the type of exception thrown. But an IllegalArgumentException makes more sense to me that an IllegalStateException in this case.

For:

PortletSession#getAttributeMap(int)
PortletSession#removeAttribute(String,int)

we could just add the IllegalArgumentException when the scope is unknown to the container.

Comment by msnicklous [ 17/Aug/13 ]

updated javadoc comments in PortletSession to clarify behavior when the scope is unknown.





[PORTLETSPEC3-19] Errata: Clarify when CacheControl parameters can be set Created: 03/May/13  Updated: 26/Jul/13  Resolved: 09/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CacheControl parameters need to be set in the HTTP header before the response is
written.

Working Document 3 (22.04.13) Section "PLT.22.2 Validation Cache", page 164 line 4 states:
-------------------------
The portlet should set the validation token, expiry time or caching scope before
writing to the output stream as otherwise portals / portlet containers may ignore the
values.
-------------------------

This is correct. However, the example right below that shows such parameters being set
in the doView method:

-------------------------
protected void doView (RenderRequest request, RenderResponse response)
throws PortletException, java.io.IOException
{
...
if ( request.getETag() != null ) { // validation request
if ( markupIsStillValid(request.getETag()) ) {
// markup is still valid
response.getCacheControl().setExpirationTime(30);
response.getCacheControl().setUseCachedContent(true);
return;
}
}
// create new content with new validation tag
response.getCacheControl().setETag(someID);
response.getCacheControl().setExpirationTime(60);
PortletRequestDispatcher rd =
getPortletContext().getPortletRequestDispatcher("jsp/view.jsp");
rd.include(request, response);
}
-------------------------

In general, this example would not work. Instead, the example code should
appear in the doHeaders method, as follows:

Corrected:
-------------------------
protected void doHeaders (RenderRequest request, RenderResponse response)
{
...
if ( request.getETag() != null ) { // validation request
if ( markupIsStillValid(request.getETag()) ) {
// markup is still valid
response.getCacheControl().setExpirationTime(30);
response.getCacheControl().setUseCachedContent(true);
return;
}
}
// create new content with new validation tag
response.getCacheControl().setETag(someID);
response.getCacheControl().setExpirationTime(60);
PortletRequestDispatcher rd =
getPortletContext().getPortletRequestDispatcher("jsp/view.jsp");
rd.include(request, response);
}
-------------------------



 Comments   
Comment by msnicklous [ 09/Jul/13 ]

Updated spec document accordingly.

Comment by msnicklous [ 26/Jul/13 ]

Fix discussed on 20130723 and was accepted.





[PORTLETSPEC3-18] Provide a method in PortletConfig to query the supported portlet modes Created: 03/May/13  Updated: 02/Feb/15  Resolved: 26/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It would be good to add a method to the PortletConfig interface that would
provide the portlet modes supported my the portlet.



 Comments   
Comment by Neil Griffin [ 14/May/13 ]

+1 Always seems helpful to expose elements configured in the portlet.xml descriptor to the developer.

Comment by andre.hagemeier [ 31/Jul/13 ]

+1 why not extend this to the whole portlet descriptor? I could imagine that supported languages, portlet name, title etc might be interesting as well

Comment by msnicklous [ 26/Aug/13 ]

I think that most of the other information is available through one method or the other already. Supported languages can be obtained through Portletconfig.getSupportedLocales() and the portlet name through PortletConfig.getPortletName(). The supported processing and publishing events are available along with the supported public render parameters. The portlet title, short title, keywords, display name, etc. are available through the resource bundle (even if no real resource bundle is provided ).

What I find to be missing completely is a way of obtaining the defined and supported portlet modes and window states. You can get that information sort of indirectly through use of PortletRequest.isPortletModeAllowed(PortletMode) and PortletRequest.isWindowStateAllowed(WindowState), but you have to sort of try it out ... it isn't very elegant.

So I think we need a way to get an enumeration of the available portlet modes and window states.

It might be that we need other information in a nice API as well, but so far I haven't found anything else to be missing.

Comment by msnicklous [ 26/Aug/13 ]

Added methods:

PortletConfig.getPortletModes()
PortletConfig.getWindowStates()

Comment by msnicklous [ 02/Feb/15 ]

Implemented methods in Pluto branch V3Prototype. While doing so, I discovered an oversight - both the portlet modes and window states are dependent on the MIME type. I updated the method signatures to reflect the fact. I also added a method to obtain the public render parameter QNames, since that information wasn't available elsewhere. The method signatures are:

Enumeration<PortletMode> PortletConfig.getPortletModes(String) Enumeration<WindowState> PortletConfig.getWindowStates(String)
Map<String, QName> PortletConfig.getPublicRenderParameterDefinitions()

See:
V3.0 javadoc





[PORTLETSPEC3-17] Errata: Correction in setNextPossiblePortletModes Created: 03/May/13  Updated: 16/Aug/13  Resolved: 16/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I believe we need a correction here, see below.

Original:
-------------------------
void setNextPossiblePortletModes(java.util.Collection<PortletMode> portletModes)
-------------------------

Corrected:
-------------------------
void setNextPossiblePortletModes(java.util.Collection<? extends PortletMode> portletModes)
-------------------------



 Comments   
Comment by julien_viet [ 10/May/13 ]

I think this would be only useful if people were using PortletMode subclasses.

This makes the API (a bit) more complex to understand and does not bring much value imho.

Comment by Neil Griffin [ 14/May/13 ]

+1 Seems like a nice feature in that it adds some flexibility:

List<PortletMode> portletModes = new ArrayList<PortletMode>();
response.setNextPossiblePortletModes(portletModes);

List<ExtendedPortletMode> extendedPortletModes = new ArrayList<ExtendedPortletMode>();
response.setNextPossiblePortletModes(extendedPortletModes);
Comment by msnicklous [ 16/Aug/13 ]

Updated method signature & javadoc comment here.





[PORTLETSPEC3-16] Provide a mechanism to extend annnotation processing in GenericPortlet Created: 03/May/13  Updated: 30/Aug/13

Status: In Progress
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When extending GenericPortlet, there is currently no way to extend or reuse the
annotation processing provided by GenericPortlet. It would be good if the
GenericPortlet annotation processing could be made extensible in some manner.

One use case would be to allow support for custom portlet modes.



 Comments   
Comment by Neil Griffin [ 14/May/13 ]

I think that the simplest way to achieve this goal would be to have the private maps in GenericPortlet could be exposed with getter methods, and the getter methods could be consulted rather than accessing the private variables directly. For example:

Method actionMethod = getProcessActionMethodsMap().get(action);

instead of:

Method actionMethod = processActionHandlingMethodsMap.get(action);

Also, it would be good to change the scope of the GenericPortlet.cacheAnnotatedMethods() method from private to protected so that it can be overridden.

Comment by msnicklous [ 30/Aug/13 ]

The map methods are not synchronized, and if we make them available, portlet programmers might be tempted to change them, which might not be so good.

Instead, I propose adding the following methods to GenericPortlet:

dispatchAnnotatedActionMethod()
dispatchAnnotatedEventMethod()
dispatchAnnotatedRenderMethod()

These methods allow some flexibility, since the annotation name used does not need to be an action parameter, an event name, or a portlet mode. An arbitrary string can be used.

For example, a developer could annotate a method and access it as follows:

@RenderMode(name="George")
myRenderMethod(...) {
   ...
}

doDispatch(...) {
   ...
   boolean itWorked = dispatchAnnotatedRenderMethod("George", ...);
   if (!itWorked) {
      // show a message
   }
}

If this proposal is found to be good, I will update GenericPortlet to use these methods internally, test the changes, and update the spec appropriately in order to resolve this issue.





[PORTLETSPEC3-15] Issue in GenericPortlet Annotation Processing Created: 03/May/13  Updated: 19/Aug/13  Resolved: 16/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This problem is a bit esoteric, and I hope I can adequately present it.
It has to do with Action dispatching using annotations in the case of inheritance.

Working Document 3 (22.04.13) Section "PLT.5.4.5.1 Action Dispatching", beginning at line 8
on page 48, it states:
-------------------------
For a received action the processAction method in the GenericPortlet class tries
to dispatch to public methods annotated with the tag
@ProcessAction(name=<action name>), where the action name must be set on the
ActionURL ...
-------------------------

An attempt was made to use this feature in the following manner:
-------------------------
class PortletA extends GenericPortlet {
@ProcessAction(name="actionA")
void processMyActionAinA(ActionRequest req, ActionResponse resp)
throws PortletException, java.io.IOException;
};

class PortletB extends PortletA

{ @ProcessAction(name="actionA") void processMyActionAinB(ActionRequest req, ActionResponse resp) throws PortletException, java.io.IOException;}

;
-------------------------

Now the question is, for portlet B, which "processMyActionA" is called when actionA occurs?

We would want it to be "processMyActionAinB", I believe.

However, GenericPortlet uses .getClass().getMethods() to obtain the methods for annotation processing.

The javadoc for Class.getMethods() states:
-------------------------
Returns an array containing Method objects reflecting all the public member methods of the
class or interface represented by this Class object, including those declared by the class
or interface and those inherited from superclasses and superinterfaces. Array classes
return all the (public) member methods inherited from the Object class. The elements in the
array returned are not sorted and are not in any particular order.
-------------------------

Since GenericPortlet doesn't do any particular processing to handle methods inherited from
superclasses, it turns out that the actual method for PortletB called when actionA occurs
is not deterministic. It can be either "processMyActionAinB" or "processMyActionAinA", depending on
how .getMethods() happens to order the method array.

We may want to look into this at some point.



 Comments   
Comment by Neil Griffin [ 14/May/13 ]

I think a simple fix for the private GenericPortlet.cacheAnnotatedMethods() method would be to call Method.getDeclaringClass() to see if if that is the same as this.getClass(). If true, then it should "win" over all other candidate methods in the array.

Comment by msnicklous [ 16/Aug/13 ]

updated GenericPortlet.java. Code change only; no apidoc change. See: GenericPortlet.java

Test portlet: PORTLETSPEC3_15 from portletbox.





[PORTLETSPEC3-14] Errata: Clarification about the Portlet Title Created: 03/May/13  Updated: 02/Aug/13  Resolved: 26/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JSR 286 spec defines several ways for setting the portlet title:

1) The title can be set in a resource bundle.
2) The title can be set in the portlet-info section of the portlet descriptor.
3) The title can be set by overriding the GenericPortlet.getTitle() method.
4) The title can be set during the render headers part of the render phase

However, these are all optional ways of setting the title. It is not defined
what happens when none of them are used. In that case, WebSphere Portal, at least,
uses the <portlet-name> value from the portlet descriptor, which is mandatory.

I don't know how the RI treats this case.

Do we need to specify something here?



 Comments   
Comment by msnicklous [ 06/May/13 ]

Updated the problem priority to "minor" from "major" ... corrected an oversight on my part.

Comment by julien_viet [ 10/May/13 ]

We have a similar issue withGateIn portlet container : https://issues.jboss.org/browse/GTNPC-19 .

Portlet 1.0 did not have this issue as specifying a portlet-info section was mandatory and this part was relaxed with portlet 2.0 leading to case where nothing could be specified.

I don't know if the portlet-name is the most appropriate value (as it can be quite developer oriented), for instance if the portlet display name is available makes imho a better candidate (and it is localized).

So I think we should say that it is correct to explicit title and in that case, the portlet container is free to pickup a title using the available information and the last resort value would be the portlet name.

Comment by Neil Griffin [ 14/May/13 ]

I don't know how the RI treats this case. Do we need to specify something here?

If the <title>...</title> is missing in the portlet.xml descriptor, the Pluto throws an exception:

Error rendering portlet portlet-name-from-descriptor.
java.util.MissingResourceException: Can't find resource for bundle org.apache.pluto.driver.container.InlinePortletResourceBundle, key javax.portlet.title
at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
at java.util.ResourceBundle.getString(ResourceBundle.java:334)
at javax.portlet.GenericPortlet.getTitle(GenericPortlet.java:281)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:252)}}

Liferay throws a similar exception:

{{03:50:53,012 ERROR [http-bio-8080-exec-171][IncludeTag:253] Current URL /c/portal/render_portlet generates exception: Can't find resource for bundle com.liferay.portlet.PortletResourceBundle, key javax.portlet.title
03:50:53,014 ERROR [http-bio-8080-exec-171][IncludeTag:154] java.util.MissingResourceException: Can't find resource for bundle com.liferay.portlet.PortletResourceBundle, key javax.portlet.title
at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
at java.util.ResourceBundle.getString(ResourceBundle.java:334)
at com.liferay.portal.util.PortalImpl.getPortletTitle(PortalImpl.java:3498)
at com.liferay.portal.util.PortalUtil.getPortletTitle(PortalUtil.java:1065)}}

Using <portlet-name> as a last resort seems fine to me.

Comment by msnicklous [ 14/May/13 ]

@Neil - interesting ... it appears we have an inconsistency between the spec and the RI here. The schema for the 2.0 deployment descriptor calls for both the title and the portlet-info elements to be optional:

==========
...
<complexType name="portlet-infoType">
<sequence>
   <element name="title" type="portlet:titleType" minOccurs="0"/>
   <element name="short-title" type="portlet:short-titleType" minOccurs="0"/>
   <element name="keywords" type="portlet:keywordsType" minOccurs="0"/>
</sequence>
...
<element name="resource-bundle" type="portlet:resource-bundleType" minOccurs="0"/>
<element name="portlet-info" type="portlet:portlet-infoType" minOccurs="0"/>
<element name="portlet-preferences" type="portlet:portlet-preferencesType" minOccurs="0"/>
...
==========

I think Pluto seems to be working according to the Portlet 1.0 schema. Does it throw an exception when the entire portlet-info block is missing? If I read the portlet 1.0 schema correctly, the portlet-info block is optional, but when it is present the title element is mandatory. If Pluto is parsing according to the 1.0 schema in this point, it should not throw an exception when the entire portlet-info block is missing.

I think the 2.0 schema describes the correct behavior, and that we should mention this situation in the appropriate section in the spec. The fallback behavior if no title is specified in any manner should be something like this: "If no title is specified, the portlet container can define the portlet title using any available information, for example through use of the portlet name."

I'll look for the appropriate location in the spec, prepare a concrete change proposal, and post it here.

Comment by Neil Griffin [ 15/May/13 ]

msnicklous wrote above:

I think Pluto seems to be working according to the Portlet 1.0 schema. Does it throw an exception when the entire portlet-info block is missing?

Yes, Pluto 2.0.3 throws java.util.MissingResourceException in the following cases:

1. When the <portlet-title> element is missing
2. When the <portlet-info> block is missing

During our phone call, msnicklous asked:

Would adding a doHeaders method set the title dynamically?

Yes, on Pluto 2.0.3 adding a doHeaders() method made it possible to set the title dynamically.

BUT on Liferay, the getTitle() method is called by the page layout engine prior to the portlet lifecycle being invoked, so the doHeaders() approach does not work in Liferay.

Comment by Neil Griffin [ 15/May/13 ]

Test Portlet: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-14-portlet

Comment by msnicklous [ 19/Jul/13 ]

As mentioned previously, it seems that according to the deployment descriptor schema, the <portlet-info>, <portlet-title> and <resource-bundle> elements are all optional, even though the Pluto implementation does not treat them as being optional.

My take is that Pluto has a bug in this area, and that the elements should be handled as being optional. As a clarification, I propose the following change in the spec.

Referring to the [latest version of the working document] (https://java.net/projects/portletspec3/downloads/download/WorkingDocs/PortletSpec3-20130708.pdf):
On page 52 after line 16 add the following paragraph:
=====
The <portlet-info> and <resource-bundle> elements are optional in the deployment descriptor. If neither are present, the portlet title will not be explicitly defined. In this case, the portlet container can draw on other information, for example on the <portlet-name> or <display-name> values from the portlet descriptor, to define the portlet title.
=====

Comment by Neil Griffin [ 23/Jul/13 ]

@msnicklous: Just to clarify, if neither are present, then it is left as an implementation detail?

Comment by msnicklous [ 26/Jul/13 ]

implemented fix in spec.

Comment by msnicklous [ 02/Aug/13 ]

reviewed on 20130730 and can be closed.





[PORTLETSPEC3-13] Two extensions for BaseURL Created: 03/May/13  Updated: 29/Aug/13  Resolved: 28/Aug/13

Status: Resolved
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GIF File NamedAnchor-FragmentIdentifier.gif    

 Description   

Add methods to the BaseURL class to provide additional function.

1) add a way to manage fragment identifiers in URLs in order to be able to create URLs such as:

http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.1.2

void setFragmentIdentifier(String)
String getFragmentIdentifier()

2) add a method to create URLs that required the user to log in before they can access the URL

void setProtected(Boolean)



 Comments   
Comment by julien_viet [ 10/May/13 ]

I am in favor of this, however I think we should not use the "protected" name as it is a reserved java keyword and that could raise issues with scripting language such as Groovy that supports natively properties (i.e write url.protected = true).

We have similar concern with GateIn portlet container and we named it "authenticated".

Comment by msnicklous [ 13/May/13 ]

I agree on the naming. So then it would become:

2) add a method to create URLs that required the user to log in before they can access the URL

void setAuthenticated(Boolean)

Comment by Neil Griffin [ 14/May/13 ]

+1 these are very nice additions.

The term fragment identifier is used by the HTML spec but I wonder if getNamedAnchor/setNamedAnchor would be more meaningful to portlet developers?

Comment by andre.hagemeier [ 31/Jul/13 ]

Why would the wording "fragment identifier" be a problem? That's basically what the idea is about, isn't it?

Comment by Neil Griffin [ 13/Aug/13 ]

My impression is that "named anchor" is a term that would be more easily recognized by developers.

Comment by msnicklous [ 23/Aug/13 ]

Google trend information about terms "Fragment Identifier" and "Named Anchor". Original information found here

Comment by msnicklous [ 23/Aug/13 ]

Based on info from Google trends, it looks like "Named Anchor" would win out. Neither term is particularly popular compared to "Ben Affleck" for example, but quite a few more people seem to search for "named anchor" than for "fragment identifier".

(Note that I wasn't able to use the "embed" string provided by Google, because Jira doesn't let me paste script into the post. But you can follow the link above to view the original data.)

On the other hand, "fragment identifier" is the official technical term that can be found in RFC 3986 and other technical literature, while "named anchor" tends more towards web site design (imho). And the fragment identifier can also be used for more than just addressing a named HTML anchor tag - it could provide additional information on a resource URL, for example.

So I am kind of partial to using the precise term as the method name, but explaining it to be a named anchor in the description.

I would also note that adding a fragment identifier to a render URL or a resource URL makes sense, but adding one to an action URL not so much. For now, I would add setFragmentIdentifier to BaseURL, but if we decide to add dedicated interfaces for ActionURL and RenderURL, I would move setFragmentIdentifier to RenderURL and ResourceURL, just for the sake of clarity.

And naturally setAuthenticated makes sense for all URLs, so it clearly belongs in BaseURL.

Comment by msnicklous [ 23/Aug/13 ]

Here are my concrete proposals:

1) for set authenticated

void setAuthenticated(boolean authenticated)

Indicates whether authentication is required for this URL.

When the parameter is set to true, user authentication will be required when accessing the URL. A setting of false indicates that authentication will not be required.

If authentication is not explicitly set on the URL through this method, the default will be true if PortletRequest.getAuthType() indicates that the current request is authenticated and false if the current request is not authenticated.

Parameters:
authenticated - true, if the URL requires authentication. false, if the URL does not require authentication.
Since:
3.0

boolean getAuthenticated()

Returns the authentication setting for the URL.

Returns:
true if the URL requires authentication
Since:
3.0

2) for the fragment identifier

void setFragmentIdentifier(String fragment)

Sets a fragment identifier on the URL.

The fragment identifier consists of additional information appended to the URL after a '#' character. A URL can have only a single fragment identifier. The fragment identifier may not contain the '#' character.

The fragment identifier is often used to address a named anchor such as <a name="#fragmentIdentifier">, but it can also be used for other purposes such as to provide additional information for resource serving.

The fragment identifier will not be namespaced. The portlet is responsible for performing any required namespacing.

Any previously set fragment identifier will be replaced.

Parameters:
fragment - The fragment identifier to be added to the URL
Throws:
IllegalArgumentException - if the fragment identifier is null, the empty string (""), or contains the '#' character.
Since:
3.0

String getFragmentIdentifier()

Gets the fragment identifier set on the URL.

Returns:
The fragment identifier set on the URL, or null if no fragment identifier has been set.
Since:
3.0

Comment by msnicklous [ 28/Aug/13 ]

Resolved by adding several methods to BaseURL:

setAuthenticated
getAuthenticated
setFragmentIdentifier
getFragmentIdentifier
permitFragmentIdentifier
fragmentIdentifierPermitted

Handling the fragment identifier was more complicated than I initially anticipated. I ended up introducing two additional API methods that we hadn't discussed - I apologize for that. I should have thought more carefully before I committed. I should have posted the proposals in the issue in order to allow discussion and perhaps look for alternatives.

Anyway, the background is that a portal can set the fragment identifier on portlet URLs (WebSphere does so in certain situations). That isn't wrong or non-compliant, since JSR286 doesn't mention fragment identifiers at all, and since the fragment identifier is never transported back to the server.

The basic idea behind the latter four APIs in the list above is to allow the portal implementation to append a fragment identifier to a portlet URL if the portlet itself isn't using it. In addition, it should be possible for a portlet to explicitly request that absolutely no fragment identifier gets appended to a URL, even if the portlet itself is not using it.

It seemed to best to implement both of the ideas of the getting / setting of the fragment identifier and the permitting / suppression of the fragment identifier by introducing the two pair of getter / setter methods - setFragmentIdentifier/getFragmentidentifier and permitFragmentIdentifier/fragmentIdentifierPermitted.

I also updated the corresponding section in the spec - please see link.

If there is need for discussion on this point, please reopen and we can discuss.

Comment by Neil Griffin [ 28/Aug/13 ]

For JavaBean getter/setting consistency, should the permitFragmentIdentifier and fragmentIdentifierPermitted methods be named isFragmentIdentifierPermitted() and setFragmentIdentifierPermitted(boolean) respectively?

Comment by msnicklous [ 29/Aug/13 ]

good idea, thanks for the feedback! implemented. See:

setFragmentIdentifierPermitted
isFragmentIdentifierPermitted





[PORTLETSPEC3-12] Errata: Clarify use of Portlet 1.0 Tag Library in v2.0 Portlets Created: 03/May/13  Updated: 26/Jul/13  Resolved: 09/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Chapter PLT.26 contains a statement that the v2.0 portlet container must support the
V1.0 tag library in order to support V1.0 portlets. However, it does not mention whether
V2.0 portlets using the V1.0 tag library should be supported. See text below.

Working Document 3 (22.04.13) Section "PLT.26 Portlet Tag Library", lines 17-20 on page 207:
-------------------------
In order to support Java Portlet Specification V1.0 portlets that references the V1.0
tag library via
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>
the portlet container must also support the V1.0 tag library defined in JSR 168.
-------------------------

My take would be that we should be as permissive as possible in this case, and allow
the use of the V1.0 tag library with V2.0 portlets, should anybody wish to do so. I
propose an addition to the text as follows:

Corrected:
-------------------------
In order to support Java Portlet Specification V1.0 portlets that reference the V1.0
tag library via
<%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>
the portlet container must also support the V1.0 tag library defined in JSR 168.

Java Portlet Specification 2.0 Portlets may reference the V1.0 library.
-------------------------



 Comments   
Comment by msnicklous [ 09/Jul/13 ]

Updated spec document accordingly.

Comment by msnicklous [ 26/Jul/13 ]

Fix discussed on 20130723 and was accepted.





[PORTLETSPEC3-11] Create single interface to handle public and private render parameters Created: 03/May/13  Updated: 30/Jul/13

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The StateAwareResponse and BaseURL interfaces both allow setting and getting public and private render parameters.
However they use different method names to do the same job. I suggest introducing a new interface that
represents the aspect of handling parameters and to have both the StateAwareResponse and the
BaseURL interfaces extend this new interface. This would make it much simpler to write state handling code,
and would make it easier to keep the semantics consistent.



 Comments   
Comment by msnicklous [ 06/May/13 ]

Updated the problem priority to "minor" from "major" ... corrected an oversight on my part.

Comment by julien_viet [ 10/May/13 ]

I don't see how that is technically possible since:

1/ StateAwareResponse class has methods named "render parameter" such as setRenderParameters(String key, String value)

2/ BaseURL class has methods named "parameter" such as setParameter(String name, String value)

Comment by msnicklous [ 13/May/13 ]

We would have to include both setRenderParameters and setParameters in the new interface, and deprecate one of them. The point is that the parameters don't really differ conceptually (at leaset as I understand it so far), so we shouldn't have two different method names for setting / getting the same thing.

Comment by Neil Griffin [ 14/May/13 ]

I like the idea of a separate interface very much, but perhaps it could be left as an implementation detail.

It might be that I am simply accustomed to the existing API, but it seems like:

response.setRenderParameter("foo", "1234");

seems to self-document a little better than:

response.setParameter("foo", "1234");

meaning that the parameter is intended for the render request (in some sense).





[PORTLETSPEC3-10] Errata: Clarify setting parameters on Resource URLs Created: 03/May/13  Updated: 02/Aug/13  Resolved: 26/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Referring to Working Document 3 (22.04.13) Section "PLT.7.1.1 BaseURL Interface",
lines 14-16 on page 55, it is stated:

-------------------------
When creating a ResourceURL the current render parameters are
automatically added to that URL by the portlet container, but are hidden to the
getParameter calls of the portlet URL object.
-------------------------

My assumption would be that since the render parameters are hidden, they cannot be
removed. Would this be correct? Can existing render parameters on resource URLs be set?

Section "PLT.11.1.1.4 Resource Request Parameters", page 75, line 29 states the following,
so it appears that at minimum, new render parameters may be added to Resource URLs.

-------------------------
For serveResource requests the portlet must receive any resource parameters that
were explicitly set on the ResourceURL that triggered the request.
-------------------------

Since ResourceURL extends BaseURL, and since BaseURL defines get / set parameter
methods, we may need addition clarification in the description of the BaseURL class.



 Comments   
Comment by Neil Griffin [ 14/May/13 ]

My assumption would be that since the render parameters are hidden, they cannot be removed. Would this be correct?

The following causes an IllegalStateException on Pluto, even though the JavaDoc for BaseURL.setParameter(String, String) indicates that the URL parameter should be removed when null is passed:

ResourceURL.setParameter("publicRenderParam", (String) null);

Can existing render parameters on resource URLs be set?

The following is a no-op on Pluto during the RENDER_PHASE (meaning that the existing value of the Public Render Parameter is preserved in the string representation of the resource URL, instead of the overridden value of "abcd"):

ResourceURL.setParameter("publicRenderParam", "abcd");

But in the RESOURCE_PHASE, it works, meaning the string representation of the resource URL contains the overridden value of "abcd".

Comment by Neil Griffin [ 15/May/13 ]

Test Portlet: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-10-portlet

Comment by msnicklous [ 26/Jul/13 ]

reworked apidocs to clarify how parameters are set.

Comment by msnicklous [ 02/Aug/13 ]

reviewed on 20130730 and can be closed.





[PORTLETSPEC3-9] Errata: Clarification needed for method MimeResponse.createRenderURL Created: 02/May/13  Updated: 13/Aug/13  Resolved: 02/Aug/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: errata, jsr286

 Description   

The description contains a statement that I believe to be incorrect. It states:

"The created URL will per default not contain any parameters of the current render request."

However, the created URL I believe must contain any public render parameters that were set on
the request. Also, the term "current render request" may be misleading. What is meant is the
request that is being executed when the URL is created.

So I would propose the following update:

Original:
-------------------------
createRenderURL

PortletURL createRenderURL()

Creates a portlet URL targeting the portlet. If no portlet mode, window state or security modifier is set in the PortletURL the current values are preserved. If a request is triggered by the PortletURL, it results in a render request.

The returned URL can be further extended by adding portlet-specific parameters and portlet modes and window states.

The created URL will per default not contain any parameters of the current render request.

Returns:
a portlet render URL
-------------------------

Corrected:
-------------------------
createRenderURL

PortletURL createRenderURL()

Creates a portlet URL targeting the portlet. If no portlet mode, window state or security modifier is set in the PortletURL the current values are preserved. If a request is triggered by the PortletURL, it results in a render request.

The returned URL can be further extended by adding portlet-specific parameters and portlet modes and window states.

The created URL will per default contain only the public render parameters from the request
being executed when the render URL is created.

Returns:
a portlet render URL
-------------------------

The same change should be made for the MimeResponse.createActionURL method.



 Comments   
Comment by msnicklous [ 03/May/13 ]

Updated the description to address the "current render request" aspect.

Comment by Neil Griffin [ 14/May/13 ]

I determined that Liferay's portlet container currently implements the existing requirement, meaning that the result of MimeResponse.createRenderURL() does "not contain any parameters of the current render request"

However, Pluto does not implement the existing requirement. Instead, it implements the proposed change such that it contains "only the public render parameters from the request being executed when the render URL is created"

The proposed changed would have almost no impact on JSF 2 portlets, since they rarely make use of render URLs.

It might have more impact on Java/JSP based portlets, where developers tend to use <portlet:renderURL /> somewhat regularly.

Does the portlet developer want the public render parameters to continue getting propagated? I can see a case for both yes and no. I guess it depends on what we consider the main use-case to be.

Comment by Neil Griffin [ 15/May/13 ]

Test Portlet: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-9-portlet

Comment by rossclewley [ 21/May/13 ]

I've tried Neil's test portlet on the Oracle portlet container and it implements the current requirement that MimeResponse.createRenderURL() does "not contain any parameters of the current render request". i.e. the same as Liferay.

Comment by msnicklous [ 30/Jul/13 ]

I propose the following changes to the javadoc descriptions of the createRenderURL, createActionURL, and createResourceURL methods on the MimeResponse class:

PortletURL createRenderURL()

Creates a portlet URL targeting the portlet. If no portlet mode, window state or security modifier is set in the PortletURL the current values are preserved. If a request is triggered by the PortletURL, it results in a render request.

The new render URL will not contain any private render parameters from the current request.

The returned URL can be further extended by adding portlet-specific render parameters and portlet modes and window states. Any parameter added to the render URL is automatically a render parameter.

Public render parameters do not need to be explicitly added to the new render URL, unless the public render parameter value is to be changed. Any public render parameters associated with the portlet will automatically be available during render request processing resulting from activation of the URL.

If a public render parameter value is changed on a render URL, then the public render parameter will be set to the new value when the URL is activated.

Returns:
a portlet render URL

PortletURL createActionURL()

Creates a portlet URL targeting the portlet. If no portlet mode, window state or security modifier is set in the PortletURL the current values are preserved. If a request is triggered by the PortletURL, it results in an action request.

The new action URL will not contain any private render parameters from the current request.

The returned URL can be further extended by adding portlet-specific action parameters and portlet modes and window states. Any parameter added to the action URL is automatically an action parameter.

Public render parameters do not need to be explicitly added to the new action URL. Any public render parameters associated with the portlet will automatically be available during action request processing resulting from activation of the URL.

If an action parameter has the same name as a public render parameter, then both the action parameter value(s) and the render parameter value(s) will be available when the action request is triggered. The action parameter value(s) will appear before the render parameter value(s) in the parameter values array.

Returns:
a portlet action URL

ResourceURL createResourceURL()

Creates a resource URL targeting the portlet. If no security modifier is set in the ResourceURL the current values are preserved. The current render parameters, portlet mode and window state are preserved depending on the cacheability setting for the new resource URL.

If a request is triggered by the ResourceURL, it results in a serve resource request of the ResourceServingPortlet interface.

If cacheability is set to PORTLET or PAGE, the values of the render parameters are preserved. Otherwise, the render parameters will not be preserved.

The public and private render parameters are added to the URL with their current value. The render parameter values cannot be changed on the URL.

The returned URL can be further extended by adding portlet-specific resource parameters. Any parameter added to the resource URL is automatically a resource parameter. If a resource parameter has the same name as a public or private render parameter, then both the resource parameter values and the render parameter values will be available when the resource request is triggered. The resource parameter value(s) will appear before the render parameter value(s) in the parameter values array.

The created URL will contain the current cacheability setting of the parent resource by default. If no parent resource is available, PAGE is the default.

Returns:
a portlet resource URL

Comment by Neil Griffin [ 30/Jul/13 ]

Recommend using either "The new" or "The returned" in a consistent manner. Currently both terms are used very close together, though they refer to the same thing.

Also, the general term "render parameter" is meaningful when it refers to either Public/Private Render Parameters that the portlet developer has explicitly set via StateAwareResponse.setRenderParameter(String name, String value). These are parameters that are set in the ACTION_PHASE/EVENT_PHASE and intended to survive into the RENDER_PHASE.

However I think that the general term "render parameters" becomes vague/ambiguous when referring to parameters set on a URL. While it is true that a Public Render Parameter can be set on a URL, I don't think we can precisely say Private Render Parameters can be set on a URL. Rather, they are simply Private Parameters (not Private Render Parameters) when set on a URL.

Because of this, I would recommend that the following sentence be clarified or perhaps not added:

Any parameter added to the render URL is automatically a render parameter.

Comment by msnicklous [ 30/Jul/13 ]

Hi Neil,

I tried to be precise in my use of the term "render parameter" - that's (supposed to be) part of the actual clarification. I believe that parameters set on a render URL are actually render parameters, since clicking on a render URL will result in a render request. In the descriptions of createActionURL & createResourceURL, I used the terms "action parameters" and "resource parameters" correspondingly.

Comment by msnicklous [ 02/Aug/13 ]

Updated Javadoc comments on URL creation methods in MimeResponse.

Comment by Neil Griffin [ 05/Aug/13 ]

@Scott: Thanks for the clarification. Sounds good.

Comment by msnicklous [ 13/Aug/13 ]

changes reviewed on 6 Aug 2013





[PORTLETSPEC3-8] Errata: Clarify inconsistencies regarding getting and setting parameters Created: 02/May/13  Updated: 13/Aug/13  Resolved: 13/Aug/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reading the spec document on parameters and comparing it with the javadoc on
"get...Parameter..." and "set...Parameter..." calls on various Response, Request, and
URL classes, it seems to me that there are a number of inconsistencies that should
be addressed, for example:

  1. Is a parameter allowed to have a value of null?
  2. Under which cases (if any) should setting a parameter to a value of null remove the parameter?
  3. In which cases exactly are public parameters get and set?
  4. In which cases are public render parameters set or updated?
  5. In which cases are public render parameters removed?
  6. Should the "getParameterMap" methods always return an immutable map?
  7. probably more that I haven't noticed yet ...

To #6 -

The javadoc for PortletRequest.getParameterMap states:
-------------------------
    Returns:
        an immutable Map containing parameter names as keys and parameter values as map 
        values, or an empty Map if no parameters exist. 
        The keys in the parameter map are of type String. 
        The values in the parameter map are of type String array (String[]).
-------------------------

While the javadoc for BaseURL.getParameterMap states:
-------------------------
Returns:
    Map containing parameter names as keys and parameter values as map 
    values, or an empty Map if no parameters exist. 
    The keys in the parameter map are of type String. 
    The values in the parameter map are of type String array (String[]).
-------------------------

Shouldn't the returned Map values be consistently immutable?

If not, and if we want to be able to update the actual parameters by updating the
Map returned by BaseURL.getParameterMap, it needs to be described clearly.



 Comments   
Comment by Neil Griffin [ 13/May/13 ]

Regarding #1 - #5, I would recommend creating separate issues.

Regarding #6, I checked the Liferay and Pluto source code, and neither return an immutable map. It is possible that portlet developers have been calling BaseURL.getParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible.

Comment by msnicklous [ 15/May/13 ]

We discussed this issue, made some progress, but also identified areas where more work is needed.

A new issue will be opened to look at the following points in more detail:

  • Under which cases (if any) should setting a parameter to a value of null remove the parameter?
  • In which cases are public render parameters removed?

The following points were cleared up:

  • Should the "getParameterMap" methods always return an immutable map?
    • No, that would break existing code
    • No action necessary

The following point needs to be examined in more detail:

  • Is a parameter allowed to have a value of null?
    • No, a parameter may not have a null value
    • This may need clarification in the javadoc / spec - need to have a look
  • In which cases are public render parameters set or updated?
Comment by Neil Griffin [ 15/May/13 ]

For the following questions:

Under which cases (if any) should setting a parameter to a value of null remove the parameter?

In which cases are public render parameters removed?

See: PORTLETSPEC3-25

Comment by Neil Griffin [ 15/May/13 ]

Test Portlet for this issue: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-8-portlet

Comment by mfreedma [ 21/May/13 ]

On your statement:

"The following points were cleared up:

Should the "getParameterMap" methods always return an immutable map?
No, that would break existing code
No action necessary"

I agree that map returned is mutable. I disagree if we/the developer expects that manipulating this Map directly impacts the BaseURL. Rather we/developer should manipulate this Map and the call baseURL.setParameters(Map). Right?

Comment by Neil Griffin [ 28/May/13 ]

@Mike: It looks like Scott has fortified the PORTLETSPEC3-8 test portlet with a test for this.

There are two new buttons:

  • Button with label "actionURL.setParameters() before" (test 12)
  • Button with label "actionURL.setParameters() after" (test 13)

On Pluto, clicking on these buttons does not affect the toString() value of the ActionURL that is rendered in the subsequent portal page. I think that this confirms your statement:

I disagree if we/the developer expects that manipulating this Map directly impacts the BaseURL.

On Liferay, clicking on these buttons does indeed affect the toString() value. Because of this, my preference would be that interpretation be left to the implementation, rather than tighten-up the Spec requirement.

I'd be interested to know what happens in other implementations.

Comment by msnicklous [ 26/Jul/13 ]

I believe the only remaining open point here is whether an an update to the map returned by one of the get parameter map functions should directly cause an update to the actual underlying parameters. In other words, should the following code actually change the parameters:

String[] values = { "Fred", "Wilma", "Pebbles" };
actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);

My take would be that by itself no, it should not. The correct code should be:

String[] values = { "Fred", "Wilma", "Pebbles" };
Map<String, String[]> parmMap = actionResponse.getRenderParameterMap();
parmMap.put("privateRenderParameter3", values);
actionResponse.setRenderParameters(parmMap);

I would suggest the following change for the getRenderParameter map method and corresponding updates for the getParameterMap method on BaseURL:

Map<String,String[]> getRenderParameterMap()

Returns a Map of the parameters currently set on this portlet URL via the setParameter or setParameters methods.

Contents of this map may be modified, but modifying the map does not directly affect the render parameters. In order to set the
parameters to the values in the modified map, the setRenderParameters(Map) with the modified map as a parameter must be used.

The keys in the returned map are of type String, and the values are of type String array (String[]).

If no parameters exist this method returns an empty Map.

Returns:
    Map containing parameter names as keys and parameter values as map values, or an empty Map if no parameters exist. The keys in the parameter map are of type String. The values in the parameter map are of type String array (String[]).
Comment by Neil Griffin [ 30/Jul/13 ]

Regarding the following sentence:

Contents of this map may be modified, but modifying the map does not directly affect the render parameters. In order to set the parameters to the values in the modified map, the setRenderParameters(Map) with the modified map as a parameter must be used.

Using the "Set Parms direct Map #1" (case 4) and "Set Parms direct Map#2" (case 5) buttons, I found that modifying the following code will indeed cause the underlying map to be changed on Liferay Portal:

actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);

It is possible that portlet developers have been calling getRenderParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible.

Because of this, my vote would be that interpretation be left to the implementation, rather than tighten-up the Spec requirement. Therefore I would recommend changing part of the sentence to the following:

"modifying the map is implementation dependent and therefore may or may not directly affect the render parameters. In order to guarantee that the modified map affects the render parameters, the setRenderParameters(Map) with the modified map as a parameter must be used."

Comment by msnicklous [ 31/Jul/13 ]

Note that Pluto does not allow the parameters to be changed through the map directly. The map obtained from getRenderParameterMap() can be updated,
but the updates are ignored without the setParameters() call. So Pluto behaves according to the proposed change.

WebSphere allows a parameter update directly through the map ... sometimes. Namely, if the map is initially empty, it cannot be updated. If a private parameter has been set previously
so that the map is non-empty, a direct parameter update through the map will be allowed. This seems to me to be an "accident of implementation".

It would be good if we could understand how other implementations work and see if we can come to a conclusion on this.

Comment by msnicklous [ 31/Jul/13 ]

Neil,

I see that I was working on an stale copy of the Jira issue when I made my update, and I hadn't seen your update. Thanks for posting how Liferay works in this area.
It might indeed be best to leave that point as an implementation detail.

Comment by andre.hagemeier [ 31/Jul/13 ]

Neil,
"Regarding #6, I checked the Liferay and Pluto source code, and neither return an immutable map. It is possible that portlet developers have been calling BaseURL.getParameterMap().put(name, value) in order to set values, and changing to an immutable map would cause legacy applications to be non-backward-compatible."

I have seen this being done, and I have done it personally. E.g. I implemented a preprocessor to pass url parameters as PRP to Portlets under certain circumstances. So restricting this point would break existing implementations.

In addition, Scott,:
"String[] values =

{ "Fred", "Wilma", "Pebbles" };
actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);
My take would be that by itself no, it should not. The correct code should be:

String[] values = { "Fred", "Wilma", "Pebbles" }

;
Map<String, String[]> parmMap = actionResponse.getRenderParameterMap();
parmMap.put("privateRenderParameter3", values);
actionResponse.setRenderParameters(parmMap);"

With that, you would enforce immutable maps. Although I would favor the second approach as well, making the first one impossible would break existing code. Since the first approach cannot be deprecated (as you would have to deprecate a method from java.util.Map), sth like this could be done:

public class DeprecatedMutableMap<String, String[]> extends HashMap<String, String[]> {
@Override
public boolean put(String name, String[] values)

{ logger.warn("calling the put method on this map instance is deprecated. Better use ..."); return super.put(name, values); }

}

Just a rough idea. But that would be highly vendor specific, so it actually would not have to be related to the JSR. The JSR would only have to specify, that setting the render parameter directly should not be possible (and if it is already, it should at least be deprecated).

Comment by msnicklous [ 01/Aug/13 ]

I gave this more thought, and I think we have to work our way through the ideas and specify this, one way or the other. I don't think we can leave it as an implementation detail.

With the portlet title issue, where we said if the title is not specified in the portlet descriptor, it's up to the implementation to determine the title,
it wasn't critical, because the implementation could decide to leave it empty, just call the portlet "Bob", or do something maybe more sensible. It wouldn't
break the portlet.

However, leaving the map issue up to the implementation will result in a real incompatibility, where a portlet written to assume that changing the map changes the parameters would
not work on a portlet container that does not support that (for example, it wouldn't work on the current reference implementation).

I understand the point about the map on many implementations currently being mutable and directly effecting a change in the parameters. However, if we leave the map like this, we run into other issues.

Earlier we agreed on certain rules for the portlet parameters: A parameter may not have a null value, but it can have the empty string as a value. Setting a public
render parameter to null does not remove the public render parameter; the removePublicRenderParameter() method must be used to remove it. Not including a public render parameter
in the map passed to setRenderParameters() does not mean that the public render parameter is removed.

If we stick with these rules (and I believe we should), then the map returned by getParameters() or getRenderParameters() would have to enforce these rules as well.
It looks to me like this would lead to a custom map implementation in any case.

I do not believe we could just say, "well, we have these rules about parameters, but if you get a map through getRenderParameters() you can do whatever the map happens to allow."

And would we really want to say that setting a parameter within the map to null would remove it? That would be .... ugly in imho. But that might be just my personal feeling of aesthetics.

In light of this, I thought it would be cleaner to force the map to be passed to setParameters() and setRenderParameters() in order for the new values to take effect. the setParameters() call could then enforce the parameter rules.

Andre - I don't think the proposal above would mean that the map is immutable. The map could still be changed. It would just no
longer directly effect a change in the actual parameters - this is the way it currently works on Pluto.

Comment by andre.hagemeier [ 01/Aug/13 ]

Scott,
i think whether this map is immutable or not depends on the point of view. I assume your point of view is:
The map is not immutable since you can actually change its values, and once you set this map with setRenderParameters(), it will take effect.

My point of view:
The map is immutable, because i cannot change the values of the parameters of this specific map (or at least is has no effect). I need create a new map or use the same map to re-initiate the values of the backed map.

With your example:

params.java
String[] values = { "Fred", "Wilma", "Pebbles" };
actionResponse.getRenderParameterMap().put("privateRenderParameter3", values);
// this way, you could directly change the values of the prp map. You will not receive a clone, but the real backed map, so any change to this map is directly reflected in the request

String[] values = { "Fred", "Wilma", "Pebbles" };
Map<String, String[]> parmMap = actionResponse.getRenderParameterMap();
parmMap.put("privateRenderParameter3", values);
actionResponse.setRenderParameters(parmMap);"
// most likely you will receive a clone of the internal map here. otherwise you would not have to call setRenderParameters, but could just use the first approach.
// the setRenderParameters method would then iterate over the paramMap and put its names and values to the internal map of the request

//this is basically the same, as if I created a totally new map and copied all existing values. //There is just no reference to the map instance
String[] values = { "Fred", "Wilma", "Pebbles" };
Map<String, String[]> parmMap = new HashMap<String, String[]>();
copy(actionResponse.getRenderParameterMap(), parmMap);
parmMap.put("privateRenderParameter3", values);
actionResponse.setRenderParameters(parmMap);"

To me, the second approach is immutable, because changing the returned map has no effect. Only, if I use the returned map and set it using setRenderParameters, the change will take effect. But that would happen due to the fact, that all names and values are copied to the internal map of the request.

The only thing, I want to make sure, is that existing implementations still work. Since the methods mentioned don't exist in portlet2.0, i assume, that the old ones will be deprecated, but still be available. And with that getParameterMap needs to return a mutable map, so that
request.getParameterMap().put(x,y) will still work, even if it Eclipse will show a warning, because getParameterMap may be deprecated.

Apart from that, as I said, I agree, that the second way would be the more accurate.

Comment by msnicklous [ 01/Aug/13 ]

Andre, sorry, don't really follow you. All methods listed currently exist. In fact, the code in the examples is copy/pasted from test portlets that were run with
varying degrees of success against several portal implementations. Nothing would be deprecated.

I don't think we should make assumptions about the internal implementation of a portlet container. We just need to describe external behavior.

Comment by andre.hagemeier [ 01/Aug/13 ]

Sorry Scott, I guess I mixed up some things here.
The only question to me is, what to do with the spec and the implementations. I think the implementations cannot be forced to return immutable maps.
So two possibilities would be left:

  • allow mutable maps in the spec
  • deprecate mutable maps in 362 (but still allow them for backward compatibility) and make immutable ones the default. Therefore, a subclassing approach could be used like above stated.

Anyway, this issue needs to be documented properly, to make clear why there is a problem at all.

Comment by Neil Griffin [ 06/Aug/13 ]

@Scott: I received feedback from my colleagues, and the unanimous response was to have StateAwareResponse.getRenderParameterMap() return an immutable map. This would make the API more clear that the only way to set parameters (with a Map) would be to call StateAwareResponse.setRenderParameters(java.util.Map).

Comment by msnicklous [ 13/Aug/13 ]

implemented updates for descriptions of BaseURL.getParameterMap() and StateAwareResponse.getRenderParameterMap().





[PORTLETSPEC3-7] Errata: Clarify Inconsistency about Removing Shared Render Parameters Created: 02/May/13  Updated: 05/Aug/13  Resolved: 26/Jul/13

Status: Closed
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Referring to Working Document 3, Section "PLT 11.1.2 Public Render Paramaters" states on
page 77, beginning on line 22 the following:

"If a portlet wants to delete a public render parameter it needs to use the
removePublicRenderParameter method on the StateAwareResponse or the
PortletURL."

Judging from this section, it would seem like public render parameters can only
be removed using this method.

However, in the javadoc for StateAwareResponse.setRenderParameters it is stated:

-------------------------
setRenderParameters

void setRenderParameters(java.util.Map<java.lang.String,java.lang.String[]> parameters)

    Sets a parameter map for the render request.

    All previously set render parameters are cleared.

    These parameters will be accessible in all sub-sequent render calls via the PortletRequest.getParameter call 
    until a new request is targeted to the portlet.

    The given parameters do not need to be encoded prior to calling this method.

    The portlet should not modify the map any further after calling this method.

    Parameters:
        parameters - Map containing parameter names for the render phase as keys and parameter values as map values. 
        The keys in the parameter map must be of type String. The values in the parameter map must be of type String array (String[]). 
    Throws:
        java.lang.IllegalArgumentException - if parameters is null, if any of the keys in the Map are null, 
        if any of the keys is not a String, or if any of the values is not a String array. 
        java.lang.IllegalStateException - if the method is invoked after sendRedirect has been called.
-------------------------

In particular, it states that "All previously set render parameters are cleared." without
explicitly taking public and private parameters into account.

What happens when the new map provided to setRenderParameters changes or maybe even does not contain
a public render parameter that was set on the corresponding request? Should that public render parameter
be changed or removed?

Also, can individual entries in the value string[] be null? if so, what would that mean?
In general, can parameters have a value of null?

We need to decide how it should behave. My take would be to update the javadoc for
StateAwareResponse.setParameters as follows:

Corrected:

-------------------------
setRenderParameters

void setRenderParameters(java.util.Map<java.lang.String,java.lang.String[]> parameters)

    Sets a parameter map for the render request.
MSN UPDATE==>    The new paramater map applies to public as well as to private render parameters.

    All previously set render parameters are cleared.

    These parameters will be accessible in all sub-sequent render calls via the PortletRequest.getParameter call 
    until a new request is targeted to the portlet.

    The given parameters do not need to be encoded prior to calling this method.

    The portlet should not modify the map any further after calling this method.

    Parameters:
        parameters - Map containing parameter names for the render phase as keys and parameter values as map values. 
        The keys in the parameter map must be of type String. The values in the parameter map must be of type String array (String[]). 
    Throws:
        java.lang.IllegalArgumentException - if parameters is null, if any of the keys in the Map are null, 
        if any of the keys is not a String, or if any of the values is not a String array
MSN UPDATE==>        , or and entries in the values String array are null. 
        java.lang.IllegalStateException - if the method is invoked after sendRedirect has been called.
-------------------------

And the above-mentioned section in the spec needs to be changed as follows:

Corrected:
-------------------------
If a portlet wants to delete a public render parameter it needs to use the
removePublicRenderParameter method or the setRenderParameters method on the StateAwareResponse or the
PortletURL.
-------------------------

However, I'm not sure that this meets the original intent and I am not convinced
these changes alone would make for a consistent description.

More work needs to be done in this area.



 Comments   
Comment by Neil Griffin [ 13/May/13 ]

@msnicklous: I checked the Pluto portlet container implementation, and it interprets the requirements according to the clarifications you suggest.

However, I just checked the Liferay portlet container implementation, it it interprets:

"All previously set render parameters are cleared"

to mean:

"All previously set [non-public] render parameters are cleared"

If you feel that the clarifications are essential, then please let me know since it would introduce a change into the way Liferay works.

Thanks,

Neil

Comment by Neil Griffin [ 15/May/13 ]

Test Portlet: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-7-portlet

Comment by msnicklous [ 18/Jul/13 ]

Using the PORTLETSPEC3-7 portlet, you can see that you can delete parameters by specifying an empty map "actionResponse.setRenderParameters(new HashMap<String, String[]>());". This works for all private parameters that have been previously set. With public parameters, there are two cases:

1) If the public parameter was set previously during execution of the same action request, it can be deleted using an empty map.

2) If the public parameter was set during a previous request, it remains unchanged when attempting to delete it using an empty map, and no exception is thrown.

However, a public render parameter can be set to a new value using setParameters() regardless of whether the public parameter already existed or not.

Both Pluto and WebSphere show this behavior.

Comment by msnicklous [ 19/Jul/13 ]

I think that it should not be permissible to remove public render parameters by setting them to null or by leaving them out of the map parameter of the setRenderParameters() methods.

I suggest updating the description for StateAwareResponse#setRenderParameters() method as follows:

StateAwareResponse

setRenderParameters

void setRenderParameters(java.util.Map<java.lang.String,java.lang.String[]> parameters)

Sets a parameter map for the render request.

This method can be used to set both public and private render parameters. 

These parameters will be accessible in all subsequent render calls via the PortletRequest.getParameter call
until a new request is targeted to the portlet.

Any previously set private render parameter that is not contained in the new map is removed. However, public render 
parameters cannot be removed by excluding them from the map. Public render parameters that are not included 
in the map remain unchanged.

The given parameters do not need to be encoded prior to calling this method.

The portlet should not modify the map any further after calling this method.

Parameters:
parameters - Map containing parameter names for the render phase as keys and parameter values as map values.
The keys in the parameter map must be of type String and may not be null or the null string (""). The values in the parameter 
map must be of type String array (String[]). Neither the values array nor any of its elements may be null; however,
the null string ("") is allowed. 

Throws:
java.lang.IllegalArgumentException - if parameters is null, if any of the keys in the Map are null or the null string,
if any of the keys is not a String, if any of the values is not a String array, or if any of the Sting array elements are null.
java.lang.IllegalStateException - if the method is invoked after sendRedirect has been called.

Comment by Neil Griffin [ 23/Jul/13 ]

+1

Comment by msnicklous [ 26/Jul/13 ]

Updated apidocs as suggested.

Comment by msnicklous [ 02/Aug/13 ]

reviewed on 20130730 and can be closed.

Comment by Neil Griffin [ 05/Aug/13 ]

Update to my +1 vote: The changes to the apidocs will require no changes to Liferay Portal's implementation.





[PORTLETSPEC3-6] Errata: Clarification for section "PLT.25.8.2 Locales supported by the Portlet" Created: 02/May/13  Updated: 07/Aug/13  Resolved: 09/Jul/13

Status: Resolved
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1210 Account for BCP47 Closed

 Description   

Referring to the working document "JavaTM Portlet Specification, working document 3 (22.04.13)",
there is a mistake under section PLT.25.8.2 at line 15. RFC 1766 specifies the locale format
as a language tag that is composed of subtags separated by hyphens, rather than underscore
characters. The text should be corrected as follows:

Original:
-------------------------
The supported locales declared in the deployment descriptor should follow the
lang_COUNTRY_variant format as defined by RFC 1766
(http://www.faqs.org/rfcs/rfc1766.html).
-------------------------

Corrected:
-------------------------
The supported locales declared in the deployment descriptor should follow the
lang-COUNTRY-variant format as defined by RFC 1766
(http://www.faqs.org/rfcs/rfc1766.html).
-------------------------



 Comments   
Comment by julien_viet [ 10/May/13 ]

I believe that such change would mean portlet container behavior changes but also breakage of existing applications using the current format.

We should keep the current behavior. We should remove the mention of RFC 1766 that cannot be respected and instead accept a definition that is correct.

I reviewed the web-facesconfig_2_0.xsd configuration schema that accept both syntaxes and specifies:

<xsd:complexType name="faces-config-supported-localeType">
<xsd:annotation>
<xsd:documentation>

The "supported-locale" element allows authors to declare
which locales are supported in this application instance.

It must be specified as :language:[_:country:[_:variant:]]
without the colons, for example "ja_JP_SJIS". The
separators between the segments may be '-' or '_'.

</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>

Comment by msnicklous [ 13/May/13 ]

Ok, I agree that we can't break existing portlets. In light of this, I would formulate the text as follows.

Corrected:
-------------------------
The supported locales declared in the deployment descriptor should be specified as :language:[:country:[_:variant:]] without the colons, for example "ja_JP_SJIS". The separators between the segments may be '-' or ''.
-------------------------

Question – the current text uses “should” … shouldn't it be “must”? (... declared in the deployment descriptor must be specified ...)

Comment by Neil Griffin [ 13/May/13 ]

@julien: Excellent detective work with the faces-config schema!

@msnicklous: I agree that the word "must" is necessary when describing firm requirements like this.

Comment by msnicklous [ 09/Jul/13 ]

Updated spec document accordingly.

Comment by Neil Griffin [ 23/Jul/13 ]

I think during the call we decided to re-open this issue for discussion to see what the Servlet API supports.

This page lists all of the Java EE 7 XSD files:
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

And here is the URL for the web-common_3_1.xsd
http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-common_3_1.xsd

Inside the file it contains documentation for "localeType" and "locale-encoding-mappingType" elements. If I understand the docs correctly, then I think that both dash and underscore are permitted.

Comment by msnicklous [ 26/Jul/13 ]

Fix discussed on 20130723. Revisit with additional information on locale handling in Java 7.

Comment by Ed Burns [ 26/Jul/13 ]

I've been working on a JSF issue that manifests with IE10 in Chinese locales. The is related to the new "script" subtag in the language tag spec as defined by Internet Best Current Practice 47. <http://tools.ietf.org/html/bcp47>. We are going to have to revise the JSF spec to take this into account. Basically, we need to specify how language tags that include the "script" subtag are converted to Locales that may not.

This is an issue for JSF 2.2 because we do not require JavaSE 7, and JavaSE 6 does not support these script subtags at all.

For JSF 2.3, we'll have to revise that language to allow for the script subtag.

Comment by keilw [ 29/Jul/13 ]

While individual JSRs like JSF 2.2 or JBatch (352) indeed require a minimum version of Java (EE) 6, the basis for JSR 362 is said to be Java EE 7, hence the improvements to Locale in Java 7 should be available. Or is there anything on the detail page that's wrong or shall be applied differently?

Comment by msnicklous [ 30/Jul/13 ]

In light of the the new Locale support in Java 7, it seems that we should move in that direction also. A description similar to the following might be appropriate:

(updated on 7 Aug 13 to remove the statement regarding compatibility in the text proposal, and to add some additional new information after the proposal)

The supported locales declared in the deployment descriptor must be specified as a valid language tag according to IETF BCP 47, "Tags for Identifying Languages". A valid language tag is composed of subtags separated by hyphens ("-", ABNF [RFC4234] %x2D) as delimiters. The language tag must begin with the primary language subtag and may be followed by subsequent optional subtags. If specified, the subtags must appear in the order shown below.

  • language - ISO 639 alpha-2 or alpha-3 language code, or registered language subtags up to 8 alpha letters (for future enhancements).
  • script - ISO 15924 alpha-4 script code. You can find a full list of valid script codes in the IANA Language Subtag Registry (search for "Type: script").
  • country (region) - ISO 3166 alpha-2 country code or UN M.49 numeric-3 area code. You can find a full list of valid country and region codes in the IANA Language Subtag Registry (search for "Type: region").
  • variant - Any arbitrary value used to indicate a variation of a Locale.
  • extensions - A map from single character keys to string values, indicating extensions apart from language identification. The extensions in Locale implement the semantics and syntax of BCP 47 extension subtags and private use subtags.

A valid language tag example would be "ja-JP-SJIS". This tag contains "ja" as the mandatory primary language tag, followed by the "JP" country and the "SJIS" variant subtags. The optional script and extensions subtags are not specified.

See IETF BCP 47, "Tags for Identifying Languages" for a complete description. See the descriptions of the Java SE 7 Locale, Locale.Builder, and ResourceBundle classes for additional information on how Java processes IETF BCP 47 language tag information.

Note that this will require a change to the portlet descriptor v3.0 schema as well.

Backward compatibility will be retained since v2.0 portlet descriptors will be validated with the v2.0 schema, so the old language tag formato for 2.0 portlets will continue to be accepted.





[PORTLETSPEC3-5] Errata: Clarification about Private Render Parameters Created: 02/May/13  Updated: 26/Jul/13  Resolved: 17/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'm struggling a little bit about exactly how to anchor the following clarification - whether we need a
change in the javadoc, or a paragraph in the spec.

First some background:
---------------------------
> The spec/javadoc never clearly states the specific meaning/semantic of
> getPrivateParameterMap().  Because of this there seem to be varying
> released interpretations/implementations.  Can you clarify?  Which is
> correct:
>
>    1. getPrivateParameterMap returns a Map of the non-public render
>       parameters whose existence stems from the use on one of the
>       setParameter APIs in a render or resource URL or on an action or
>       event response.  I.e. getPrivateParameterMap returns the requests
>       private render parameters and since during an action there is no
>       such thing one expects an empty Map to always be returned in this
>       lifcycle (phase). Or put another way merging this Map with the
>       public render parameter Map doesn't (always) yield the contents of
>       getParameterMap() -- when a resource request receives postback
>       data as well as public/private render params.
>    2. getPrivateParameterMap returns a Map of the non-public parameters
>       in this request.  I.e. in an action request, this api returns the
>       same/equivalent Map as getParameterMap -- and in a resource
>       request one gets both the private render parameters and postback
>       data in this Map.
>    3. something else?
>
>  >From a programming perspective I find (2) more interesting/valuable as
> I can see uses for code that uses getPublicParameterMap() to process the
> PRPs and then turns around and continue working with the rest of the
> parameters it hasn't yet processed.
>     -Mike-

Hi Mike,

To me (2) is what both the spec and javadoc do describe as the intended behavior.

The spec says in PLT.11.1.2 "Portlets can access a merged set of public and private 
parameters via the getParameter methods on the PortletRequest or separated as maps 
of private parameters via the method and public parameters via the 
getPrivateParameterMap. (lxxxvi)"

That alone I would think already disqualifies interpretation (1) above as it clearly 
states that getParameterMap() always represents a union of the private and public 
parameters accessible through getPrivateParameterMap() and getPublicParameterMap().

Furthermore, the PortletRequest.getPrivateParameterMap() javadoc also states 
"Returns a Map of the private parameters of this request." As this method is 
(fully) inherited by ActionRequest, it also applies to action requests. As 
nothing is said anywhere to exclude postback data from this Map, and the 
getParameterMap() method (which must also represent the portlet private 
parameters) also doesn't distinguish between posted or non-posted parameters, 
I think interpretation (2) is correct.

Both Apache Pluto container and Jetspeed-2 Portal have been implemented 
according to (2).
---------------------------

My take would be that we might need some clarification in the javadoc for 
PortletRequest, as follows:


Original:
-------------------------
getParameterMap

java.util.Map<java.lang.String,java.lang.String[]> getParameterMap()

    Returns a Map of the parameters of this request. 
    Request parameters are extra information sent with  the request. 
    The returned parameters are "x-www-form-urlencoded" decoded.

    The values in the returned Map are from type String array (String[]).

    If no parameters exist this method returns an empty Map.

    Returns:
        an immutable Map containing parameter names as keys and parameter 
        values as map values, or an empty Map if no parameters exist. The 
        keys in the parameter map are of type String. The values in the 
        parameter map are of type String array (String[]).


        
getPrivateParameterMap

java.util.Map<java.lang.String,java.lang.String[]> getPrivateParameterMap()

    Returns a Map of the private parameters of this request. 
    Private parameters are not shared with other portlets or components. 
    The returned parameters are "x-www-form-urlencoded" decoded.

    The values in the returned Map are from type String array (String[]).

    If no private parameters exist this method returns an empty Map.

    Returns:
        an immutable Map containing private parameter names as keys and 
        private parameter values as map values, or an empty Map if no 
        private parameters exist. The keys in the parameter map are of 
        type String. The values in the parameter map are of type String 
        array (String[]).
    Since:
        2.0
-------------------------

Corrected:
-------------------------
getParameterMap

java.util.Map<java.lang.String,java.lang.String[]> getParameterMap()

MSN UPDATE==>    Returns a Map of all public and private parameters of this request. 
    Request parameters are extra information sent with  the request. 
    The returned parameters are "x-www-form-urlencoded" decoded.

    The values in the returned Map are from type String array (String[]).

    If no parameters exist this method returns an empty Map.

    Returns:
        an immutable Map containing parameter names as keys and parameter values 
        as map values, or an empty Map if no parameters exist. The keys in the 
        parameter map are of type String. The values in the parameter map are 
        of type String array (String[]).


        
getPrivateParameterMap

java.util.Map<java.lang.String,java.lang.String[]> getPrivateParameterMap()

    Returns a Map of the private parameters of this request. 
MSN UPDATE==>    Private parameters are all those not declared to be public parameters 
MSN UPDATE==>    in the portlet deployment descriptor. 
    The returned parameters are "x-www-form-urlencoded" decoded.

    The values in the returned Map are from type String array (String[]).

    If no private parameters exist this method returns an empty Map.

    Returns:
        an immutable Map containing private parameter names as keys and 
        private parameter values as map values, or an empty Map if no 
        private parameters exist. The keys in the parameter map are of 
        type String. The values in the parameter map are of type 
        String array (String[]).
    Since:
        2.0
-------------------------


 Comments   
Comment by Neil Griffin [ 13/May/13 ]

I like the "MSN UPDATE" clarifications to the JavaDoc.

BTW, I confirmed that Liferay's portlet container has functionality described in (2), which is the same as Pluto/JetSpeed.

Comment by Neil Griffin [ 15/May/13 ]

Test Portlet: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-5-portlet

Comment by msnicklous [ 09/Jul/13 ]

updated formatting.

Comment by msnicklous [ 17/Jul/13 ]

Updated javadoc comments.

Comment by msnicklous [ 26/Jul/13 ]

Fix discussed on 20130723 and was accepted.





[PORTLETSPEC3-4] Errata: Clarification for PortletRequest.getPortletSession() Created: 30/Apr/13  Updated: 26/Jul/13  Resolved: 17/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JSR286, PortletRequest, portlet

 Description   

To be consistent with HttpServletRequest.getSession(), the Javadoc for
PortletRequest.getPortletSession() should be changed as follows:

Original:
-------------------------
PortletSession getPortletSession(boolean create)

    Returns the current portlet session or, if there is no current session and the 
    given flag is true, creates one and returns the new session.

    If the given flag is false and there is no current portlet session, this 
    method returns null.

    Creating a new portlet session will result in creating a new HttpSession on 
    which the portlet session is based on.

    Parameters:
        create - true to create a new session,
        false to return null if there is no current session 
    Returns:
        the portlet session
-------------------------

Corrected:
-------------------------
PortletSession getPortletSession(boolean create)

    Returns the current portlet session or, if there is no current session and the 
    create flag is true, creates one and returns the new session.

    If the given flag is false and there is no current portlet session, this method 
    returns null.

    Creating a new portlet session will result in creating a new HttpSession on which 
    the portlet session is based.

    To make sure the session is properly maintained, you must call this method before 
    the response is committed. If the container is using cookies to maintain session 
    integrity and is asked to create a new session when the response is committed, 
    an IllegalStateException is thrown.        
    
    Parameters:
        create - true to create a new session,
        false to return null if there is no current session 
    Returns:
        the portlet session


 Comments   
Comment by mfreedma [ 24/May/13 ]

Looks good.

Comment by msnicklous [ 09/Jul/13 ]

updated formatting.

Comment by msnicklous [ 17/Jul/13 ]

Updated javadoc comments.

Comment by msnicklous [ 26/Jul/13 ]

Fix discussed on 20130723 and was accepted.





[PORTLETSPEC3-3] Errata: Clarification in Javadoc for CacheControl.getExpirationTime() Created: 30/Apr/13  Updated: 26/Jul/13  Resolved: 17/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JSR286, portlet

 Description   

In the Javadoc for the CacheControl class, the following is stated for getExpirationTime() and setExpirationTime().
Taken together, it's a bit unclear as to what a return value of 0 from getExpirationTime() actually means - does
it mean "hasn't been set" or does it mean "disabled"?

The description for getExpirationTime() should be changed as indicated. The description for setExpirationTime() would remain unchanged.

Original:
-------------------------
getExpirationTime

int getExpirationTime()

    Get the currently set expiration time. If no expiration time is set on this response 
    the default defined in the portlet deployment descriptor with the expiration-cache 
    tag is returned, or 0 if no default is defined.

    This call returns the same value as the getProperty(EXPIRATION_CACHE) call.

    Returns:
        the currently set expiration time in seconds, or 0 if no expiration time is set.

setExpirationTime

void setExpirationTime(int time)

    Sets a new expiration time for the current response in seconds.

    If the expiration value is set to 0, caching is disabled for this portlet; 
    if the value is set to -1, the cache does not expire.

    This call is equivalent to calling setProperty(EXPIRATION_CACHE).

    Parameters:
        time - expiration time in seconds
-------------------------

Corrected:
-------------------------
getExpirationTime

int getExpirationTime()

    Get the currently set expiration time. If no expiration time has been 
    explicitly set on this response, the default defined in the portlet 
    deployment descriptor with the expiration-cache tag is returned; If
    no default value is provided in the portlet deployment descriptor, 
    0 is returned.

    This call returns the same value as the getProperty(EXPIRATION_CACHE) call.

    Returns:
        the currently set expiration time in seconds; 
        0 indicates caching is disabled for this portlet; 
        -1 indicates the cache does not expire.

setExpirationTime

(unchanged)
-------------------------


 Comments   
Comment by mfreedma [ 08/May/13 ]

So though I think the structure of the sentence in the description improves/clarifies the meaning I am worried that changing the statement to "0 is assumed" is ambiguous/confusing. Since we are describing what value is returned, shouldn't we use the term returned instead of assumed?

The changes to the description in the "returns" section is am improvement.

Comment by Neil Griffin [ 11/May/13 ]

I agree with Mike – "if no default is provided in the portlet deployment descriptor, 0 is returned."

Comment by msnicklous [ 13/May/13 ]

I agree with Mike & Neil ... I think we should use the sentence Neil suggested.

Comment by msnicklous [ 09/Jul/13 ]

updated formatting; incorporated suggested text change.

Comment by msnicklous [ 17/Jul/13 ]

Updated javadoc comments.

Comment by msnicklous [ 26/Jul/13 ]

Fix discussed on 20130723 and was accepted.





[PORTLETSPEC3-2] just a test Created: 29/Apr/13  Updated: 26/Jul/13  Resolved: 30/Apr/13

Status: Closed
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: bdaw Assignee: julien_viet
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

just a test



 Comments   
Comment by msnicklous [ 26/Jul/13 ]

See what happens when you close an issue.





[PORTLETSPEC3-1] Errata: Clarification for javax.portlet.renderHeaders Container Runtime Setting Created: 24/Apr/13  Updated: 26/Jul/13  Resolved: 09/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JSR 286 Portlet Specification 2.0


Tags: Errata, JSR286

 Description   

Referring to Section "PLT.11.1.4.3 The Render Part Request Attribute for Setting Headers in the Render Phase" on page 80 of the working document, it is a little bit unclear as to what should happen with the RENDER_PART portlet request attribute when the javax.portlet.renderHeaders container runtime setting is set to false, or is not set. I suggest the following changes:

Change lines 7-8 on page 81 from:
=====
Non-streaming portals will not set this attribute and thus the portlet should set
headers, portlet title and produce its markup in a single render request.
=====

to:
=====
Non-streaming portals will not set this attribute and thus the portlet should set 
headers, portlet title and produce its markup in a single render request.

If the javax.portlet.renderHeaders container runtime setting is set to false, the RenderRequest.RENDER_PART request attribute should not be set.
=====


 Comments   
Comment by msnicklous [ 14/May/13 ]

Updated to use Jira formatting

Comment by mfreedma [ 24/May/13 ]

Looks good.

Comment by msnicklous [ 09/Jul/13 ]

Updated spec document.

Comment by msnicklous [ 26/Jul/13 ]

Accepted.





Generated at Fri Sep 04 08:36:31 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.