Engineering Full Stack Apps with Java and JavaScript
Annotations were introduced to reduce the burden of Application assemblers who would otherwise have to combine every developer’s configuration details into the web.xml file. Thus annotations allow for pluggability of the code by allowing developers to specify configurations on their own classes and hence application assemblers would not have to add them to the web.xml file. We can still use web.xml to override any of the configuration given by an annotation. We may also use the web.xml element metadata-complete with a value of true to ignore any other configuration details such as annotations or web fragments.
Web fragments are xml files that will have part of the configurations of a web.xml. There can be many web fragments, and when the application is deployed container will combine all the fragments and will treat it like a single web.xml. Similar to annotations, now developers can write web fragments for their modules and application assemblers would not have to add them to the web.xml file. We can override annotation behavior with a web fragment or web.xml. Container will first process web.xml and then based on any order defined (if any) process web fragments and finally will process annotations for any metadata that is not already defined in web fragment or web.xml. You may also specify the order of invocation of web fragments from within the web fragment.
When annotations were already there to support modularity, why you need a web fragment? Not everything which can be defined using a web.xml can be configured using annotations. This includes most JSP related configurations and the welcome-lists. You may also want to quickly override some of the details configured as annotations without recompiling the code, which can be done through xmls like web.xml or web fragments. However using a web.xml to override the annotation behavior will again increase the overhead of application assemblers. So web fragments are a better solution for overriding annotation behavior and can be supplied by the same developers itself. Another advantage of web fragments over annotations is that ordering of components using annotations is not defined, whereas we can specify order for web fragments.
Syntax and rules for defining web fragments
Ordering web fragments
Within a web.xml or a web fragment, elements are loaded in the order they are declared. Ordering of components using annotations is not defined. Ordering of web fragments are also not defined by default, but they can be ordered using <absolute-ordering> in a DD or <ordering> element in a web fragment.
You can specify the order of web fragments from within a web fragment itself using the element <ordering>. <ordering> has two subelements <before> and <after>, and they can contain any <name> elements and fragments declared inside <before> will be loaded before this fragment and fragments declared inside <after> will be loaded after this fragment. Both subelements <before> and <after> may also contain an <others/> element which will refer to all other elements not explicitly named.
<web-fragment>
<name>fragment2</name>
<ordering>
<before>
<name>fragment3</name>
<others/>
</before>
<after>
<name>fragment1</name>
</after>
</ordering>
<web-fragment>
You can specify the order of web fragments from within a web.xml using the element <absolute-ordering>. Order specified by <absolute-ordering> will override any conflicting ordering specified by <ordering>.
The <absolute-ordering> may contain <name> elements and the <others/> element. The <others/> element which will refer to all other elements not explicitly named. If an <others/> element is not present and an element is not explicitly defined, that fragment configuration is completely ignored.
<web-app>
<absolute-ordering>
<name>fragment1<name>
<name>fragment2<name>
<others/>
<name>fragment3<name>
</absolute-ordering>
</web-app>
You will be clearer about web fragments once you do the demo (next note.)