[PORTLETSPEC3-36] Ajax: Remove ability for portlets to provide resources Created: 13/Dec/13  Updated: 27/May/16  Resolved: 29/Jan/16

Status: Closed
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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.

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:

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.

Comment by msnicklous [ 29/Jan/16 ]

The current draft does not allow portlets to contribute resources to be shared with other portlets. As with JSR286, they can include resources for their own use by inserting markup during header request processing.

However, portlets can declare dependencies on common resources by using the @Dependencies annotation within the @PortletConfiguration annotation as follows:

   dependencies = {
      @Dependency(name="Dojo", minVersion="3.1.4"),
      @Dependency(name="AngularJS", minVersion="1.4.8")

or by using the corresponding tags in the portlet deployment descriptor:


The actual configuration and provision of the common resources is left to the portal implementation.

Comment by Neil Griffin [ 29/Feb/16 ]

@msnicklous: Request that this issue be re-opened so that a small enhancement can be added. The JSF ResourceHandler mechanism specifies both name and library for identifying a resource which I have found to be very helpful in distinguishing between resources. Would you consider adding a library attribute to the @Dependency annotation and a library element to the portlet.xml schema? Thank you.

Comment by Neil Griffin [ 27/May/16 ]

The concept of "library" has been added via the <scope>...</scope> element and also via the HeaderResponse.addDependency(String name, String scope, String version) and HeaderResource.addDependency(String name, String scope, String version, String markup) methods. For more info, see PORTLETSPEC3-40.

Generated at Tue Jan 17 13:49:14 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.