portals-pluto-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Ingenthron <Matt.Ingenth...@Sun.COM>
Subject Re: deploying portlets to Pluto binary distribution
Date Tue, 01 Mar 2005 01:50:35 GMT
Hi David,

----- Original Message -----
From: "David H. DeWolf" <ddewolf@apache.org>
Date: Monday, February 28, 2005 5:27 pm
Subject: Re: deploying portlets to Pluto binary distribution

> 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 does the Sun implementation.

Are you saying this is entirely by design?  To me it seemed to be more
of a side effect of being based on the same technology.  I may just have
been looking at it from a different angle since the spec didn't seem to
really say one way or the other to me.

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

Hmmmm.  I'll definitely defer to someone with more experience in this
area (sounds like it's you), but I read that same paragraph and came to
the conclusion that one can implement JSR-168 as long as they implement
the runtimes associated with the Servlet Spec.  To me that meant a
container could (and probably would) also support regular webapps, but
it didn't need to in order to be a portlet container.  It just needed to
support the Servlet 2.3 runtime.  I guess in doing so, it'd have to
support a bunch of other stuff, like regular webapps...

In fact, it's that paragraph that lead me to write what I did.  :)

Now that I look at it, I did have a poor choice of words though.  I
should have said there's a very real difference when it comes to a
"portlet" and the spec discusses those differences.

- Matt

View raw message