Archive for the 'tomcat' Category

My first servlet app is online

Monday, June 19th, 2006

In this weblog entry, I talked about how to turn on the invoker servlet in Tomcat 5.0.28. I’ve received some advice since then from members of the Kansas City JUG telling me never to use the invoker servlet. In fact, even the JavaRanch page I referred to in the previous post had a link touting the evils of the invoker servlet. In addition, my KCJUG colleagues have assured me that registering each of my servlets with Tomcat through the web.xml file is simple.

So I did it. And it was easy.

My main beef now is with the text I’m following. All the examples so far in the book just drop the servlets into the default folder and use the invoker servlet to find them. In fact, there is no detailed explanation of web.xml and it’s features until Volume 2 of the book, which hasn’t even been published yet! (Actually, the first edition is published and available for free, but I’m still pissed!) I would think that there would be more about web.xml.

Anyway, I did get a sample application up on my website and coaxed the people at pointless waste of time to test it out. All it does is track clicks on links within a page, but I’m pretty happy with it as a first servlet application. I also got my redirect working so http://www.dangertree.net actually points to the index.php page (by default, Tomcat doesn’t recognize ‘index.php’ as a default page).


Tomcat 5.0.28 Invoker Servlet

Wednesday, June 14th, 2006

While setting up my first Apache Tomcat installation, I ran into a problem with the invoker servlet. The invoker servlet lets you run servlets without first making changes to the WEB-INF/web.xml file in your web application. All it really does is let Tomcat know that that any servlet classes dropped into the WEB-INF/classes directory should be executable through the path http://hostname/servlet/ServletName. By default starting at version 4.1.12, Tomcat does not allow this behavior simply by coming with a conf/web.xml file that has those lines commented out. From the Tomcat FAQ:

The invoker is a dynamic servlet which allows run-time loading of other servlets based on class name. This servlet is the one that allows http://localhost/servlet/com.foo.MyClass?more=cowbell, where com.foo.MyClass is some class which can be loaded as a servlet but was never explicitly declared in a config file.

In the text I’m following, Core Servlets and JavaServer Pages Volume 1 (2nd Edition), all it says to do in order to turn on the invoker servlet is to edit conf/web.xml and upcomment the following lines:

<servlet-mapping>
    <servlet-name>invoker</servlet-name>
    <url-pattern>/servlet/*</url-pattern>
</servlet-mapping>

This tells Tomcat that the Invoker Servlet should sit and watch the /servlet path for anything dropped into that directory and treat it as a package-less servlet. That means that you dont’ have to update the web.xml file everytime to change your structure. This is helpful for testing and debugging during development, but should not be used in a deployed server because of security problems. But with version 5.0.28, you also have to uncomment the lines in conf/web.xml that define the location of the classes for the invoker servlet, not just the mappings as shown above. So in order to get the invoker servlet to work, uncomment the following as well from conf/web.xml:

<servlet>
    <servlet-name>invoker</servlet-name>
    <servlet-class>
        org.apache.catalina.servlets.InvokerServlet
    </servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <load-on-startup>2</load-on-startup>
</servlet>

If you only uncomment the servlet-mapping invoker elements, Tomcat won’t even start properly. You have to ensure the corresponding Invoker servlet name and class are defined in conf/web.xml as shown above. JavaRanch had some very good information on the invoker servlet and how it works in Tomcat.