portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luta, Raphael (VUN)" <Raphael.L...@groupvu.Com>
Subject RE: Re[2]: JSR-168 Comments & Dispatching to portlets
Date Tue, 29 Jul 2003 15:08:47 GMT

De : Serge Huber [mailto:shuber2@jahia.com]
> Hi Raphael,
> Long time no see, but I'm not sure you remember me :) Anyway, 
> let's get 
> back down to code :)

Sure, I think I still have an XO3 Portal box somewhere :)

> >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.

We both agree on this.

> >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.

You would still require an implementation specific bridge between your
"extended" container and your base servlet container if you want your
WAR to be usable idependantly of the portal, or deploy the WAR twice,
once in Tomcat and once in your container... not exactly user friendly :/

> >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.

As far as Pluto is concerned, the goal is to have it OSS somewhere
and preferably at Apache, but it is not there yet :(

> >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.

I think so but I haven't check closely.
> >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 
> implementation.

I don't think it's unfair. The point was the J2EE container 
implementations are typically *not* portable. 

> 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.

I can definitely see how this would make life easier for "best of
breed" portal vendors but since I see no incentive for the big 
"integrated" application server players (Sun, IBM, BEA, Oracle) to 
agree on such API which would only help their competitors, I give
such an API one chance in hell to be standardized or correctly 
implemented by thoses vendors :)

We'll have to deal with each container on a case by case basis and
write API adapters...

> > > 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).

OK, but only portal developers (as opposed to portlet developers)
are interested in such a functionality. That's a small crowd :/

> > > 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 :
>          myPortlet.setPageContext(pageContext)
> 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 
> class.

Actually, I would strongly -1 on the above API because of thread safety
issues but the general idea is that the portal implementation needs to 
strongly encapsulate the calls to the portlet container to make sure
the correct portlet instance is called. So again is this line of
code is used only once in the whole portal code, why bother going through
a standardization process ?

JSR 168 does not define any public portlet dispatching model for a good
reason IMO: there's no simple, portal-portable, meaningful portlet 
identifier that can be used as the key to a specific portlet instance in
a specific context page (like the URI is the Servlet API RequestDispatcher).
Only portal implementations and portlet container need to concern
themselves with the "raw" Portlet classes and it would be a security issue
to expose them outside of the containers.

> >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 :)
> >http://jakarta.apache.org/~raphael/frjug/Jetspeed_2_fr.ppt
> >
> >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.

I think this can only come from user requests to those specific 

Raphaƫl Luta - raphael@apache.org
Jakarta Jetspeed - Enterprise Portal in Java

Vivendi Universal - HTTP://www.vivendiUniversal.com: 
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material of Vivendi Universal which is for the exclusive use of the
individual designated above as the recipient. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, 
this information by persons or entities other than the intended recipient 
is prohibited. If you received this in error, please contact immediately 
the sender by returning e-mail and delete the material from any computer. 
If you are not the specified recipient, you are hereby notified that all 
disclosure, reproduction, distribution or action taken on the basis of this 
message is prohibited.

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

View raw message