Scan the web.xml files that apply to the web application and merge them using the rules defined in the spec. For the global web.xml files, where there is duplicate configuration, the most specific level wins. ie an application's web.xml takes precedence over the host level or global web.xml file.
()
| 1285 | * application's web.xml takes precedence over the host level or global web.xml file. |
| 1286 | */ |
| 1287 | protected void webConfig() { |
| 1288 | /* |
| 1289 | * Anything and everything can override the global and host defaults. This is implemented in two parts: |
| 1290 | * |
| 1291 | * - Handle as a web fragment that gets added after everything else so everything else takes priority |
| 1292 | * |
| 1293 | * - Mark Servlets as overridable so SCI configuration can replace configuration from the defaults |
| 1294 | */ |
| 1295 | |
| 1296 | /* |
| 1297 | * The rules for annotation scanning are not as clear-cut as one might think. Tomcat implements the following |
| 1298 | * process: |
| 1299 | * |
| 1300 | * - As per SRV.1.6.2, Tomcat will scan for annotations regardless of which Servlet spec version is declared in |
| 1301 | * web.xml. The EG has confirmed this is the expected behaviour. |
| 1302 | * |
| 1303 | * - As per http://java.net/jira/browse/SERVLET_SPEC-36, if the main web.xml is marked as metadata-complete, |
| 1304 | * JARs are still processed for SCIs. |
| 1305 | * |
| 1306 | * - If metadata-complete=true and an absolute ordering is specified, JARs excluded from the ordering are also |
| 1307 | * excluded from the SCI processing. |
| 1308 | * |
| 1309 | * - If an SCI has a @HandlesType annotation then all classes (except those in JARs excluded from an absolute |
| 1310 | * ordering) need to be scanned to check if they match. |
| 1311 | */ |
| 1312 | WebXmlParser webXmlParser = new WebXmlParser(context.getXmlNamespaceAware(), context.getXmlValidation(), |
| 1313 | context.getXmlBlockExternal()); |
| 1314 | |
| 1315 | Set<WebXml> defaults = new HashSet<>(); |
| 1316 | defaults.add(getDefaultWebXmlFragment(webXmlParser)); |
| 1317 | |
| 1318 | Set<WebXml> tomcatWebXml = new HashSet<>(); |
| 1319 | tomcatWebXml.add(getTomcatWebXmlFragment(webXmlParser)); |
| 1320 | |
| 1321 | WebXml webXml = createWebXml(); |
| 1322 | |
| 1323 | // Parse context level web.xml |
| 1324 | InputSource contextWebXml = getContextWebXmlSource(); |
| 1325 | if (!webXmlParser.parseWebXml(contextWebXml, webXml, false)) { |
| 1326 | ok = false; |
| 1327 | } |
| 1328 | |
| 1329 | ServletContext sContext = context.getServletContext(); |
| 1330 | |
| 1331 | // Ordering is important here |
| 1332 | |
| 1333 | // Step 1. Identify all the JARs packaged with the application and those |
| 1334 | // provided by the container. If any of the application JARs have a |
| 1335 | // web-fragment.xml it will be parsed at this point. web-fragment.xml |
| 1336 | // files are ignored for container provided JARs. |
| 1337 | Map<String,WebXml> fragments = processJarsForWebFragments(webXml, webXmlParser); |
| 1338 | |
| 1339 | // Step 2. Order the fragments. |
| 1340 | Set<WebXml> orderedFragments = WebXml.orderWebFragments(webXml, fragments, sContext); |
| 1341 | |
| 1342 | // Step 3. Look for ServletContainerInitializer implementations |
| 1343 | if (ok) { |
| 1344 | processServletContainerInitializers(); |
no test coverage detected