Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Servlet 3.0: A Sneak Preview : Page 3

Find out which features in the upcoming Servlet 3.0 specification will affect a major change in the way developers build Java web applications.


advertisement

Pluggability Through Web Frameworks

As discussed previously, Servlet 3.0 includes enhancements to enable you to plug frameworks and libraries into a web application. This pluggability reduces the number of configurations and provides good modularity for web applications. Servlet 3.0 achieves pluggability through web module deployment descriptor fragments (or web fragments, for short).

A web fragment is a part of the web.xml file specified and included in the framework-specific JAR's META-INF directory. A web fragment provides logical partitioning of the web application without your having to edit the web deployment descriptor for framework-specific components.

The elements (tags) used in the web fragment are almost the same set of elements (tags) used in the deployment descriptor, except the root element (parent tag). The root element for the web fragment should be web-fragment, and hence the file should be called web-fragment.xml. The container will look for web-fragment.xml only in the JAR file placed under the WEB-INF\lib folder. If the JAR file under the lib directory has any web-fragment.xml files, the container will load the required classes and process them.



Just as the Servlet name is expected to be unique in a given web.xml file, the same logic applies to web fragments as well. In addition, the Servlet name must be unique in the entire web application, including the web.xml and all the web fragments.

As an example, the following web-fragment.xml is placed under the jars\META-INF directory of frameworks:

web-fragment.xml <web-fragment> <servlet> <servlet-name>ControllerServlet</servlet-name> <servlet-class>com.app.control.ControllerServlet</servlet-class> </servlet> <listener> <listener-class>com.listener.AppServletContextListener</listener-class> </listener> </web-fragment>

The framework JAR file is placed under the WEB-INF\lib directory. The Servlet 3.0 specification does not define the ordering of configuration from web-fragment.xml and annotations, but it does define the ordering of configuration of web.xml and web-fragment.xml as follows:

  1. Absolute ordering
  2. Relative ordering

Figure 1. Absolute Ordering in Servlet 3.0: You achieve absolute ordering with the help of the <absolute-ordering> element in the web.xml file.

You achieve absolute ordering with the help of the <absolute-ordering> element in the web.xml file (see Figure 1). This element has a child element <name> that specifies the names of web fragments and thus the absolute ordering of the web fragments to be processed. If multiple web fragments have the same name, the container ignores the web fragment that appears second.

web.xml <web-app> <name>DemoApp</name> <absolute-ordering> <name>WebFragment1</name> <name>WebFragment2</name> </absolute-ordering> ... </web-app>

Figure 2. Relative Ordering in Servlet 3.0: You achieve relative ordering with the help of the <ordering> element in the web-fragment.xml file.

You achieve relative ordering with the help of the <ordering> element in the web-fragment.xml file (see Figure 2). The container would look upon this element only if there is no entry of <absolute-ordering> in web.xml. The ordering of the web fragments is decided by the <before>, <after>, and <others> elements. If any of the web fragments has a <before> child element, the file will be moved to the beginning of the list of sorted documents. Similarly, if any of the web fragments has an <after> child element, the document will be moved to the end of the list of sorted documents.

To understand the relative ordering better, consider some examples. The following example assumes that three JAR files each has a web-fragment.xml file.

web-fragment.xml <web-fragment> <name>WebFragment1</name> <ordering><after>WebFragment2</after></ordering> ... </web-fragment> web-fragment.xml <web-fragment> <name>WebFragment2</name> .. </web-fragment> web-fragment.xml <web-fragment> <name>WebFragment3</name> <ordering><before><others/></before></ordering> .. </web-fragment>

The files will be processed in the following order:

  1. WebFragment3
  2. WebFragment2
  3. WebFragment1

The JAR file having WebFragment3 will be processed first because of the <before> element. This setup insures that the document is placed on top of the list. The JAR file having WebFragment2 will be processed next, because the JAR file with WebFragment1 uses the <after> element, which pushes the document to the end of the list of documents to be processed. The <others> element nested within the <before> and <after> elements ensures that the documents are pushed to the top and the bottom of the list, respectively.

If web.xml encounters both <absolute-ordering> and <ordering> elements, it ignores the <ordering> element; it considers only the absolute ordering because that element appears first. Similarly, if the <ordering> element appears first and is followed by the <absolute-ordering> element, then the container ignores <absolute-ordering> because it considers only the relative ordering. If a deployment descriptor does not have <absolute-ordering> (in the web.xml) and <ordering> (in the web-fragment.xml), then the documents are assumed not to have any ordering dependency.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap