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:
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.
In JSR 168 (Portlet 1.0), the only way to achieve eventing between portlets was through a portlet session. This was possible between portlets that are in the same web application. JSR 286 (Portlet 2.0) defines a lifecycle for events, so that eventing is possible between portlets that are in different web applications.
Java Server Page (JSP) and HTML Portlets These portlets can be simple to implement and deploy, and they provide basic functionality quickly.
A portal is a collection of mini web applications, called portlets. A portal supports features like personalization, content aggregation, authentication, and customization. Portlets act as windowed web applications within the portal, and each window in a portal web page (called a portal page) represents a portlet.
The portlet container is the runtime environment for portlets using the JSR 286 Portlet specification, in which portlets are instantiated, used, and finally destroyed. The JSR 286 Portlet application programming interface (API) provides standard interfaces for portlets and backwards compatibility for JSR 168 portlets.
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.
Ok, Since I've not found anything new that distinguishes a 2.0 portlet from a 1.0 portlet (aside from using additional services and ) I'll begin the lists for my answer here.
Must Do:
Must Not Do:
The upshot is, if you simply convert your portlet.xml, you are now "286 compliant" unless you relied on the two items in the second list for your program flow. I can't find anything else, but if someone finds another item for these lists, please edit.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With