To Portlet or Not?

Discussions

Web tier: servlets, JSP, Web frameworks: To Portlet or Not?

  1. To Portlet or Not? (2 messages)

    I am looking for a good website CMS framework. We currently develop webapps using Hibernate/Webwork/Sitemesh. This works great for an individual app, but we are looking for a solution where we can deploy different “modules” (forums, wiki, etc.) I came across java Portlets (JSR 168) and it looks like it might just work. I am just concerned about how complicated implementing portlets can be. Is there a different solution besides portlets that allows for multiple webapps to be aggregated under one master webapp? Or is this what portlets were designed for?

    Threaded Messages (2)

  2. To Portlet or Not?[ Go to top ]

    IMHO, all this portlet buzz is too much like the EJB promise in its early days. "You are going to get reusable, transactional, scalable, distributed components that you can use out-of-the-box". Sounds too much like a sales bragging to me.

    Now they have just changed the title. Now they promise you that you can get whole web-applications and just plug them in!. But hey, did not they fail at the EJB level? What makes anybody think it will succeed on even higher level?

    I am sorry but I just don't see this happening. I see some nice portlet frameworks (e.g. Exo Platform) but I do not see many Portlet vendors and even less - people reusing portlets written by others.

    How many people have used JBoss Portal portlets in Exo and vice versa?

    Call me a pessimist, if you wish, but I will reply that those who think they are optimists are just naive.

    Back to your question: I think you will spend more time in integration if you go with the Portlets than if you would not and, in addition, you will get yourself additional, complex layer which is neither easy to maintain nor very portable from an App Server to an App Server.

    cheers
  3. To Portlet or Not?[ Go to top ]

    I agree. I am currently working with one major portal vendor and the amount of support for JSR-168 is less than ideal. Each vendor has their own existing API (except open-source solutions of course which typically use Apache Pluto, which is still in Beta) that allows you to develop an application much faster than using JSR-168. So, even though the marketing machine is talking about JSR-168 and WSRP, it is definitely not where it needs to be. Give me tools in the spec that can access things such as db pools, user stores, etc. uniformly across portal vendors and I'm good to go. Until then, think of your portal app as only running on the one portal server that you pick. And even then, you are not going to replace a full-blown app, you might surface 10% of a large app if you're lucky. Don't get me wrong, some of the portal vendors have some great tools that work with their specific portal server, there is not this great interoperability across all of the servers that you would think is happpening.