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 implementation.
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 :
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.
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.
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 :)
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]
