Some confusion exists in the portlet development community, because many vendors tout their compliance with JSR 168 standards and less rarely talk about JSR 286 compatibility. I think this is mostly due to the fact that prior to JSR 168 becoming mainstream, the standards were loose and vendors built to their own specifications. So becoming compliant with JSR 168 was (and still is) a big deal.
In addition, while the JSR 286 spec has been out since 2008, it took the Portal vendors some time to update their Portal Servers to support the new standard. Now all the major vendors support JSR 286 on their Portal server. Even many content management systems are supporting JSR 286 portlets on their systems.
Also known as Portlet 2.0, JSR 286 builds upon the first portlet standard, JSR 168, so it has all the features of the first standard plus more:
- Event handling
- Shared parameters
- Resource addressing
- Alignment with WSRP 2.0
If you want a really in depth discussion of these new features, take a look at this article on developerWorks: What’s new in the Java Portlet Specification V2.0 (JSR 286)? It’s been three years since the JSR 286 spec came out, so its hardly new.
So when should you code to JSR 286 or when should you code to JSR 168? Here are my thoughts:
- If you are using the latest version of a mainstream portal, code to JSR 286. Liferay 6, WebSphere Portal 7, Oracle WebCenter 11.1.1.14, JBoss, Adobe CQ5, OpenText, Apache all support JSR 286.
- If you aren’t sure what spec your portal server supports, code to JSR 168. If you have older versions of Liferay (prior to V5), WebSphere Portal (prior to V6), Oracle WebCenter (prior to v11), you don’t have a choice – JSR 168 is the only supported spec.
- Your development environment may dictate whether you use JSR 286 or not. In IBM’s Rational Developer, for example, it can’t create a JSR 286 portlet using Struts. You can build a JSR 168 portlet using Struts, though.
So my bottom line is this: code to the JSR 286 standard when you can and only use JSR 168 when forced to.
Mark,
We had a project last year where we were also implementing the Google Search Appliance (GSA) into the Portal environment (Portal and WWCM). One of our biggest challenges was how to crawl the content from WWCM and index them properly to be returned in results when using the GSA.
After going through various design discussions, we found that we could leverage the seed list features of the JSR286 portlet in order to extract the various content URLs required for the crawl and index. It took some effort to write a custom connector to make it all work and to apply customer-specific filtering and collections. However, we did manage to get it all to work in the end, thanks to the seed list feature of the portlet. Without this, the GSA would not have been a viable solution for the customer.
Thanks for blog post – Jason Westfall