Getting WebApp working at remote site: loop 'Deploying discovered web applications'

[Simon Brooke <si...@jasmine.org.uk>]

-----BEGIN PGP SIGNED MESSAGE-----

I have a webapp which I've thoroughly tested on various tomcat versions, and 
it works fine on my servers. I've now delivered it to my customers ISP, and 
it won't run on their servers (Tomcat 4.1.12). I have a limited amount of 
access to their tech support staff which I don't want to overtax, so I'd like 
to have a clear understanding of what the problem is before I hassle them.

What I am seeing is 
(i) None of the servlets in the webapp function. Instead, for all URLs which 
should be valid, I get a 404 error:

HTTP Status 404 - /shop/servlet/show_category
type Status report
message /shop/servlet/show_category
description The requested resource (/shop/servlet/show_category) is not 
available.

In the log, I get:

2003-09-04 12:13:50 StandardHost[shop.xylodom.com]: Mapping request URI 
'/shop/servlet/show_category'
2003-09-04 12:13:50 StandardHost[shop.xylodom.com]:   Trying the longest 
context path prefix
2003-09-04 12:13:50 StandardHost[shop.xylodom.com]:  Mapped to context '/shop'

However what is particularly concerning me is what I see in the log when no 
requests are being serviced: a rapidly repeating loop

2003-09-04 12:14:03 HostConfig[shop.xylodom.com]: Deploying discovered web 
applications
2003-09-04 12:14:18 HostConfig[shop.xylodom.com]: Deploying discovered web 
applications
2003-09-04 12:14:33 HostConfig[shop.xylodom.com]: Deploying discovered web 
applications
2003-09-04 12:14:48 HostConfig[shop.xylodom.com]: Deploying discovered web 
applications

This is similar to a problem which "Brandon Cruz" <bc...@norvax.com> reported 
to this list on 18th November last - did you get a fix, Brandon, and did it 
work? - but Brandon reported this appearing in catalina.out whereas I've got 
it in the log. 

In my webapps directory I had (this morning) both a 'shop.war' file (which I 
uploaded by FTP) and a 'shop' directory which I think I also uploaded by FTP 
because I think the war did not initially unpack (but this is a few days ago 
so I could be wrong. If I remove _both_ war file and directory from webapps 
then I get the same 404 error, and the same thing in the log:
2003-09-04 12:40:58 StandardHost[shop.xylodom.com]: Mapping request URI 
'/shop/servlet/show_category'
2003-09-04 12:40:58 StandardHost[shop.xylodom.com]:   Trying the longest 
context path prefix
2003-09-04 12:40:58 StandardHost[shop.xylodom.com]:  Mapped to context '/shop'
2003-09-04 12:41:04 HostConfig[shop.xylodom.com]: Deploying discovered web 
applications

If having removed both war file and directory, I then call 
manager/reload?path=/shop, I get a 'OK - Reloaded application at context path 
/shop' report(!) and trying the Servlet again _still_ gives the same 404 
error. However, in the logs the 'reload' gives a huge set or exception dumps, 
out of which I'll try to extract the key points:

2003-09-04 12:45:22 StandardHost[shop.xylodom.com]: Mapping request URI 
'/manager/reload'
2003-09-04 12:45:22 StandardHost[shop.xylodom.com]:   Trying the longest 
context path prefix
2003-09-04 12:45:22 StandardHost[shop.xylodom.com]:  Mapped to context 
'/manager'
2003-09-04 12:45:22 StandardWrapper[/manager:Manager]: Loading container 
servlet Manager
2003-09-04 12:45:22 Manager: init
2003-09-04 12:45:22 Manager: init: Associated with Deployer 'shop.xylodom.com'
2003-09-04 12:45:22 Manager: init: Global resources are available
2003-09-04 12:45:22 Manager: restart: Reloading web application at '/shop'
2003-09-04 12:45:22 StandardContext[/shop]: Reloading this Context has started
2003-09-04 12:45:22 WebappLoader[/shop]: Deploying class repositories to work 
directory /usr/share/tomcat4/work/Standalone/shop.xylodom.com/shop
2003-09-04 12:45:22 StandardContext[/shop]: Exception starting Loader
LifecycleException:  start: :  java.lang.NullPointerException
	at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:678)
....
- ----- Root Cause -----
java.lang.NullPointerException
	at 
org.apache.catalina.loader.WebappClassLoader.addPermission(WebappClassLoader.java:497)
	at 
org.apache.catalina.loader.WebappLoader.setPermissions(WebappLoader.java:885)

None of my classes are mentioned anywhere in the error dump, so I'm assuming 
that either the war file or the directory in the webapps directory _was_ 
where my app was (not) being loaded from, and the null pointer exception was 
because the requested app to reload was not there - which makes the 'OK' 
response a bit confusing...

Meantime the servlet request after removing the webapp shows up in the log 
_exactly_ as before:

2003-09-04 12:47:26 StandardHost[shop.xylodom.com]: Mapping request URI 
'/shop/servlet/show_category'
2003-09-04 12:47:26 StandardHost[shop.xylodom.com]:   Trying the longest 
context path prefix
2003-09-04 12:47:26 StandardHost[shop.xylodom.com]:  Mapped to context '/shop'

I have also tried putting the webapp and the directory back, one at a time; 
and still no change. I have *occasionally* had a class not found error 
relating to one of my classes, but so infrequently that I cannot characterise 
the circumstances.

Does any of this ring any bells with anybody? I can upload to the webapp 
directory, and I can see the logs (but not catalina.out) but I can't either 
see or alter the tomcat configuration. When I get back to tech support at the 
ISP I'd like to be able to tell them what I want them to do...

Cheers

Simon, with much less hair than last night...

- -- 
simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GP/CS s++: a+ C+++ ULBVCS*++++$ L+++ P--- E+>++ W+++ N++ K w--(---) 
M- !d- PS++ PE-- Y+ PGP !t 5? X+ !R b++ !DI D G- e++ h*(-) r++ y+++
- ------END GEEK CODE BLOCK------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBP1c81Xr1UrYJMbiJAQE4VgQA1L0ctLNv2DrfBvZN51bm73LpyonWbkXg
h3Zv4XVVjLYw0ew0q20sI7OjHR7UUER0VnyARCX2be/zAO72PwXnlq32hbhQbP5s
fYRKaSbfAT0Wpoa09mQLWOOD+pqJIqt1eD43FekalWHgVk8v9dtBjOxBiqRz1O9t
DaHKSmMzwkY=
=ChIa
-----END PGP SIGNATURE-----