Shared web.xml

[rmaucher]

The web container uses a shared web.xml to do a lot of its webapp configuration, including its default Servlet, the JSP implementation, SSI, CGI, etc. There are then hooks for deployers (ok, probably something which might be going away too) to expand programmatically on this shared metadata. Also rounding up this shared web metadata are TLDs for all shared tag libraries (also available for expansion programmatically).

One strategy which could fit the requirements is to keep the shared web.xml relatively hidden away yet user editable, and provide a few specialized elements in the domain model to configure the most immediately important features (like the Jasper "dev" flag, the directory listing, enabling CGI or SSI, adding - not removing or anything complex - a mime mapping, adding a selection of the container provided filters). And for the rest, this is out of the scope of the domain model and the user needs to edit web.xml.

Comments ?

Note: This discussion is similar for other EE containers, which might want to  use standard spec files to configure their containers.

[ssilvert]

Most of that sounds reasonable to me.

But forgiving my ignorance, why would the hooks for deployers go away?  How would deployers add web metadata to a deployment?

Stan

[brian.stansberry]

I think what you propose makes the most sense. There's no way every little detail of everything our underlying projects support is going to be configurable via the domain. What's configurable via the domain is the stable configuration that we expose via our management tools. Stuff that's stable and that users are likely to want to configure should go in the domain config if they can.

For things that don't get into the domain schema, some users are still going to want to poke under the covers and tweak things. So, "relatively hidden away yet user editable" makes sense. The key thing is the contents of those files are not going to be represented in the management API, there's not such a strict compatibility guarantee going forward, and the domain management infrastructure can't be responsible for keeping that file in sync around all the servers in the domain -- that's the user's responsibility.

A question is what is the "relatively hidden away" location.  A simple choice is a resource in the JBoss Web integration module. Issues with that:

1) Patching. If users edit this file, and then a patch that comes out that modifies the file, we have a conflict and the patch fails. I don't see this is an argument against putting this in the integration module; the patching process is going to face this problem elsewhere.

2) Single shared web.xml across the domain, i.e. if you have multiple server-groups in your domain and they use different web container configs, they must use the same shared web.xml.