> > restart tomcat(can't believe this has to be done everytime a servlet
> > gets added or changed), did that
There is a mode (not recommended for production use) for servlet changes to
be noticed by Tomcat and for those servlet class(es) to be automatically
reloaded, so you, strictly speaking, you don't need to restart Tomcat every
time you change a servlet. Just set the Reloadable entry in the Context tag
for the webapp to "true":
<Context path="/examples"
docBase="webapps/examples"
crossContext="false"
debug="0"
reloadable="true" >
</Context>
(If it was false before, you will need to restart Tomcat before this takes
effect.)
Calling servlets: the servlet path is one set up by default ("for backward
compatibility" according to server.xml), so, for example, if you had a
HelloWorld servlet class in
webapps/examples/WEB-INF/classes
then, if Tomcat is running, using the URL
http://yourmachinename:8080/examples/servlet/HelloWorld
would bring up that servlet. From server.xml
<!-- Non-standard invoker, for backward compat. ( /servlet/* )
You can modify the prefix that is matched by adjusting the
"prefix" parameter below. Be sure your modified pattern
starts and ends with a slash.
NOTE: This prefix applies to *all* web applications that
are running in this instance of Tomcat.
-->
<RequestInterceptor
className="org.apache.tomcat.request.InvokerInterceptor"
debug="0" prefix="/servlet/" />
so it doesn't have anything to do with mod_jk.
As the previous poster stated, try seeing if the examples under Tomcat work
first, then revise the configuration and see what happens.
Hope this helps...
Regards,
Joel Parramore
----- Original Message -----
From: "Sam Newman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 23, 2001 2:17 PM
Subject: Re: seems as though a servlet engine would have a little clearer
documentation on getting servlets running
> Go back to first prinicples. Try accessing the servlet directly via tomcat
> rather than worying about apache - try looking at
> http://youmachine:8080/yourcontext/servlet/YourServlet
> The port 8080 reefres to the port tomcat is running on. With no port
> specified, it means you are trying to access via the standard http port of
> 80, which is where Apache (or some other webserver) is running.
> If that works, its an Apache/mod_jk issue. If not, its a web.xml issue.
Just
> to reassure you, tomcat does work - I wouldn't be at all suprised if it
has
> the largest user base of all servlet engines currently on the market.
> If you find that doesn't work, please post your web.xml so we can have a
> look. If not, can you post the directives you use to get Apache running
with
> mod_jk (probably the mod_jk.conf-auto file generated in tomcat/conf).
>
> regards,
> sam
> ----- Original Message -----
> From: "Dan & Sharon" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, April 23, 2001 6:55 PM
> Subject: seems as though a servlet engine would have a little clearer
> documentation on getting servlets running
>
>
> > ok,
> > install tomcat,
> > jsps are workin,
> > made new context,
> > jsps are workin in it,
> > write a servlet(5 min),
> > try to get servlet working(5 hr),
> > read documentation,
> > it says put servlets in WEB-INF/classes dir, did that
> > it says add servlet to WEB-INF/web.xml, did that
> > <web-app>
> > <servlet>
> > <servlet-name>servtest.class</servlet-name>
> > <servlet-class>servtest.class</servlet-class>
> > </servlet>
> > </web-app>
> > restart tomcat(can't believe this has to be done everytime a servlet
> > gets added or changed), did that
> > it says call your servlet with
> > "http://thehost/WEB-APP/servlet/theservletname";
> > did that
> > response: 404
> > there's no servlet directory, kinda makes sense, but i thought mod_jk
> > was taking care of that. HMM.
> > so now that i've followed the instructions and that didn't work, i make
> > a servlet directory and add my servlet there. web browser tries to
> > download and save it to my disk, no display.
> > i'm sure that this being a servlet engine, it would probably serve
> > servlets, otherwise that would be really embarrasing for the
> > programmers, so, anyone got any suggestions?
> >
> >
