Java Enterprise and Web Technologies

To solve this question, the user needs to know the naming convention and location of the deployment descriptor for a web application.

The deployment descriptor is an XML file that contains information about the web application, such as the servlets, filters, and other components that make up the application. It is used by the web server or servlet container to configure the application at runtime.

Now, let's go through each option and explain why it is right or wrong:

A. \doc-root\dd.xml: This option is incorrect because the deployment descriptor must be located in the WEB-INF directory of the web application. Therefore, option A is not a valid location for the deployment descriptor.

B. \doc-root\web.xml: This option is incorrect because the deployment descriptor must be located in the WEB-INF directory of the web application. Therefore, option B is not a valid location for the deployment descriptor.

C. \doc-root\WEB-INF\web.xml: This option is correct. This is the correct location and naming convention for the deployment descriptor of a web application. The WEB-INF directory is a special directory that is not directly accessible from the web, so it is a secure location to store configuration files.

D. \doc-root\WEB_INF\dd.xml: This option is incorrect because the deployment descriptor must be named "web.xml" and it must be located in the WEB-INF directory of the web application. Therefore, option D is not a valid location or naming convention for the deployment descriptor.

The Answer is: C

The init-param element within servlet defines initialization parameters that are accessible via the ServletConfig object. These parameters are specified as name-value pairs and retrieved using getInitParameter() method in the servlet.

The exception-type element is used within the error-page element to specify which Java exception should trigger the error handling. When that exception is thrown, the container redirects to the specified location. The servlet element (option B) contains servlet configuration, not error handling. Elements named exception or error-handling (options C, D) are not standard deployment descriptor elements.

The error-page element in web.xml contains either an exception-type subelement (for Java exceptions) OR an error-code subelement (for HTTP status codes), plus a required location subelement pointing to the error page. Option A uses the non-existent exception element. Option C incorrectly uses exception as element name. Option D is missing the required location element. Only option B has the correct structure.

The welcome-file-list element is a direct child of the web-app root element in web.xml. It defines the list of files the server should look for when a client requests a directory URL. Option B (welcome-file) is a subelement within welcome-file-list, not its parent. Options C and D (servlet, file-list) are not valid parents for welcome-file-list.

Error-page configuration supports two formats: using error-code for HTTP status codes (option A) OR using exception-type for Java exceptions (option D). Both require a location element pointing to the error page. Options B and C incorrectly mix both error-code and exception-type in the same error-page element - only one should be specified per error-page entry.

The root element of the Java web application deployment descriptor (web.xml) is web-app. This element contains all other configuration elements like servlet, servlet-mapping, filter, context-param, etc. Options A (web), C (name), and D (display-name) are not the root element name, though display-name can be a subelement within web-app.

The context-param element in web.xml requires two subelements: param-name (the parameter name) and param-value (the parameter value). Option A correctly identifies param-name as required. Options B (name), C (init-param), and D (servlet-name) are incorrect - name is not a valid element, init-param is for servlet configuration, and servlet-name is used elsewhere in the descriptor.

The jsp:setProperty tag with property="*" is a special shorthand that automatically sets all bean properties to matching request parameters. For each property in the bean, it looks for a request parameter with the same name and sets the value using appropriate type conversion. Option A is wrong - setProperty does have a property attribute. Option B is wrong - * is a valid special value. Option C is wrong - * is a wildcard, not a literal string value.

The correct URI for JSTL 1.1 core library is http://java.sun.com/jsp/jstl/core. This follows the standard pattern for JSTL 1.x taglib URIs. The other options are incorrect: they omit 'jstl' or use incorrect versioning.

A WebLogic Domain must have exactly one Administration Server, which serves as the central management point. The number of Managed Servers is optional - you can have zero, one, or many Managed Servers depending on your scalability needs. Options A and C incorrectly specify fixed numbers of Managed Servers.

Oracle WebLogic Server is a Java EE application server. While it includes web server capabilities (handling HTTP), its primary role is providing a platform for developing and deploying multi-tier distributed enterprise applications, including business logic and database connectivity, which distinguishes it from a simple web server.

WebLogic Server can deploy multiple archive formats: WAR files for web applications, EAR files for enterprise applications (which can contain multiple modules), and SAR files for service archives. 'All of the above' is correct because WebLogic supports all these deployment formats, not just one type.

WebLogic Server has two primary modes: Development mode (auto-deployment enabled, faster startup, lower security) and Production mode (no auto-deployment, better performance, higher security). 'Staging' is not a WebLogic mode - staging is related to deployment stages or environment, not a server operation mode.