portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre Stølsvik <En...@Stolsvik.com>
Subject Re: Re[2]: JSR-168 Comments & Dispatching to portlets
Date Tue, 29 Jul 2003 14:14:41 GMT

| That is one point I didn't make previously. Let's take an example scenario
| : running Jetspeed 2 on WebLogic. Let's say I have a set of JSR-168
| compliant portlets that I have deployed in WebLogic's portlet container.
| Now I don't like the portal aggregator GUI of WebLogic (this is an example
| :)), and I want to use Jetspeed 2 as my aggregator and portlet manager. So
| basically what I will have to do is bypass WebLogic's portlet container
| lookup-and-dispatch mechanism to use Pluto's ? If I understand correctly
| this is what I will need to do, and this is why I think it is a shame that
| it was not specified because instead of having two "xerces.jar" files I now
| have in effect two different portlet container implementations on my
| application server.

YES, I -so- follow you!! ;)

If I really LOVE IBM's Portlet Container with extremely fast handling of
Portlets, using NIO and native and internal JVM tricks - kicking of
Portlets 18 times faster than Pluto, THEN I'M STUCK WITH THEIR SHITTY GUI
TOO, right? - Or -exactly- the other way around: I love IBM's GUI, but I
need the Open Source-ness of Pluto because I want to tweak some parameter
in there - or add som extra logging - or just because it is better..

This is my worry. This ain't no cross-platform logic. I -can't- understand
the rationale for making the spec like this, except for having the
possibility to lock customers into a specific Portal (GUI) and
Servlet/Portlet Container combo - like e.g. Oracle does: touch their
Portal, be forced to use their AppServer (strange J2EE compliant thing),
and thus be forced to use their DB too. Openness is only good for a
Company as long as it creates incetives for customers to use that
Company's product because then it can "suck -in-" other vendors products
(here: Portlets) too.

I'd like, as pointed out, the ability to chuck in a Portal (GUI) WebApp
into a Servlet/Portlet Container, detaching these two entities entirely.
Or, even more preferrably, that the Servlet- and Portlet Container are
detached too. Then you have -three- components that should have defined
interfaces: Portal (GUI), Servlet Container and Portlet Container -
JetSpeed, Tomcat and Pluto.


Endre Stølsvik               M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS         -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message