Effective portlet development means respecting the servlet API

When moving to portlet development from web development, software engineers must remember that servlet and JSP development rules still apply.

For some bizarre reason, when experienced software developers jump into JSR-286 portlet development, their brains turn to mush, and they seem to throw away all of the basic rules of web based software development in Java. Portlet and portal based applications are more similar to standard servlet and JSP based applications than they are different, so when application developers embark upon building portlet based applications, it can't be stressed enough that all of the basic concepts they learned when developing web based Java applications apply equally when doing portlet based development.

More and more Java developers are being asked to learn the Portlet API.

Cameron McKenzie, Editor of TheServerSide (@potemcam)

Servlet and JSP development rules still apply

Here are three of the rules of servlet and JSP development that no web developer would ever violate, but for some reason, when those web developers become portlet developers, these rules seem to go out the window:

  1. You don’t spawn new threads in a servlet, nor should you spawn them in a portlet

    The portal server is already threading client invocations. Spawning new threads will only wreak havoc on the portal server. Sure, Java 7 provides all sorts of great facilities for doing threading orimplementing concurrent programs, but the body of a portlet is not the right place to be playing around with these new features.

  2. You don’t declare instance variables in a Servlet and you shouldn't declare them within a portlet either

    As far as instance variables go, there are times when they are appropriate, but those times usually involve extending the servlet or portal framework as opposed to creating a portlet or servlet that corresponds to a user story. When you are tempted to place an instance variable in a portlet, think instead about how the various scopes, such as the PortletSession or the PortletContext, might be a more appropriate place to maintain the data.

  3. You don’t synchronize servlet methods, and you shouldn't synchronize portlet methods either

    Synchronizing methods is also a bad idea in a portlet. Synchronizing portlet methods can create a bottleneck in your applications. Move complex logic as far away from the portlet tier as possible, and if you really need to synchronize a method, synchronize it in that far away place, not in the portlet itself.

Portlet development isn't a revolutionary new way to develop applications. It's more of an evolutionary change, and that means building upon the patterns and best practices of servlet and JSP based development, and not reverting back to anti-patterns and poor web-based programming techniques.

Do you have any quick tips for mastering the JSR 286 portlet API? Let us know how you learned to be a great portlet developer.

Follow Cameron McKenzie on Twitter (@potemcam)

Recommended Titles

Liferay Portal Systems Development By Jonas X. Yua
Liferay in Action By Richard Sezov
OSGi in Action By Richard Hall
Enterprise OSGi in Action By Holly Cummins
The Well-Grounded Java Developer By Martijn Verburg

Dig Deeper on Web portal design

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.