The continuing (mundane) saga... Martin - Good Morning to you, and thanks for your reply.
If I understand you, you're talking about my reload troubles. I'm inferring from your post that reload should reload everything (incl. META-INF/context.xml and WEB-INF/web.xml)... Howevah, looking again at the online dox ( http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#Reload%20An%2 0Existing%20Application ), it says web.xml changes require a restart but reloading .class or .jar changes are what this is for. Well, it doesn't seem to be reloading anything, even simple java code changes. Here's the details: I'm just using the task supplied with the deployment download (apache-tomcat-5.5.12-deployer) build.xml: <target name="reload" description="Reload web application"> <reload url="${url}" username="${username}" password="${password}" path="${path}"/> </target> This target is called from my own build script: <target name="reload" description="- reloads [target] content into local Tomcat"> <ant antfile="build\deploy-tomcat.xml" target="reload" inheritAll="true" inheritRefs="false" > <property name="url" value="http://localhost:55120/manager"/> <property name="path" value="/${context}"/> <property name="username" value="XXX"/> <property name="password" value="XXY"/> </ant> </target> I have context set as: <property name="context" value="wadi"/> And here's the relevant output of the build script: reload: [reload] OK - Reloaded application at context path /wadi But no evidence that the change I made (this time, to a class file) made it to the server. And in this case, both tomcat and ant are running on the same host. FWIW, I cant see how reload would actually reload the app, as the reload task doesn't take a war attribute, like deploy does. It would make sense to me only if it expected the app update to occur outside of the task, if tomcat is running on a separate host than the one on which the build script runs. Oh, and that's just what the dox say at the end of the section - 'Currently, application reloading (to pick up changes to the classes or web.xml file) is not supported when a web application is deployed directly from a WAR file. It only works when the web application is deployed from an unpacked directory. If you are using a WAR file, you should undeploy and then deploy or deploy with the update parameter the application again to pick up your changes.' But arrgh even in my dev situation (app in outside of webapps, in unpacked directory structure, on same host as tomcat). Maybe the issue is I first deploy using the deploy target with the .war, which is the only way I can make this work (unless I rename & push the META-INF\context.xml to conf\Catalina\localhost, which makes no sense to me). I think my issue here is that I'm not obeying the rules that make reload usable; I need to undeploy/deploy, so I'll go that route. And regarding the session issue (re: StandardManager - IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.commons.fileupload.DeferredFileOutputStream ), if I care enough I'll go over to the commons user list and try to figure out what to do about it there. Well, probably too much text here but I was trying to not keep anyone guessing. Cheers, Steve Ps - Martin, I saw your reply in the archives but for some reason I didn't get it directly, though I'm still getting other email from Tomcat-Users... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
