- Context Architecture
- Context-Initialization Parameters
- Using Listeners
- Context and Attributes within a Distributable
- Practice Questions
- Need to Know More?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Context and Attributes within a Distributable
The behavior of these listeners in a distributable is exactly the same as the behavior of the listeners discussed in the previous section, with one notable exception: Event notification of addition, removal, or replacement affects the listener for only that context. No other context, even in the same JVM, knows about the listener events. However, some vendors do provide cross-context event capabilities.
The deployment descriptor contains the configuration for a Web application. The distributable element, by its presence in a Web application deployment descriptor, indicates that a given Web application is programmed appropriately to be deployed into a distributed servlet container. It is the only indication within the descriptor that the application is distributable. The syntax for the distributable element is shown in the following snippet:
<web-app>
<distributable />
</web-app>
When a Web application is marked as distributable, the servlet container may distribute the application to multiple JVMs. There are advantages for clustering, scalability, and failover. Because the context exists locally in the JVM (where created), the ServletContext object doesn't share memory space with other JVMs. Therefore, to manually share information between contexts, you should store this information externally in a DB or an EJB. Notice that the session is scoped to the service handling requests. However, the context is scoped to the Web container's JVM. Be careful—events and sessions are not propagated to other containers automatically. That is how you should answer any test questions about distributed applications. Vendors are free to improve on this, but answer according to how it works by default.