portals-pluto-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: deploying portlets to Pluto binary distribution
Date Tue, 01 Mar 2005 01:27:32 GMT
Matthew Ingenthron wrote:
. . .
> 
> There are a few POJO solutions-- I just don't know of any that will
> let you deploy one WAR to do both-- at least not without relying on
> how a particular implementation handles a WAR.

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

As a result, a portal which utilizes the pluto portlet container will 
serve content from many contexts.  In addition, those contexts may be 
accessed direclty.

For example, assume:

contextA = /portal
contextB = /portletAContext
contextC = /portletBContext

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

> Now that I've looked at the spec again, it does seem that they spend
> some time explaining how a portlet WAR is the same as any other WAR.
> Still, when it comes to servlets, there are real differences, and the
> spec has a section that discusses those differences.  I still think
> you'd be relying on an implementation detail-- a portlet container
> will nearly always be on top of a servlet container, but it's not
> required to be.

Not true, see PLT.32:

"The portlet container is an extension of the servlet container. As
such, a portlet container can be built on top of an existing servlet 
container or it may implement *all* [emphasis added] the functionality 
of a servlet container. Regardless of how a portlet container is 
implemented,
its runtime environment is assumed to support Servlet Specification 2.3."

Hope that helps,

David

Mime
View raw message