On 4/15/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 4/15/06, Evan J [EMAIL PROTECTED] wrote:
But again, ANY classes that does not have url mapping in
WEB-INF/web.xml, would not be autodeployed even if Tomcat server is
restarted. So once again, any class that has an existing url-mapping
in WEB-INF/web.xml, can be recompiled and autodeployed upon placement
in WEB-INF/classes but no newly compiled class that does not have
url-mapping in web.xml can be autodeployed or deployed at all (or at
least I get status 404 when I point my browser to the servlet).
If there is no mapping in web.xml, Tomcat doesn't know what to do with
the request, so the 404 is expected. You can't just point your
browser to the servlet. At least, not unless you enable the invoker
servlet...
http://vh.domain.com/SomeNewClass (or /servlet/SomeNewClass).
... and this URL containing /servlet/ makes me think you're working
from some old documentation that expects the invoker servlet to be
enabled.
* http://tomcat.apache.org/faq/misc.html#evil
You should put your servlet classes in packages and explicitly map
them in web.xml. URLs matching those mappings are the only ones you
can expect to work.
Whether changes to web.xml are picked up without reloading the context
is a different question. I always re-deploy for web.xml changes, so
I'm not sure.
You might want to try your experiments again, (using only URLs that
match mappings in web.xml,) and post another (shorter!) question if
you're still not seeing the behavior you want.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
The reason I posted my question in such a long thread was because
I did not want any ambiguity as far as what has been done to tackle
the issue. And from your response, I take it you did not read the
post throughly. I wasn't following any document and the reason I
mentioned servlet/MyClass was because, as for one of my settings
in the Apache webserver, I had /servlet/* mounted for servlets but
I had long gone moved away from that. As far as packaging, I
mentioned that I had been trying to only examin this issue with
web.xml redeployment and used packaging where it's applied.
My problem lies in the realm of not being able to re-deploy web.xml for
any modification. If I could get that to work, I would be more than happy
to use the url-mapping to map my new classes. Again, I can access
servlets accordingly with url-mapping already presented in web.xml
but since I cannot redeploy it, I have no other choice but to restart
the server. I wonder if I have understood the purpose of WatchedResource
in Context correctly...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
