Home/ Questions/Q 7167263
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T14:32:58+00:00

Does anyone have a link to a concise summary of what makes a portlet

  • 0

Does anyone have a link to a concise summary of what makes a portlet “JSR-286 compliant” vs being only “JSR-168 compliant”. I’ve got a copy of the spec and that’s anything but concise so linking the spec is not a useful answer. I’ve searched the web for an hour now and I’ve found nothing that is clear (aside from the spec, which of course requires that you read the previous spec too, and then weed out the “new features” from the “required compliance”.

Particularly I’ve found that there’s quite a bit of confusion out there on the necessity of web.xml, which appears to come from people using Liferay and not realizing that Liferay is dropping in a web.xml for them.

Do JSR-286 portlets require a web.xml file in their WAR files?

What I’d really like is something that contains one or more of the following lists:

  • Things you have to do to a JSR-168 to make it become JSR-286 compliant
  • Things you must not do, that would cause an otherwise JSR-286 compliant portlet to be considered only JSR-168.

You can leave “use the portlet-app_2_0.xsd” off the list, as I consider that part obvious.

I’m open to the answer that both lists are empty aside from the DTD/xsd for portlet.xml, and the difference is only in what the portal supports, but please back that assertion up with a link or other reference.

The reason I care is I see posts about Vaadin portlets in Liferay that imply that some features are not available for JSR-168 portlets… It may also be that some logic in Liferay switches based on which version of portlet.xml it sees, but I haven’t confirmed that either so that would be interesting information too, but not the answer to my question.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    According to this doc, but it’s also mentioned in jsr286:

    The JSR 286 spec(Portlet 2.0) does not break binary compatibility with JSR168(Portlet 1.0). This means that all portlets written against the Portlet 1.0 specification can run unchanged. The only exceptions to this rule are:

    renderResponse.setContentType is no longer required before calling getWriter or getOutputstream. In JSR168, calling getWriter or getOutputstream without previously setting the content type resulted in an IllegalStateException.

    getProtocol for included servlets / JSPs returns ‘HTTP/1.1’, In JSR168, it returned null.

    So as long as your jsr168 portlet doesn’t depend on the value returned by getProtocol() you’re safe (ie every jsr168 portlet is a jsr286 portlet).

    The posts you see seem to be logical as jsr286 is a newer spec and there are some features that make jsr268 portlet not a jsr168 portlet.

    • 0