portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hepper <sthep...@hursley.ibm.com>
Subject Re: [Pluto] basic architecture
Date Mon, 06 Oct 2003 06:54:36 GMT
As Steven already noted, pluto needs to be in the shared app to allow 
the wrapper servlet that puto puts into the portlet web apps access to 
the pluto classes.

Currently we've tried to not use any interals of tomcat to get pluto 
running and I would like to stick to this design descission to allow 
pluto to run on other app servers besides tomcat and to prove that the 
portlet spec does not require internals of the app server for the 
implementation.

Regards,
    Stefan

Glenn R. Golden wrote:

> This is my current understanding of a 168 Pluto based portal 
> implementation, I just want to see if I'm on a boat with any other 
> passengers here...
>
> The whole thing (Portal, Portlets, Servlets, Jsp, etc) is running in a 
> Java Servlet/Jsp Web application server (i.e. Tomcat).
>
> The entire Portal is one webapp.  It has it's own folder under 
> tomcat/webapps, and the standard isolation from other webapps.
>
> The Portlets that will be running in the portal are in one or more 
> other webapps.  Sets of portlets live in a webapp, along with 
> (optionally) some servlets, jsp, static content, etc.  There may be 
> many sets of portlets, each in a different webapp.  Each with it's own 
> .war, folder under tomcat/webapps, isolation from other webapps, etc.
>
> The Portal Administrator installs the portal webapp.  She installs 
> each webapp of sets of portlets that will be available (probably via 
> tools in the portal).  She informs the portal (somehow) of the 
> existence of these sets of portlets in these other webapps.  Then she 
> uses the portal tools to configure the portal pages, etc.
>
> Different webapp sets of portlets are running in their own class 
> loader, so jar versions and static classes are not in conflict between 
> them.  Also, they cannot share static classes, such as common services 
> (such as provided by Pluto or Turbine or Avalon).  As a request is 
> processed, and a servlet context request dispatcher is used to pass 
> the pen from one portlet to another to aggregate the response, the 
> servlet request *is* common, and anything placed in there (such as a 
> service manager) would be shared by all the portlets even across 
> different webapps.  [I'm a little blurry on this whole point.]
>
> Yes?
>
> If I'm close here, then...
>
> I wonder if there's a way for the Portal to query the "tomcat" to get 
> the list of available portlets, so that we can just drop in a 
> (properly prepared) .war and the portal knows it's there?
>
> Is there a way to have a common Avalon-ish service framework among all 
> webapps, or are they kept separated?
>
> Thanks.
>
> - Glenn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


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


Mime
View raw message