Mailing-List: contact pluto-user-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pluto-user@portals.apache.org
Reply-To: pluto-user@portals.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4223E0EC.6080202@vecna.com>
Date: Mon, 28 Feb 2005 22:26:36 -0500
From: Bill Schneider <bschneider@vecna.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: "David H. DeWolf" <ddewolf@apache.org>
CC: pluto-user@portals.apache.org
Subject: Re: deploying portlets to Pluto binary distribution
References: <1310c7132c02.132c021310c7@sun.com> <4223C504.4090801@apache.org>
In-Reply-To: <4223C504.4090801@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> Pluto is a good example of a portlet container which allows precisely 
> that without leveraging any proprietary apis. Pluto *depends* upon the 
> webapp being deployed as a standard web application.  It then uses the 
> servlet api to invoke the portlets (using a cross context request 
> dispatcher).

How widely supported is cross-context request dispatch?  I know it's 
easy in Tomcat... but what about other containers?

If there were a good way to handle cross-context /method calls/, though, 
this would be somewhat of a moot discussion, as I could then easily have 
a separate portlet WAR that includes the interface JAR for my business 
APIs, and fishes out the implementation from the other context where the 
"real" app is deployed.

> A request to /portal/something may render content from /portal, 
> /portalA, and /portalB concurrently.  Each of the requests to the 
> portlet contexts would be rendered through a Pluto dispatch servlet, 
> which in turn would invoke the actual javax.portlet.Portlet, which in 
> turn would probably use some jsps, etc. . .In addtion, a client browser 
> could just as easily request /portletAContext/someServlet and directly 
> serve up content.
> 
> Is that what you're asking to do?  If so, it's very legit and an example 
> can actually be seen in the pluto TestSuite (see the External Scope 
> Session Attribute Test).

yep, that's exactly it.  Thanks for the cogent explanation!

-- 
Bill Schneider
Chief Architect

Vecna Technologies, Inc.
5004 Lehigh Road, Suite B
College Park, MD 20740
bschneider@vecna.com
t: 301-864-7594
f: 301-699-3180