Filters are configured in the __________ file of a web application.
- filter-config.xml
- filter.xml
- web-config.xml
- web.xml
Filters are configured in the web.xml file of a web application.
The __________ method is called by the web container to indicate to a filter that it is being taken out of service.
- close()
- destroy()
- release()
- terminate()
The destroy() method is called by the web container to indicate to a filter that it is being taken out of service.
If a filter needs to perform different actions based on whether the request is an HTTP GET or POST, where should this logic be implemented?
- In the destroy() method
- In the doFilter() method
- In the init() method
- In the service() method
The logic for different actions based on HTTP GET or POST requests should be implemented in the doFilter() method of the filter. This method is responsible for processing the request and can be customized for different scenarios.
How would you ensure a filter only processes requests for a specific servlet?
- Check the servlet name in the configuration
- Set a specific attribute in the request
- Use if conditions in the doFilter() method
- Use the url-pattern in the filter mapping
To ensure a filter processes requests for a specific servlet, configure the filter mapping in the deployment descriptor (web.xml) using the url-pattern element with the appropriate servlet mapping.
How does the load-on-startup element in web.xml affect a servlet's lifecycle?
- It controls the number of instances created for a servlet when handling client requests.
- It decides whether a servlet should be loaded automatically or on demand.
- It determines the order in which servlets are initialized when the application starts.
- It specifies the maximum number of times a servlet can be loaded during the application's lifecycle.
The load-on-startup element in the web.xml file specifies the order in which servlets should be initialized when the application starts. Servlets with lower values are initialized first.
Describe how you would configure a filter to initialize with predefined parameters.
- Implement the init() method in the filter
- Set parameters in the doFilter() method
- Use a configuration file
- Use the
in the deployment descriptor
To configure a filter with predefined parameters, use the element in the deployment descriptor (web.xml) to specify initialization parameters. These parameters can be accessed in the filter using the getInitParameter() method.
What is the correct order of method invocation in a filter's lifecycle?
- destroy(), init(), doFilter()
- doFilter(), init(), destroy()
- init(), destroy(), doFilter()
- init(), doFilter(), destroy()
The correct order of method invocation in a filter's lifecycle is init(), doFilter(), and destroy().
How can a filter chain be used to implement security checks in a web application?
- Bypass the filter chain for security checks
- Implement security logic in each filter
- Include multiple filter instances in the chain
- Use only a single filter for all security checks
A filter chain can be used to implement security checks by including multiple filter instances, each responsible for a specific security aspect, and processing them in the order they are configured.
What happens if a filter in the filter chain does not call the doFilter() method?
- An exception is thrown
- The filter chain continues processing without the filter
- The request processing stops
- The response is sent to the client directly
If a filter does not call the doFilter() method, the request processing stops, and the subsequent filters in the chain and the servlet are not invoked.
How does filter ordering affect the processing of requests and responses in a servlet application?
- Filter ordering has no impact on processing
- Filters are always processed in a random order
- Filters are processed in the order they are declared
- Filters are processed in the reverse order they are declared
Filter ordering affects the processing of requests and responses in a servlet application. They are processed in the reverse order they are declared in the deployment descriptor, affecting the sequence of their execution.