4

Is it advisable to change web.xml (or, in fact, any other file) in app server after the deployment? Do ALL app servers expose their deployment/directory structure?

I would prefer making changes locally, re-building the war (or .ear, etc.), and re-deploying the application.

halfer
  • 19,824
  • 17
  • 99
  • 186
Sudhanshu Umalkar
  • 4,174
  • 1
  • 23
  • 33

1 Answers1

3

Regarding your first question, it depends on the type of the resource. For a classpath resource, you can override the file in any directory that has a higher priority in the class loading mechanism of your application server ($CATALINA_HOME/lib for instance if you're using Tomcat). For an xml file, like web.xml, you can declare an external entity in the packaged file with an absolute path, but you have to be sure that the file will be present on the target server. For instance, your packaged web.xml could look like that:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document [
<!ENTITY webEntity SYSTEM 'C:\Temp\web.xml'>
]>
&webEntity;

So the actual content of the web.xml would be the content of the file C:\Temp\web.xml.

In short, there is no official way to do it but there are tricks. I guess, what people do is to produce a custom package for each production site. There are multiple ways to automate this with Maven like war overlay or classifiers. Here is an interesting link.

Regarding your second question, I would not rely on this assumption. It's quite straight-forward to modify an exploded resource on a Tomcat server but it's is not that simple on a JBoss AS.

halfer
  • 19,824
  • 17
  • 99
  • 186
benweet
  • 3,685
  • 1
  • 21
  • 26
  • 1
    @BalusC noted here: http://stackoverflow.com/questions/25928486/tomcat-include-another-xml-file-to-web-xml that the ENTITY approach is an XXE vulnerability and is scheduled to be patched. I definitely wouldn't go that route. https://bugzilla.redhat.com/show_bug.cgi?id=1069911 – josh-cain Sep 02 '15 at 19:48