portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre Stølsvik <En...@Stolsvik.com>
Subject Re: [Pluto] basic architecture
Date Fri, 03 Oct 2003 07:19:30 GMT
On Thu, 2 Oct 2003, 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.

The question here is: does Pluto "hook into" the internals of Tomcat? See,
I can't understand anything else. Wars have separation, and since a Portal
App is a Web App, then Pluto and Tomcat must reside "on the same level",

| 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

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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message