[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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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.





Generated at Fri Sep 04 20:18:40 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.