I am a big fun of British music band Dire Straits. Their “Telegraph Road” song is among the ones I most like and listen over and over again. It tells the story of a lone man settling down in wilderness, and his followers coming one after the other. It traces development of a big city out of a small community, all the way down to the Telegraph Road.
It is hard to say that Java Specification groups have had enough lessons from history of development. A long time ago Servlet specification came with its own pack, then came JSP and then came Portlet specifications. Unfortunately, all those aim to be a brick on the wall, and well integrated with each other, however, the reality is a big disappointment.
Take Servlet Filter mechanism as an example, although portlets are valid JEE web applications, there is no way for Filters, defined in the web.xml, to get applied to when a portlet request comes in. Hence, people all around the community started to develop “patches” to accommodate this necessity. Spring Portlet MVC employs HandlerInterceptor, or Apache tries to simulate them with PortletFilters.
When JSF specification arrived into the town, it just appeared that nobody had cared enough to leave room for a healthy growth. We need to employ “legacy” bridges to make our JSF enabled portlets to work within portals. Portlet specification assumed that content is not a full web page, but only a fragment of it, some JSF guys on the other hand developed codes that expect full page content to operate. Just look at those ExtensionsFilter and AddResource stuffs in MyFaces.
Portlet specification says that portal is a web application in addition to being a portlet container, and individual portlets could also be separate web applications as mentioned above. Bu that’s all, they didn’t go further, didn’t settled down enough rules for how communication between portlet container and its individual portlets will be performed, and leaved us in a fog.
I think, we wait for lawyers to arrive first, and then rules will come along.