portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [Pluto] basic architecture
Date Fri, 03 Oct 2003 14:50:42 GMT

On Thursday, October 2, 2003, at 07:08  PM, 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?

Jetspeed-2 provides a registry of all portlets in all web applications.
Unlike Jetspeed-1, the registry is stored entirely in the database.
You can access the registry with JMX.

> Is there a way to have a common Avalon-ish service framework among all 
> webapps, or are they kept separated?
Again, I will answer for J2 if you don't mind.
CPS - Common Portlet Services is a light wrapper over Fulcrum.
We are currently discussing the best service framework to replace 

David Sean Taylor
Bluesunrise Software
+01 707 773-4646
+01 707 529 9194

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

View raw message