Essential guide to API management and application integration
A comprehensive collection of articles, videos and more, hand-picked by our editors
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.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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:
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.
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.
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 knowhow you learned to be a great portlet developer.