You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by "Cottington, Alan" <Al...@factiva.com> on 2003/10/30 20:14:10 UTC

Using binary content-types?

Are you supposed to be able use any other content type in the response (RenderResponse setContentType) than text/html, e.g image/gif, image/jpeg, text/javascript.

Or is there another method of returning this sort of data rather than through the portlet/RenderResponse.

Thanks,
Alan.

Re: Servlets accessible via url?

Posted by "Glenn R. Golden" <gg...@umich.edu>.
The portlet container, and the portal, don't do anything with your 
servlets.  That's why the whole thing is running in a Servlet 
container, like Tomcat.  You need to register your servlets in the 
web.xml just like normal, and make urls to the Servlets in the normal 
way.

All your portlet needs to do is know how to write the url to the 
servlet.

The Portal and Pluto won't interfere in any way with the Servlet 
working.

I don't see anything wrong with popups or mixing servlets and portlets 
in a webapp.

- Glenn

On Thursday, October 30, 2003, at 02:54  PM, Tony Field wrote:

> The portlet spec is fuzzy around the area of how exactly a portlet 
> container deals with servlets.  It's clear that a portlet container 
> must be able to provide all of the services of a servlet container, 
> but it's not clear whether or not the portal server will be able to 
> render URL requests that are directed at servlets living in the 
> portlet's webapp without having to go through the portlet.  In other 
> words, suppose this configuration:
>
> /myWebapp
> /myWebapp/jsp/portlet1.jsp
> /myWebapp/jsp/portlet2.jsp
> /myWebapp/lib/servlet1.jar
> /myWebapp/lib/servlet2.jar
> /myWebapp/lib/servlet3.jar
>
>
> portlet1.jsp dispatches the request to servlet1 (I know that this 
> works fine)
> portlet2.jsp dispatches the request to servlet2 (I know that this 
> works fine)
>
> servlet3 is meant to be accessible via the url,  (I wonder if this can 
> be expected always)
> ex.
> http://myhost/myWebapp/servlet3?foo=bar
>
> So my question is this - can I actually acccess servlet3 in this way, 
> or do I have to deploy the servlet in its own webapp that is NOT a 
> portlet webapp?
>
> My goal is to be able to have my portal render portlet1, then have the 
> user click on a link that creates a pop-up to servlet3, and have 
> portlet1 and servlet3 share the same session.  I *know* that pop-ups 
> are "not a good thing" but it is a model that I need to support 
> initially.  I hope to do the "right thing" as a second phase.
>
> Thank you in advance,
> Tony


Servlets accessible via url?

Posted by Tony Field <to...@fatwire.com>.
The portlet spec is fuzzy around the area of how exactly a portlet 
container deals with servlets.  It's clear that a portlet container 
must be able to provide all of the services of a servlet container, but 
it's not clear whether or not the portal server will be able to render 
URL requests that are directed at servlets living in the portlet's 
webapp without having to go through the portlet.  In other words, 
suppose this configuration:

/myWebapp
/myWebapp/jsp/portlet1.jsp
/myWebapp/jsp/portlet2.jsp
/myWebapp/lib/servlet1.jar
/myWebapp/lib/servlet2.jar
/myWebapp/lib/servlet3.jar


portlet1.jsp dispatches the request to servlet1 (I know that this works 
fine)
portlet2.jsp dispatches the request to servlet2 (I know that this works 
fine)

servlet3 is meant to be accessible via the url,  (I wonder if this can 
be expected always)
ex.
http://myhost/myWebapp/servlet3?foo=bar

So my question is this - can I actually acccess servlet3 in this way, 
or do I have to deploy the servlet in its own webapp that is NOT a 
portlet webapp?

My goal is to be able to have my portal render portlet1, then have the 
user click on a link that creates a pop-up to servlet3, and have 
portlet1 and servlet3 share the same session.  I *know* that pop-ups 
are "not a good thing" but it is a model that I need to support 
initially.  I hope to do the "right thing" as a second phase.

Thank you in advance,
Tony