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 02:25:47 GMT

Matthew Ingenthron wrote:
> 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 
>>that without leveraging any proprietary apis. Pluto *depends* upon 
>>webapp being deployed as a standard web application.  It then uses 
>>servlet api to invoke the portlets (using a cross context request 
> As does the Sun implementation.

Which is one reason why it's much better than WebLogic's implementation 
:)  - sorry, shameless plug.

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

Ok, I see your point now.  I've always assumed that it was a by design 
that Pluto was originally implemented this way -  but since I'm not the 
original implementor I can't say one way or the other.

>>>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 
>>container or it may implement *all* [emphasis added] the 
>>of a servlet container. Regardless of how a portlet container is 
>>its runtime environment is assumed to support Servlet Specification 
> 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...

When you differentiate between "runtimes" and "other stuff" what are you 
referring to? What is the line between what the container must and must 
not support?  Is it the processing of deployment descriptors that you're 
referring to?

What leads me to believe that it is the entire spec that must be 
implemented (vs just runtime support) are statements like the following 
which are littered throughout the portlet spec:

"Portlets, servlets and JSPs are bundled in an extended web application 
called portlet application. Portlets, servlets and JSPs within the same 
portlet application share classloader, application context and session."


"Portlets can leverage servlets, JSPs and JSP tag-libraries for 
generating content."


"A portlet can call servlets and JSPs just like a servlet can invoke 
other servlets and JSPs using a request dispatcher (see PLT.16 
Dispatching Requests to Servlets and JSPs Chapter). To enable a seamless 
integration between portlets and servlets the Portlet Specification 
leverages many of the servlet objects."

I guess if you are stating that the portlet container does not have to 
make the context available through "normal" means (through a simple 
contextPath) I would agree with you, however, remember that the portlet 
container does have to support the PortletResponse.encodeURL("") which 
will create a direct url to resources within the webapp.  As a result, 
the resources ARE available, but not necessarily through normal means.


> 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