On Wed, 23 Jul 2003, Serge Huber wrote: | At 09:05 AM 7/23/2003 -0700, you wrote: | | >Tomcat and Resin have a cross-context invoker feature. | >See http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html | | Yes I am aware of those, but it still doesn't solve the problem of | dispatching to a Portlet API portlet. The entry point for one of those | portlets is a class that complies to a certain interface. For a Servlet in | a different web application we can dispatch by doing something like this : | | ServletContext otherWebAppContext = | ServletContext.getContext(otherWebAppContextPath); | RequestDispatcher otherWebAppDispatcher = | otherWebAppContext.getRequestDispatcher(otherWebAppURI) | otherWebAppDispatcher.include(request, response); | | But there is no equivalent for portlets. How can I call the doView method | of a certain portlet ? You'd need a way to access the classloader of the | other context. From what I understand in the implementation that is being | proposed to the ASF there will be a JAR that integrates with Tomcat | (meaning it will not be deployed in a context class loader but in Tomcat's | classloader, providing access down to all sub class loaders) to provide | access to the portlets, but this is very container specific and will have | to be modified to run on any other application server.
I so hugely "agree with your problems" here. The spec is -very- confusing on how to bind together the actual portal application (the one that draws the windows and handles the user comms) and the portlet container. It states very hard that it "only defineds the contract between the portlet and the container". But how interesting is that, if it is impossible to actually -make a PORTAL- using these Portlets? 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. One way of solving it is apparently using WSRP as the "glue" between the portlet and portal. 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). 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. -- Mvh, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
