Java Enterprise Architecture Quiz - Patterns, Spring, and Servlets

Session attributes are shared across all servlets within the same ServletContext (web application). When you store an attribute in an HttpSession using setAttribute(), any other servlet in the same application can retrieve it using getAttribute() on the same session (identified by the same session ID). This sharing is a key purpose of session attributes - to maintain user-specific state across multiple servlets/JSPs in the application. Different ServletContexts have separate session scopes.

HttpServletRequest.getSession(true) returns the current session or creates a new one if none exists. The boolean parameter 'create' controls this behavior: true means create if needed, false means return null if no session exists. Option A (getSession(false)) would return null instead of creating a session. The method getSession() with no arguments is equivalent to getSession(true) - it also creates sessions.

Option C is FALSE (making it the correct answer to 'which is NOT true') because ServletContext has no getParameter() method - the correct method is getInitParameter(). Options A, B, and D are all TRUE: ServletContext init parameters are configured in web.xml, meant for data that rarely changes (like database connection strings), are application-wide (shared by all servlets), and are accessed using getInitParameter(String name).getParameter() methods exist on HttpServletRequest, not ServletContext.

ServletRequest.getInputStream() is declared in the ServletRequest interface and returns a ServletInputStream for reading the request body as binary data. Options A, B, and C are wrong because getMethod(), getHeader(), and getCookies() are declared in HttpServletRequest (which extends ServletRequest), not in ServletRequest itself. ServletRequest contains fundamental methods like getParameter(), getAttribute(), getInputStream(), and getReader(), while HttpServletRequest adds HTTP-specific methods.

In the init(ServletConfig) method, the ServletConfig object is passed as a parameter and can be accessed directly. The getServletConfig() method returns this stored config object, which is useful in other methods throughout the servlet lifecycle. getServletInfo() returns servlet information (not config), and getInitParameters() is not a standard method.

Spring is primarily used in integration testing to test how different components work together. It allows you to load the application context, wire beans together, and test interactions between components in a near-production environment. Stress testing focuses on system limits, and regression testing checks for bugs in existing functionality.

Spring defines five bean scopes: singleton (default), prototype, request, session, and global session. 'response' is NOT a valid scope in Spring - the option list includes singleton, prototype, and request, which ARE all valid Spring scopes, making 'response' the correct answer for what is NOT defined.

The ApplicationContext is Spring's bootstrap mechanism that loads all high-level entry-point objects required by your application. It provides configuration for the application, reads bean definitions, and assembles them at runtime. Application scope is a bean scope, and Application Integration is not a standard Spring term.

An Aspect is a Java class that encapsulates one or more advices (logic like logging, security, transactions) applied to multiple points in an application. A pointcut defines WHERE advice is applied, and a join point is a specific execution point where advice can be applied. The aspect class contains both pointcuts and advices.

Spring supports constructor injection (via dependencies in constructor), setter injection (via setter methods), and field injection (via annotations). Interface injection is NOT supported by Spring - it was part of early DI frameworks but Spring chose not to implement it, preferring the other three approaches.

Spring supports two types of transaction management: programmatic (manually managing transactions in code) and declarative (using annotations or XML configuration). Both approaches are valid and commonly used depending on the use case. Programmatic gives fine-grained control; declarative is cleaner and preferred for most cases.

In Ant build scripts, the Target tag is the fundamental execution unit - you invoke a target to run a specific build process. Targets contain tasks like compile, deploy, copy. When you run 'ant targetname', you're invoking a Target tag. Deploy, Compile, and Copy are tasks within targets, not the invoking mechanism.

An Ant build.xml file can contain any number of target tags - there's no fixed limit. Each target represents a named sequence of tasks that can be executed independently or as dependencies of other targets. Common practice is to have multiple targets like init, compile, test, deploy, clean, etc.

You can rename build.xml to any name you like - Ant doesn't hardcode the filename. When running Ant, you specify the build file with the -f or -file flag (e.g., 'ant -f my-build.xml'). The default is build.xml only for convenience, not as a requirement.

In Ant build scripts, the property tag is used to declare variables. Properties are name-value pairs that can be referenced throughout the build script using ${property.name} syntax. 'file', 'variable', and 'declare' are not valid Ant tags for declaring properties.

The Project tag is the root element in an Ant build script - all other elements (targets, tasks, properties) are nested within it. Every valid build.xml must start with a tag as the root. 'Root', 'Directory', and 'folder' are not valid Ant tags.

The tag in Apache Ant build tool is specifically designed to display messages to the console during build execution. This is the standard way to output build progress or debug information in Ant build scripts. The other options (print, out, write) are not valid Ant tags for console output.

In Ant build tool, the 'depends' attribute of a target specifies which other targets must execute before the current target. These dependent targets are referred to as pre-targets and are executed in the order they are listed in the depends attribute.

The Decorator pattern attaches additional responsibilities to an object dynamically. It wraps an object (both implement the same interface) to add behavior without modifying the original class, providing a flexible alternative to subclassing for extending functionality.

The Facade pattern provides a simplified interface to a complex subsystem. One class exposes a high-level interface that coordinates multiple underlying classes, making the subsystem easier to use without exposing its complexity.