As I understand :
context.xml contains whatever can go into the Context element in server.xml. These contents are explained (fairly well but without a tutorial aspect) in the Config HowTo docs. This context.xml file is then packaged into the META-INF directory of the .war file and the .war file is then deployed.
Hey presto!
I spent ages playing with entries in server.xml, only to have them overwritten (or, worse, spawned across multiple contexts as I defined a DefaultContext!). It's great for Resource entries, Loggers etc - web.xml is the standard deployment descriptor, and just has ref's etc; context.xml allows you to bind it to the container (which is usually implementation specific anyway).
Deploy/undeploy/Install etc have all worked as advertised for me since I've taken this approach - using Ant (although I do sometimes have to delete the generated JSP java/class files ...).
BTW, I've had problems _only_ when I rely on case-sensitive context names. I wanted to deploy as /Content (rather than /content) ... it deployed fine, but undeploy failed with 'no context at ...'.
G'luck
tim
Jim Lynch wrote:
I've been following this thread with interest since I've never been able to get undeploy to work either. Where might I go to learn about context.xml and most importantly, what goes into it? Examples would be great.
Thanks, Jim.
Phillip Qin wrote:
Having added context.xml, Deploy/Undeploy works perfectly for me now EXCEPT Undeploy doesn't delete work/....../myapp. However, Tomcat will take care of that because it checks if the file has been changed and reload the updated file. Maybe that's why the directory is not removed.
--------------------------------------------------------------------- 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]
