This servlet displays images just fine from the root context.
It uses the root context that comes standard with tomcat.
I'm hitting it with this URL:
http://localhost:8080/hello
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class HelloWorldExample extends HttpServlet{
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("hello world");
out.println("<img src=tomcat.gif>");
}
}
Here is the web.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd";>
<web-app>
<display-name>Welcome to Tomcat</display-name>
<description>
Welcome to Tomcat
</description>
<servlet>
<servlet-name>
Hello
</servlet-name>
<servlet-class>
HelloWorldExample
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Hello</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
</web-app>
Is this what you are trying to do?
On Wednesday 09 July 2003 04:18 pm, John Turner wrote:
> I'm just trying to understand why it was necessary.
>
> Our apps have mixed content, and we did not have to configure things as
> you've described.
>
> John
>
> On Wed, 9 Jul 2003 16:04:06 -0400, Mark Biciunas <[EMAIL PROTECTED]>
>
> wrote:
> > As I understand it, the servlet will receive all requests other than
> > those
> > that have been re-routed through servlet-mappings.
> >
> > Just out of curiosity, do you see a problem with this approach?
> >
> > Mark Biciunas
> > Agorex Inc
> > (905) 274-6785
> > [EMAIL PROTECTED]
> > ----- Original Message -----
> > From: "John Turner" <[EMAIL PROTECTED]>
> > To: "Tomcat Users List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, July 09, 2003 3:57 PM
> > Subject: Re: setting up a root servlet / getting images to appear in
> > Tomcat
> > 4.1.24
> >
> >> So you have a servlet that is intercepting all requests, other than
> >> image
> >> requests?
> >>
> >> John
> >>
> >> On Wed, 9 Jul 2003 15:55:21 -0400, Mark Biciunas
> >
> > <[EMAIL PROTECTED]>
> >
> >> wrote:
> >> > Actually, the point of the article is to explain how NOT to deliver
> >>
> >> the
> >>
> >> > images via the servlet and to allow Tomcat to serve images normally -
> >> > something that doesn't happen if you are using a root context.
> >> >
> >> > It is only when you configure server.xml with a blank context path
> >>
> >> (ie:
> >> > <Context path="" docBase="myservlet" debug="0"/>) that you run into
> >>
> >> this
> >>
> >> > problem. If you specify a path (ie: <Context path="myservlet"
> >> > docBase="myservlet" debug="0"/> then the problem doesn't appear.
> >> >
> >> > Hope this helps,
> >> >
> >> > Mark Biciunas
> >> > [EMAIL PROTECTED]
> >> > ----- Original Message -----
> >> > From: "John Turner" <[EMAIL PROTECTED]>
> >> > To: "Tomcat Users List" <[EMAIL PROTECTED]>
> >> > Sent: Wednesday, July 09, 2003 3:19 PM
> >> > Subject: Re: setting up a root servlet / getting images to appear in
> >> > Tomcat
> >> > 4.1.24
> >> >
> >> >> Just so I'm clear....you want to deliver the images via the servlet?
> >> >> I'm
> >> >> missing why you have to declare the MIME types of images at
> >
> > all...Tomcat
> >
> >> > is
> >> >
> >> >> perfectly capable of serving them in a standard HTTP/1.1 manner
> >>
> >> without
> >>
> >> > any
> >> >
> >> >> intervention from a servlet, and without any additional
> >>
> >> configuration.
> >>
> >> >> John
> >> >>
> >> >> On Wed, 9 Jul 2003 15:19:48 -0400, Mark Biciunas
> >> >
> >> > <[EMAIL PROTECTED]>
> >> >
> >> >> wrote:
> >> >> > This email formally presents what I have learned over the past
> >>
> >> couple
> >>
> >> >> > days
> >> >> > about setting up a servlet to be accessed as root (ie:
> >> >>
> >> >> www.myservlet.com
> >> >>
> >> >> > instead of www.myservlet.com/somepath) without loosing access to
> >> >>
> >> >> images
> >> >>
> >> >> > and
> >> >> > other mime types. It is based primarily on advice received from
> >>
> >> Bill
> >>
> >> >> > Barker
> >> >> > and Stefan Radzom as well as the hints and suggestions of many
> >
> > others.
> >
> >> >> > As
> >> >> > you are looking at this solution, please bear in mind that I am not
> >
> > an
> >
> >> >> > expert in Tomcat configuration and there is likely a lot of things
> >>
> >> I
> >>
> >> > have
> >> >
> >> >> > missed. I welcome any additional advice / corrections people have
> >>
> >> to
> >>
> >> >> > offer.
> >> >> >
> >> >> >
> >> >> > Setting up a servlet to be accessed without a path (ie:
> >> >> > www.myservlet.com)
> >> >> > is fairly easy if you pay attention to a couple of extra steps.
> >
> > First
> >
> >> >> > this
> >> >> > is to deploy your application in the webapps directory as usual
> >>
> >> (ie:
> >> >> > webapps/myservlet). Next, update conf/servlet.xml so that you have
> >>
> >> a
> >>
> >> >> > root
> >> >> > context that looks like:
> >> >> >
> >> >> > <Context path="" docBase="myservlet" debug="0"/>
> >> >> >
> >> >> > This will tell tomcat to serve ALL incoming requests to your
> >>
> >> servlet,
> >>
> >> >> > including requests for images, etc. If your servlet is not set up
> >>
> >> to
> >>
> >> >> > handle
> >> >> > mime types, then your images, etc. will seem to disappear. To make
> >> >>
> >> >> sure
> >> >>
> >> >> > the
> >> >> > images, etc. are handled correctly, you need to map them out in
> >>
> >> your
> >>
> >> >> > WEB-INF/web.xml as follows:
> >> >> >
> >> >> > <servlet>
> >> >> > <servlet-name>myservlet</servlet-name>
> >> >> > <servlet-class>mypackage.MyServlet</servlet-class>
> >> >> > </servlet>
> >> >> >
> >> >> > <servlet-mapping>
> >> >> > <servlet-name>myservlet</servlet-name>
> >> >> > <url-pattern>/</url-pattern>
> >> >> > </servlet-mapping>
> >> >> >
> >> >> > <servlet-mapping>
> >> >> > <servlet-name>default</servlet-name>
> >> >> > <url-pattern>*.gif</url-pattern>
> >> >> > </servlet-mapping>
> >> >> >
> >> >> > <servlet-mapping>
> >> >> > <servlet-name>default</servlet-name>
> >> >> > <url-pattern>*.jpg</url-pattern>
> >> >> > </servlet-mapping>
> >> >> >
> >> >> > What is happining here in the first two sections is that you have
> >> >> > identified
> >> >> > the servlet class and mapping for your servlet. This is more or
> >>
> >> less
> >>
> >> > the
> >> >
> >> >> > same as you would do for any servlet. If you do nothing more than
> >> >>
> >> >> this,
> >> >>
> >> >> > your servlet will (should) work, but you will not see any images
> >
> > since
> >
> >> >> > picture.gif would match to a url-pattern of "/" and get sent to
> >>
> >> your
> >>
> >> >> > servlet
> >> >> > for processing.
> >> >> >
> >> >> > In the second two sections, we are telling Tomcat that anything
> >>
> >> that
> >>
> >> >> > matches
> >> >> > a pattern of *.gif or *.jpg should be sent to the default servlet.
> >> >>
> >> >> Now
> >> >>
> >> >> > any
> >> >> > requests that match *.gif or *.jpg will be handled correctly. If
> >>
> >> you
> >>
> >> >> > need
> >> >> > to support more mime types, simply create more servlet mappings.
> >> >> >
> >> >> > Where did the default servlet come from? It is already configured
> >>
> >> in
> >>
> >> >> > conf/web.xml. Remember that conf/web.xml is automatically read
> >
> > before
> >
> >> >> > your
> >> >> > WEB-INF/web.xml so it can do it's thing without you having to
> >>
> >> worry
> >>
> >> >> > about
> >> >> > it at all. The trick is to use url-patterns to send requests back
> >>
> >> to
> >>
> >> > the
> >> >
> >> >> > default servlet so that they don't end up in your servlet.
> >> >> >
> >> >> > The above solution will work great as long as you don't have to
> >>
> >> many
> >>
> >> > mime
> >> >
> >> >> > types to deal with. If you need to handle lots of diferent types
> >>
> >> of
> >>
> >> >> > requests, then Bill Barker presented the following alternate
> >>
> >> solution
> >>
> >> >> > which
> >> >> > involves changing your servlet code to redirect requests:
> >> >> >
> >> >> > URL file = getServletContext().getResource(request.getPathInfo());
> >> >> > if( file != null ) { // physical resource exists
> >> >> > RequestDispatcher rd =
> >> >> > getServletContext().getNamedDispatcher("default");
> >> >> > rd.forward(request, response);
> >> >> > return;
> >> >> > }
> >> >> > // Your code here.
> >> >> >
> >> >> > I have not tried this solution so I do not know to much about it.
> >>
> >> It
> >>
> >> >> > seems
> >> >> > staightforward enough though, so I would expect it to work great.
> >> >> >
> >> >> >
> >> >> > Mark Biciunas
> >> >> > [EMAIL PROTECTED]
> >> >> >
> >> >> >
> >> >> > -------------------------------------------------------------------
> >> >> >-
> >>
> >> -
> >>
> >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> > For additional commands, e-mail: tomcat-user-
> >>
> >> [EMAIL PROTECTED]
> >>
> >> >> --
> >> >> Using M2, Opera's revolutionary e-mail client:
> >>
> >> http://www.opera.com/m2/
> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >> --
> >> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
Ben Souther
F.W. Davison & Company, Inc.
REGISTER NOW FOR THE SCORPEO USER CONFERENCE!
September 18-19, 2003 in Boston/Brookline, MA
Additional Training Sessions held September 17, 2003
More info >> http://www.fwdco.com/services/Uconf03/default.shtm
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
