[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-49] Add createRedirectURL() method to javax.portlet.ActionResponse interface and javax.portlet.filter.ActionResponseWrapper class Created: 19/Feb/15  Updated: 25/Feb/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();





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





Generated at Sat May 30 00:16:45 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.