Changes to web.xml not affecting application behaviour

[Richard Jebb]

Hi

I hope someone can help with this - it must be a common issue.

We have just delivered a web app for a client. Most of the functionality was developed for us by a contractor on WS 5.x. I have taken their code and amended it, and successfully tested it on Tomcat 5.5. They have deployed it on WS 6.x and it won't start up.

The web.xml file shipped to them in the war file contains a context parameter log4j_props which points to the log4j properties file for the app. As shipped, this contains a DOS path to the file in my development environment. After deploying the app, they have edited the web.xml so that the parameter value is now the correct Unix path to the file as deployed.

After stopping and restarting the app, it still fails to start - log messages indicate that the application is still trying to locate the properties file at the old location and appears to be completely ignoring the changes made to web.xml.

The client's WS admin says he has been editing the web.xml located at

config/cells/cell_name/applications/ear_name/deployments/app_name/war_name/WEB-INF

which is supposed to be the cached copy, but this doesn't seem to be being read

All suggestions welcome

Richard

[Bobby Lewis]

Have they tried opening the ear/war and modifying the web.xml, then repackaging it and redeploying it? WAS may be reloading the file after each restart of the app or JVM from the actual war or another directory. I'm used to a different installed apps directory than the one you mention but I may be on a different version of WAS. I see mine in WAS_HOME/profiles/<profile name>installed_apps/

[Richard Jebb]

Thanks for this - I have suggested to them that they use the Assembly Toolkit (they are on WAS 6.x) to do exactly what you have suggested, to get around the caching issues. I'm waiting for feedback from them to see if that does the trick