Hi Endre,
Well I'm happy to see I'm not the only one with this concern. I was beginning to think that nobody had this problem except me :)
At 11:54 AM 7/29/2003 +0200, you wrote:
My problem is that is seems impossible to do both of: a) Have a Portal implemented on top of a standard Servlet Container b) Run multiple Portlet Applications, preferrably in a standard Portlet Container, preferrably -the same- container as the Portal is running in. .. and be able to, in a standard way, to communicate between the portal and the portlets.
Yes b) is exactly my problem too. I thought a lot about it and it would be possible to develop a "sub portlet container" within the portal, using a custom built portlet container (but that would imply also have to develop a sub-servlet container, with everything that includes such as classloaders, deployment descriptor handling, dispatching, etc). This solution is interesting because it guarantees complete control over the process and *no* vendor lock-in, but it's a bit of a shame because you are no longer using all the tools that are available for the top-level portlet container. So in effect you'd have this :
Portlet / Servlet Container
-------------------------------
Portal
-------------------------------
Sub-Portlet / Servlet ContainerThis would be heavy but optimal in terms of performance. In a way this is very close to how Jetspeed currently works, as Jetspeed is a Web application in a servlet container, and defines it's own "sub" portlet container. In my work, I've designed a portal that uses cross context dispatching to dispatch to standard servlets, and although it works quite well, it is not as flexible as the interfaces that the JSR 168 proposes. This is why I was hoping (and unfortunately I got involved to late to be a real part of the JSR process) that they would address this issue, as it seemed critical to me.
From what I understand of my discussion in this mailing list, Pluto does something in between : it adds within the portlet a proxy servlet that allows dispatching to the portlets. This way the system I have been using with cross-context dispatching could be adapted, but it's still not as efficient as having a portal/portlet full-blown API. Maybe this is the subject for a new JSR ? Or maybe in this project (Apache Jetspeed) we could develop what we need and then propose this as a reference implementation and submit it as a JSR (maybe that way things would move faster ?). Seeing how projects such as Xerces and Xalan got accepted throughout the whole commercial world it would seem like Apache is in a position to "impose" defacto standards.
One way of solving it is apparently using WSRP as the "glue" between the portlet and portal.
Yes but at what cost. Serializing all objects through XML and sending them through sockets that are being opened / closed all the time is very expensive in terms of performance.
To me, this seems some a kind of vendor lock-in scheme: you buy the Servlet Engine from us, and wow, it also have a Portal in there, effeciently doing proprietary communications with the Portlets. You are suddenly (as it is already) locked to both the Servlet Engine -and- the Portal (application).
My guess here is that it's indeed a very political issue. All the current commercial portal vendors involved in JSR-168 could only agree on the most common and minimal specifications, and they didn't want to have too much standardized or they would loose their commercial edge. It might not be the case, but as this process has been entirely closed (even for me, and I am part of the JCP but only as community member !), I can only speculate as to what went on in the expert group.
I would have loved a spec where the Portal was the Container, and had to be able to host Portlets within it. This way, one could buy the Servlet Container from Oracle, use JetSpeed as the Portal, and buy Portlets from CompanyA, B and C, plugging them in / installing like nice little applications in a normal OS.
Ok, again I agree. Users of portals should be free to migrate from one system to another, without vendor lock-in. After all the J2EE specs exist as Sun puts it : "for vendors to compete on implementation, and agree on standards". This is a nice vision but reality is more like : "vendors always compete on anything, Jakarta standardises".
Now enough with my whining, I'll start a quick proposition here : this is what I would have loved to see in JSR-168 :
1. Standard mechanism for portlet lookup. Maybe JNDI ? Or even UDDI ? Basically be able to do something like this :
Context context = getInitialContext();
PortletRepository portletRepository = (PortletRepository) context.lookup("PortletRepository");
// list of portlet example : ArrayList portletList = portletRepository.getPortletList();
Portlet myPortlet = portletRepository.getPortlet("myPortlet");
2. Direct dispatching to portlet. Continuing on the above code :
myPortlet.render(renderRequest, renderResponse);
As you can see not much extra is needed to have the complete picture. It's a shame the JSR-168 only specifies point 2 when point 1 could have been achieved in a minimal way without much effort. I hope this will indeed be specified later, but given the time it has taken to specify point 2 I had hope point 1 was being addressed too. Maybe it's not too late and before the final release this can be added ? Can somebody here shed some light on the possibilities still open ?
Regards, Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- - www.jahia.org : A collaborative source CMS and Portal Server
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
