Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
ServletExec Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 356
Product ServletExec
Category Known Limitations and Workarounds, Web Application
Question Something renames my web.xml file to which causes my webapp to be undeployed when SE restarts. What's wrong?
99.99999% of the time, this issue is due to using SE ISAPI with IIS 6 or higher which is an architecturally unstable, unreliable configuration that is no longer supported. The solution is to use SE AS instead. Please see SE FAQ #364 for details.

The remainder of this FAQ may help to better understand the mechanics of how web.xml gets renamed to Please note that changing file permissions in an effort to make this problem go away with SE ISAPI absolutely will not solve the problem. Please keep in mind that the file permissions issue discussed below is due to 2 or more SE ISAPI instances running at the same time. No amount of setting permissions on files will ever address that. SE AS is what addresses that.
http://<hostname>/servlet/TestServlet works when SE is "out-of-the-box" because the webapp named "default-app" gets deployed with "ServletExec Extensions" enabled and with the C:\Program Files\New Atlanta\ServletExec ISAPI\Servlets folder added as an External Library.

If the default-app is undeployed and then redeployed with "ServletExec Extensions" disabled (or with the Servlets folder no longer specified as an external library) then requests for servlets that reside in that Servlets folder (such as TestServlet, or sometimes the ArcIMS connector Servlet) can be expected to return 404 - File Not Found responses. It's easy to enable SE Extensions for any webapp on the main SE admin UI.
It's then possible (and also easy) to access the Admin UI for that particular webapp and add that Servlets folder as an External Library thus making the servlets that reside there visible and "requestable" to that webapp.

The situation is indicative of a physical file permissions problem. Manually enabling SE Extensions and adding the Servlets folder as an External Library (as mentioned above) can get things working right but most likely... only until the next restart of the default-app and/or ServletExec. It won't solve the underlying file permissions problem. The issue is that anytime SE tries to update any webapp's web.xml file it does so like this:
  1. write the new version of web.xml to a file named
  2. delete the original web.xml file
  3. rename to web.xml
This particular file permission problem has been reported on occasion before, and always with SE ISAPI (never SE AS). Apparently #1 and #2 work fine, but #3 fails. File permissions where SE ISAPI is allowed to (a) write a file & (b) delete an existing file, but cannot (c) rename the file that was written?
Very odd.

company media information terms of use privacy policy contact us