Hello, We have noticed that when "Resources" tag is declared in context.xml, it hides PostResources declaration in a given context in server.xml. When we copy the same context and put it in a separated file (under [engine]/[host]/[context].xml, everything runs correctly so I guess that this is a bug because we don't have the same behaviour for a given context. We have reproduced this on all Tomcat 8.0.x and 8.5.x so far.
I've confirmed the described behaviour with trunk (9.0.x) and I agree that expecting the same behaviour when the Context is defined in server.xml and in a separate file is a reasonable expectation. Next up is looking into why this is.
When a Context is defined in a dedicated file the order of events is: a) Create Context object b) configure from conf/context.xml c) update configuration from dedicated file When a Context is defined in server.xml the order of events is: 1) Create Context object 2) configure from server.xml 3) update configuration from conf/context.xml Ideally, we want to swap 2) and 3). Note: - b, c and 3 happen in ContextConfig - Defining Contexts in server.xml is strongly discouraged - This problem is not limited to Resources. It applies equally to any Context configuration. Re-ordering 2) and 3) is tricky as 1) and 2) happen in the digester while server.xml is being parsed. Changing the order is possible but would be very invasive. It is already possible to disable 3) by setting override="true" in the Context defined in server.xml (although that does mean all settings from conf/context.xml will be ignored). We could change the default of override for Context's defined in server.xml but I am concerned that that will break existing configurations. E.g. where resources are defined only in conf/context.xml to make common resources available to multiple web applications. I'm currently leaning towards addressing this issue with a documentation change.
Thank you for your quick feedback, we will follow this issue.
Fixed in: - trunk for 9.0.13 onwards - 8.5.x for 8.5.35 onwards - 7.0.x for 7.0.92 onwards
Thanks for the fix, so what did you change in the resources loading behaviour?
I didn't. I just updated the docs to note the current behaviour and to point out the use of the override attribute to avoid it.