portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject RE: Re[2]: JSR-168 Comments & Dispatching to portlets
Date Tue, 29 Jul 2003 13:44:13 GMT

Hi Raphael,

Long time no see, but I'm not sure you remember me :) Anyway, let's get 
back down to code :)

At 02:55 PM 7/29/2003 +0200, you wrote:

>I agree that one of the concerns of the JSR 168 is that it does not
>describe any public standard API for the communication between
>the servlet container and the portlet container.
>It does not mean it's impossible, simply that portability between
>servlet containers will be an implementation specific feature of
>the portlet container and that you may have to write servlet-container
>specific adapter code.

Well it's not impossible that's for sure, but in a "standard" way for the 
moment it is not possible. Which is all I'm pointing out at the moment.

>Note that there's another related area where the portlet container
>will have to have servlet container specific code: the portlet
>application deployment requires you to deploy a standard WAR and thus
>use the servlet colntainer deployment capabilities. :/

Yes that's why I was saying that in effect a portlet container is an 
"extended" servlet container, and re-developing it within an existing 
portlet/servlet container (such as Tomcat), just to be able to resolve 
class access issues would be a shame, but would allow complete control over 
the dispatching process.

>On the whole, I don't think this lack of APIs is a real showstopper
>and would rather see that as an opportunity for an OSS project like
>Jetspeed to work on the multi-containers approach while vendors will
>most likely try to focus on tying their servlet and portlet container.

I definitely think this is where Jetspeed (and/or Pluto) has an occasion to 
shine !

>Yes Pluto implements something like this. The key issue to solve
>here is request dispatching: how does the portlet container retrieves
>a portlet pointer while still fullfilling the JSR constraints (like
>sharing session between the portlet and objects in its WAR (JSPs, etc...)
>The porxy servlet is mainly a portlet container specific implementation
>of this request dispatching, using the native servlet API calls and some
>custom parameters.
>I don't believe there's a major performance impact there.

Ok, I'm sure I'll have more questions once I see how this work in detail 
(at least I hope Pluto will be open in the near future ?), but for the time 
being I think I understand how it works and it seems portable.

>That would however seriously duplicate concerns as the portal/portlet
>container would have to deal with classloading, WAR handling, etc...
>There is some sense to try to leverage these functions of the servlet
>container (after all, how many times do you *really* want lo load
>xerces.jar ? :)

Yes that is why I would like to avoid this as much as possible. But for 
Jetspeed to be portable it has to use only recognized features of the 
servlet and portlet API. I've been using request/response wrappers to 
dispatch to servlets from other contexts and I've noticed that although 
Tomcat implements it very well, most commercial servlet containers have 
almost no support for cross-context request and response wrappers. It seems 
that although I interpreted the spec as wanting to allow this, it was not a 
strong requirement. I'd have to check up on Servlet API 2.4 because I 
believe they have improved the wording on this.

>The JSR 168 tries to guarantee that any compliant portlet will run on
>any compliant container. It does not try to address portlet container
>portability just like EJB does not address portability of EJB
>container implementations (any luck porting JBoss to Websphere
>recently ?)

Well that's not exactly a fair comparison. EJBs do specify a mechanism for 
lookup and dispatch, and this is what I'm interested in for portlets. So in 
effect I don't think that the whole internal working of the portlet 
container should be specified, but only the lookup and dispatch. Deployment 
for one is perfectly acceptable not to be standardized because it is less 
important. But not specifying lookup and dispatch closes the doors for 
projects such as Jetspeed to use the vendor-specific portlet container 

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.

> > 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".
> >
>+1. SO we can try to standardize what's missing from the JSR... :)

I'm all for it that's for sure, or I wouldn't spend my time writing emails 
instead of doing my work :)

> > 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");
> >
>Just 2 questions:
>- what is exactly the Portlet object you're trying to get ?
>   - a portlet description as gathered from the portlet.xml descriptor
>   - a portlet object (ie a class implementing javax.portlet.Portlet)
>   - a portlet description as gathered from the current page context
>     (for example a PSML page description) ?

In my example I was thinking about a portlet object implementing 
javax.portlet.Portlet. I assumed here that it's an already configured 
portlet and that it has already been initialized.

>- what code should be able to use this API:the portlet container,
>   portal or any portlet ?

Here I was showing an example of what Jetspeed 2, so the portal, would be 
able to do. So this way Jetspeed 2 could either lookup a portlet in it's 
own repository, or in another portlet containers if one is available in the 
same context (such as my previous scenario of Jetspeed 2 running on WebLogic).

> > 2. Direct dispatching to portlet. Continuing on the above code :
> >
> >          myPortlet.render(renderRequest, renderResponse);
> >
>Note that render requests typically require a page context for them
>to be meaningful. A portlet container may avoid thinking about
>context and process the request, but a real portal would have to
>first load the page settings, then the user preferences before any
>invocation of the portlet itself...

Ok so this would mean something like :


Here I understand this might be a problem because this method should only 
be visible from outside. So maybe this would require a specific dispatching 

>Right now, a lot of possibilites are open these APIs, especially the
>portal/portlet container ones.
>Check out the slide 4 of the following presentation (in French, but
>diagrams should be OK for everyone :)
>for an overview of *my* current thoughts on JS 2 architecture (it
>is a bit out of sync with current efforts as it has been done
>is May)
>All the portal internal APIs can still be modified, and we have a strong
>option of either building out the current Pluto public APIs or define
>a new Jetspeed container API and have a JetspeedPluto adapter to match
>the 2 different APIs.

Interesting presentation. And I am also a native french speaker so for me 
it was no problem :) The flow of the diagram took me a while to understand 
but I think I get the general idea.

One thought that cross my mind is I was wondering if there was a way to 
create incentives for portal vendors to open up their lookup and dispatch 
APIs so that Pluto could be configured with Adapters that would plug-in to 
vendor specific portal layers, and therefore improve portability at the 
cost of a layer of custom code.

My vision for Jetspeed 2 is that it should become the defacto standard, be 
easily embeddable into projects, be portable to any container, scale well, 
etc... This might seem a little crazy, but hey it's just a vision :)

   Serge Huber.

- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server

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

View raw message