Skip to main content

Adobe

When to use JSR 286 vs JSR 168 for portlets

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mark Polly

Mark Polly is Perficient's Chief Strategist for Customer Experience Platforms. He works to create great customer, partner, and employee experiences. Mark specializes in web content management, portal, search, CRM, marketing automation, customer service, collaboration, social networks, and more.

More from this Author

Categories
Follow Us