What makes the JSR-286 portlet compatible?

Question

Does anyone have a link to a brief overview of what makes the portlet "JSR-286 compatible", and not just "JSR-168 compatible". I have a copy of the specification, and something but short, so a link to the specification is not a useful answer. I searched the net for an hour, and I did not find anything that was clear (except for the specification, which of course requires you to also read the previous specification, and then push the “new features” out of the “required compliance”.

In particular, I found that there is quite a bit of confusion about the need for web.xml, which seems to come from people using Liferay and doesn't understand what Liferay throws into web.xml for them.

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

What I really liked is that it contains one or more of the following lists:

• What you need to do for JSR-168 to become compatible with JSR-286.
• Things you shouldn't do that will cause the JSR-286 compatible portlet to be considered only as JSR-168.

You can leave "use portlet-app_2_0.xsd" in the list, as I find this part obvious.

I am open to the answer that both lists are empty except for DTD / xsd for portlet.xml, and the only difference is what the portal supports, but please return this statement with a link or another link.

The reason I'm worried is the Vaadin portlet messages in Liferay, which imply that some functions are not available for JSR-168 portlets ... It is also possible that some logic in Liferay switches based on which version of portlet.xml it sees but I did not confirm it so that it was interesting information, but not the answer to my question.

Answer 1

According to this document , but it is also mentioned in jsr286 :

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

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

getProtocol for enabled servlets / JSP returns' HTTP / 1.1, in JSR168 it returns null.

Until your jsr168 portlet depends on the value returned by getProtocol() , you will be safe (i.e. each jsr168 portlet will be a jsr286 portlet).

The posts you see look logical, since jsr286 is a newer specification, and there are some features that make the jsr268 portlet not the jsr168 portlet.

Answer 2

Well, since I did not find anything new that distinguishes portlet 2.0 from portlet 1.0 (besides using additional services and), I will start the lists for my answer here.

Should:

• Corresponds to 2.0 XSD for portlet.xml (xmlns = "http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd")

No need to do:

• Rely on getWriter to throw an exception if renderResponse.setContentType has not yet been called. (Seems unlikely anyway)
• Rely on getProtocol () returning null

Result: if you simply convert your .xml portlet, you are now "compatible with 286" if you do not rely on two elements in the second list for the flow of your program. I cannot find anything else, but if someone finds another item for these lists, edit it.