portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn R. Golden" <ggol...@umich.edu>
Subject Re: [Pluto] basic architecture
Date Fri, 03 Oct 2003 17:21:16 GMT
Are you open to considering just using Avalon framework as the standard 
service API for JS2, and then using some Avalon container (Forest, 
Merlin) or one we build ourself for the actual container impl?  I don't 
see why we need yet another cover, even if Pluto is using it.  Let 
Pluto do what it wants, but JS could use Avalon.

- Glenn

On Friday, October 3, 2003, at 10:50  AM, David Sean Taylor wrote:

>
> 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 
> Fulcrum.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +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


---------------------------------------------------------------------
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