}w!"#$%&'()+,-./012345<ya

Transcription

1 MASARYK UNIVERSITY FACULTY OF INFORMATICS w!"#$%&'()+,-./012345<ya Automated Migration of Seam 2 Applications to the Java EE 6 Environment DIPLOMA THESIS Bc. Jozef Hartinger Brno, January 2012

2 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: Mgr. Petr Ročkai ii

3 Acknowledgement I would like to thank Pete Muir for his comments and suggestions, Mgr. Marek Grác for consultations, reviews and the initial supervision of the thesis, Mgr. Petr Ročkai for supervising the thesis, and Martin Prpič and Eva Kopalová for proofreading. iii

4 Abstract The thesis analyzes the possibilities of an automated migration of existing Seam 2 applications to the Java EE 6 environment with the focus on the core programming model. An automated migration tool is developed as the implementation part of the thesis. iv

5 Keywords Seam, CDI, Enterprise Java Beans, Java, Java Enterprise Edition, migration, automation, dependency injection, programming model v

6 Contents 1 Software migration Manual application migration Automated application migration Conversion tools Compatibility layer Server-side component models Enterprise JavaBeans (EJB) Component types Services Seam Contexts and Dependency Injection for Java EE (CDI) Related technologies Java Persistence API (JPA) JavaServer Faces (JSF) The Classic extension API Implementation Testsuite Deployment Scopes and Contexts Passivation Seam contexts Seam scopes CDI contexts CDI scopes Emulation of Seam contexts Reference holder pattern Pull versus Push/Pull Context model Rewritable context Mapping Seam scopes to CDI Components Seam components types Roles Component creation CDI component types Automated migration of Seam components Mutable metadata in Java The discovery phase The processing phase Dependency injection vi

7 6.1 Dependency injection in Seam Dependency outjection Disinjection Dependency injection in CDI Emulation of Seam dependency injection Circular dependencies and concurrent access Events Contextual events in Seam CDI events Emulation of the Seam eventing model Interceptors EJB 3.0 Interceptors Seam Interceptors Interceptors in Java EE Automated migration of Seam interceptors Interceptor registration and lifecycle Binding annotations Interceptor ordering Other core services Conditional component installation Conditional installation of Seam components Component installation in CDI Classic extension Eager component instantiation Classic extension Conclusions A Metadata class diagram B Bootstrap activity diagram C CDI alternative metadata source API D Dependency injection algorithm E Contents of the attached CD F Manual migration steps required by the Classic extension Bibliography vii

8 Introduction Evolution, the process of change from one state to another or from one form to another, is inevitable. This is especially true for software engineering. One of the key trends in the recent decade was simplification of software development. With the expanding demand for software in many smaller organizations, the need for inexpensive software solutions led to the growth of simpler, faster methodologies that develop running software, from requirements to deployment, quicker and easier. The use of rapid-prototyping evolved to lightweight methodologies which attempted to simplify many areas of software engineering including requirements gathering and reliability testing for the growing, vast number of small software systems. [17] The way server-side applications are developed in Java has changed in recent years. The Java Enterprise Edition (Java EE) is a widely used standardized platform for serverside programming. Java EE has been following recent trends in software engineering and adapting to developers needs. Open-source projects, which gained huge popularity, such as Hibernate or Spring, have been a significant source of innovation for the Java EE platform. Existing software applications represent a valuable asset to organizations. Although the benefit of using a more modern technology is often substantial, the migration process is rarely a simple task. Chapter 1 lays the groundwork of the thesis by explaining the specifics of the software migration process and possible ways of its execution. One of the technologies that largely influenced the recent version of Java EE is the Seam Framework. At times, when the Java EE platform was lacking in certain areas such as state management, extensibility and rapid application development support, Seam provided an integrated application stack designed to simplify development of rich web applications. Chapter 2 covers the Seam Framework and the core parts of the Java EE platform. Chapter 3 introduces the Classic extension, which was developed as part of the implementation part of this thesis. A basic overview of its architecture is provided. The problems addressed by the Classic extension and their solutions are detailed in the following chapters. The rest of the thesis deals with details of the automated application migration from Seam to the Java EE environment. Each chapter is dedicated to a specific part of the Seam programming model. The chapters share a common structure. Each chapter begins with a detailed explanation of the specific part of the Seam programming model. A comparison with Java EE follows. Each chapter contains a section describing how a particular area is covered by the Classic extension. Chapter 4 delves into contexts and scopes. Chapter 5 explains the notion of an application component and deals with their migration. Chapter 6 focuses on the dependency injection mechanism. Chapters 7 and 8 are dedicated to events and interceptors. Chapter 9 looks into the other core services of, Seam such as conditional installation and eager component instantiation, and describes the way they are emulated by the Classic extension. The outcome of the implementation part of the thesis is provided on the attached compact disk, as described in Appendix E. 1

9 Chapter 1 Software migration Software migration is the process of moving from the use of one operating environment to another. In general, the target environment is usually considered to be better with regards to provided functionality, performance or efficiency. The main goal of software migration is to leverage the target environment while retaining the original functionality. When migrating existing applications, two tasks are involved: Data migration Data migration is the process of transforming data from one form to another. In the context of application development, data migration usually consists of migration between different formats of data representation (e.g. different schemas of a relational database). This thesis does not address data migration. Application migration Applications based on older technologies (also referred to as a legacy applications ) often provide core services. Based on the level of difference between the operating environments, application migration may involve substantial changes in the application source code. These changes are needed for an application to adapt to a different Application Provider Interface (API). The target operating environment may also lack alternatives to functionality provided by the source operating environment. In that case, it is necessary to emulate these parts of the source environment. This emulation consists of building a codebase that has the interface and behavior similar to the original runtime. The following approaches to application migration exist: 1.1 Manual application migration As with other manual tasks, there are many disadvantages associated with manual application migration. It usually requires a complete software development cycle. As a result, the process can become time and resource-consuming. Furthermore, manual application migration always imposes risk. It is a well-known fact that human activities are prone to mistakes. Another risk factor is the fact that legacy applications are often poorly documented, and the original developers may no longer be avail- 2

10 1.2. AUTOMATED APPLICATION MIGRATION able. Given these arguments, manual migration of software is generally considered to be appropriate for small to medium size applications only. This thesis documents differences between the programming models and documents the process of emulating the lack of functionality in the target environment. Therefore, this thesis should serve as a high-level reference for manual migration. 1.2 Automated application migration Re-implementing applications on new platforms can reduce operational costs, and the additional capabilities of new technologies can provide access to functions such as web services and integrated development environments. Once the migration process has been completed and the migrated application is functionally equivalent to the previous non-migrated version, new features can be added to the application so that the application can meet current and future business needs more accurately. The main disadvantage of the automated approach to software migration is the initial cost necessary to develop a migration tool. Complexity of such a project can be significantly higher compared to the complexity of the migration process itself. The recent development of new technologies, such as program transformation by software modernization enterprises, have made the legacy transformation process a cost-effective and accurate way to preserve legacy investments and thereby avoid the costs and business impact of migration to entirely new software. Provided that an automated migration tool of proper quality is already available, automated software migration should always be preferred over manual migration. Under such conditions, software migration usually consumes a fraction of time and resources that would be necessary for manual migration. Nevertheless, the migration process can rarely be completely automated and certain level of human interaction is always necessary Conversion tools The most common way to migrate software automatically is to transform the original application into a version capable of running in the target environment. This involves the same type of modifications as if the application was migrated manually. Once this process is completed, the application runs natively in the target environment. Such conversion tools often have the form of migration scripts. Scripts can be easily developed yet they are extremely powerful in cases where semantics of the source environment is not distant from the semantics of the target environment, and the scripts handle mostly syntactic conversion Compatibility layer A compatibility layer forms an interface between the application and the hosting environment. Unlike migration scripts, a compatibility layer does modify the legacy application. 3

11 1.2. AUTOMATED APPLICATION MIGRATION Instead, the compatibility layer enables the original application to run in the target environment without being changed. This is achieved by translating native interaction of the application into an interaction that the target environment understands [15]. Because the translation occurs at run time, speed penalty is often one of the limitations of compatibility layers. Moreover, depending on the architecture of the source and target environments, it may not always be possible to implement the compatibility layer. It is necessary for the target environment to provide sufficient level of extensibility. 4

12 Chapter 2 Server-side component models This chapter introduces server-side component models, which are related to this thesis. A component is a self-contained element of software that can be controlled dynamically and assembled to form applications. It constitutes a building block for application development. Components encapsulate the business logic of an application. Component models define a set of rules and guidelines for component interoperability. Such architecture leads to extensible, flexible and reusable applications. As the application evolves, components can be modified, extended and reassembled to reflect changed requirements. General-purpose components can be shared between multiple applications. In server-side component models, components are managed by an application server (often referred to as a container ). This involves management of the life-cycle of a component. Components are often provided with additional services, which allow them to abstract from low-level details and focus on the business logic instead. 2.1 Enterprise JavaBeans (EJB) Enterprise JavaBeans is a server-side component architecture for modular construction of enterprise applications. It is one of the key elements of the Java EE specification. It provides a standardized component model for implementing back-end business logic of an application. When developing applications, there is often a need to deal with the same types of problems such as communication with the persistence layer, asynchronous communication and others. EJB is a managed component model. That means that EJB components are provided with a set of services supplied by the application server [4] Component types The most recent version of the EJB specification (3.1) defines two major types of components: Session beans and Message driven beans. Session beans can be divided into stateless, stateful and singletons. Stateful session bean Stateful session beans are capable of maintaining state. This state is kept in memory. The EJB specification does not scope the life-span of a stateful session bean. Thus, a client is responsible for management of the lifecycle of a stateful session bean. 5

13 2.1. ENTERPRISE JAVABEANS (EJB) Stateless session bean Stateless session beans are business components which do not maintain any state. A method invocation on a stateless session bean is independent of method invocations executed previously on the same instance. Because no state is kept, stateless session beans can be shared for serving different requests. As a result, the overhead associated with stateless session beans is lower compared to stateful session beans. Example illustrates a simple stateless session public class CustomerService private EntityManager entitymanager; public void addcustomer(customer customer) { entitymanager.persist(customer); Example 2.1.1: Sample stateless session bean Singleton Singleton session beans are used for keeping shared, application-wide state. Concurrent access to component s state can either be configured declaratively and handled by the container or handled by the component itself. Message driven bean A message driven bean is a component providing integration with another Java EE specification Java Messaging Service. Unlike session beans, execution of a method of a message driven bean is asynchronous and triggered by an incoming message Services EJB components are provided with services which provide abstraction over common infrastructure tasks. Declarative transaction management Enterprise JavaBeans allows for declarative transaction management. That means that it is not necessary for components to explicitly control transaction boundaries. Instead, the container handles transaction management. By default, there is always an active transaction for a session bean method invocation. Container-managed transactions can be configured using annotations. 6

14 2.2. SEAM Declarative security The EJB Container is responsible for ensuring the client code has sufficient access rights to an EJB component. This involves both authentication and authorization. Remote execution A session bean can define remote interfaces. As a result, such a bean can be accessed remotely over the network using remote method invocation (RMI), which is a Java-specific equivalent of the remote procedure call type of communication. This enables EJB components to be used within distributed systems. Concurrency and asynchronous processing Java EE has support for asynchronous processing. EJB components can benefit from the following variants: asynchronous method invocation schedule task execution using TimerService asynchronous notification using messaging 2.2 Seam Seam is an extension to Java EE. There are multiple versions of Seam. Because differences between Seam 2 and Seam 3 are significant, it is important to distinguish between them. Unless the version is explicitly stated, the term Seam refers to version 2 of the Seam framework hereafter. Originally, Seam was developed on top of Java EE 5 to fill in some of the absent spots of the platform, mainly integration between EJB components and the presentation layer (JavaServer Faces). Seam introduces light-weight Seam-managed components whose lifecycle is bound to well-defined contexts. Besides, the contexts already introduced in the Java EE specification, additional contexts are provided. Seam components complement the EJB programming model. Firstly, Seam-managed components can benefit from EJB-like services while additional services are provided, such as contextual dependency injection. Secondly, the additional services are available for EJB components as well. Gradually, an ecosystem was established around the Seam core component model turning Seam into an application stack. This involves integration with frameworks and technologies outside of Java EE such as: RichFaces and Icefaces for building rich user interface on top of JavaServer Faces alternative presentation layers such as Wicket and Google Web Toolkit 7

15 2.3. CONTEXTS AND DEPENDENCY INJECTION FOR JAVA EE (CDI) jbpm for business process management Drools for business rules Spring RESTEasy for building web services Figure 2.1: Seam 2.3 Contexts and Dependency Injection for Java EE (CDI) In the past, the Java EE platform was often criticized for lacking support for building lightweight and reusable components. Although the EJB programming model existed, it was often perceived as complex and heavyweight. Contexts and Dependency Injection for Java EE (CDI) is a Java specification available as part of Java EE since version 6. CDI provides a lightweight programming model which includes [8] the following : A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the set of contexts is extensible. A sophisticated, typesafe dependency injection mechanism, including the ability to select dependencies at development or at deployment time, without verbose configuration. Support for Java EE modularity and the Java EE component architecture the modular structure of a Java EE application is taken into account when resolving dependencies between Java EE components Integration with the Unified Expression Language (EL), allowing any contextual object to be used directly within a JSF or JSP page 8

16 2.4. RELATED TECHNOLOGIES The ability to decorate injected objects The ability to associate interceptors to objects via typesafe interceptor bindings An event notification model A web conversation context in addition to the three standard web contexts defined by the Java Servlets specification An SPI allowing portable extensions to integrate cleanly with the container The CDI specification unifies Java EE with various parts of the platform, including deep integration with the EJB specification. The key aspect of CDI is loose coupling of components which is enabled by both the contextual dependency injection and the event notification model. Service Provider Interface (SPI) is an interface that enables a particular piece of software to be extended (e.g. by integrating with another technology). From the perspective of this thesis, the CDI SPI is an essential part of the specification because it enables portable extensions (such as the one delivered with this thesis) to be created. 2.4 Related technologies The following technologies are often used within existing Seam applications and are therefore briefly explained Java Persistence API (JPA) The Java Persistence API (JPA) is a Java specification for accessing, persisting, and managing data between Java objects and a relational database. JPA is now considered the standard approach for Object-Relational Mapping (ORM) in the Java. JPA itself is just a specification, not a product; it cannot perform persistence by itself. JPA is a set of interfaces, and requires an implementation. There are open-source and commercial JPA implementations available and all Java EE application servers should provide support for its use. [12] The JPA specification defines the notion of an entity. An entity is a lightweight Java object mapped to a relational database. The mapping is expressed using metadata (either an XML descriptor or a Java annotation). An implementation of JPA handles storing and retrieving the state of an entity in the database. Entities are usually simple state carriers which do not contain any logic 1. The specification defines the EntityManager object that offers basic operations such as loading, persisting, etc. In addition, an object-level query language similar to SQL is provided, which allows querying of the objects from the database. 1. Such architecture is also known as the anemic domain model. 9

17 2.4. RELATED TECHNOLOGIES JavaServer Faces (JSF) JavaServer Faces is a presentation layer technology used for building web-based user interfaces. Similarly to JPA, it is a Java specification with multiple implementations. JavaServer Faces is based on component-driven user interface design model. During processing of an HTTP request, a JSF implementation loads the appropriate view template, builds a component tree, processes events, and renders the response to the client. The state of UI components (and other objects) is saved at the end of each request and restored upon next creation of that view. Several types of state-saving are available, including client-side and server-side state saving. By default, the most recent version of JSF uses Facelets, which is an open-source web template system operating on view templates defined in XML. 10

18 Chapter 3 The Classic extension The Classic extension is a software module developed as the implementation part of this thesis. It implements the Seam core programming model and services on top of CDI. The Classic extension consists of the API, implementation and testsuite modules. 3.1 API The API module contains the Seam API, which has been extracted from the Seam codebase. In Seam, the boundary between the API and the implementation had never been clearly defined. Both API and implementation classes had always been bundled together. As a result, existing applications may depend on internal parts of Seam that were not intended to be used by an application. Moreover, some of the functionality intentionally requires an application to work directly with implementation classes (e.g. using static method calls) without exposing a proper API. The API module of the Classic extension contains Java interfaces and annotations that represent the Seam API. Moreover, placeholders (abstract classes) with matching signatures are provided for Seam implementation classes that an application may depend on. Actual implementations of these classes are present in the implementation module. 3.2 Implementation The Classic implementation module is an alternative implementation of the Seam core. More precisely, it is a portable CDI extension 1, which enables a Seam application to run in a Java EE environment without Seam libraries. An application still depends on the Seam API (present within the API module). The implementation module implements the API using Java EE technologies. The Classic extension performs two distinct types of activities. Firstly, the extension is active when an application is being deployed. The deployment is scanned for Seam-specific metadata and, where possible, the metadata is replaced by matching Java EE substitutes. As a result, parts of the required services are provided natively by an application server. Secondly, the Classic extension provides a compatibility layer, which emulates the remaining services at runtime. 1. Because the extension uses purely Java EE APIs, it can be run on any Java EE 6 compliant application server. 11

19 3.3. TESTSUITE 3.3 Testsuite Even though the Seam Reference documentation is quite extensive, it cannot be considered a formal specification. Many possible combinations, which are not explicitly documented, exist. Yet, an alternative implementation (such as the Classic extension) is supposed to support work in a compatible way. The Classic testsuite consists of a number of assertions which capture the behavior of the original Seam implementation. These assertions contained within both unit and integration tests are run directly in an application server and verify the compatibility of an alternative Seam implementation. 3.4 Deployment Figure 3.1 illustrates a deployment structure of a typical Seam application. The right part of the diagram illustrates the migrated application where the Classic extension replaced the Seam module. Figure 3.1: Seam application 12

20 Chapter 4 Scopes and Contexts A typical web application maintains multiple types of state. For example, the domain model state is usually kept in a persistent storage whereas the state associated with a user interaction (session state) is usually transient. State management is an essential part of both Seam and CDI. A state contained within a component is kept throughout its lifecycle. The term scope is used to refer to a life span of a component. Component scope may vary ranging from short-lived components available during processing of a single request (request scope) to components living for the entire application lifetime (application scope). Components sharing the scope are stored in the same context. Context refers to an implementation of a scope that holds the state of components. A container manages the lifecycle of a component by creating a component instance, storing it in the context and destroying the instance when the context ends. 4.1 Passivation In general, state management is a memory-intensive task. The amount of resources of an application server is always limited and the amount of primary storage (main memory) is usually lower in orders of magnitude compared to the amount of secondary storage. To resolve this problem, the passivation exists. Passivation allows the application server to free resources by transferring state from memory to the secondary storage. The reverse process is called activation. The same mechanisms are used for replication of the state among multiple application servers. A scope (either in Seam or in CDI) may be declared passivating. An object stored in such a scope may be a subject to passivation and should therefore be capable of transfering its state to the secondary storage Seam contexts Seam uses the concept of contextual variables. Such a variable, identified by a name, holds a reference to a component instance. The name uniquely identifies a contextual variable. Once Seam instantiates a new component instance, its reference is stored in a contextual variable. 1. Usually achieved by properly implementing the Serializable interface. 13

21 4.3. SEAM SCOPES Each component has its own name, which is used to identify the contextual variable in which an instance of the component is stored. A component can access contextual variables and obtain a reference to another component provided it knows its name. Besides obtaining a reference, clients are also allowed to modify the content of a context. Either declaratively or programmatically, a context variable can be set to reference any Java object (not necessarilly a Seam component). Moreover, a context variable can be unset. Contextual variables can also be read from the view layer. Scopes represent an abstraction layer that hides the difference between accessing state set by an application component and state set by an application user (e.g. by submitting an HTTP form) Figure 4.1: Contextual variables 4.3 Seam scopes Seam provides a fixed set of scopes. Each scope defines a different life span for its components. Most of the scopes have implicit boundaries. In some cases, however, explicit boundary demarcation is necessary. Seam provides seven built-in scopes, out of which six are stateful. A list of Seam scopes, ordered by their typical span starting from the narrowest one, follows: Event scope The event scope is the narrowest stateful scope. Web applications are built on the HTTP protocol and most of the time the event scope maps to a single HTTP request. Alternatively, the event scope may also be used within a remote method invocation. A state associated with the processing of the request may be demarcated by this scope. Page scope The page scope is view-layer specific and only usable with JavaServer Faces. A pagescoped component instance is kept for a series of requests carried out on the same JSF page. The page scope is backed by the component tree of a JSF page. 14

22 4.3. SEAM SCOPES Conversation scope The HTTP protocol is stateless. However, use cases exist in web applications which do not map directly to a single HTTP request. Instead, multiple requests are necessary to cover the use case (e.g shopping cart checkout wizard). For such use case, it is necessary for an application to manage its state between requests. Two options exist: store the state on the client side and resend it with every request (using either URL parameters, hidden form fields or browser cookies) store the state on the server within the session scope The conversation scope provided by Seam is an alternative option. It is designed to simplify state management of multi-request use cases. It combines advantages of both aforementioned state management approaches. Similarly to the session scope, conversation scoped state is stored on a server and is therefore easier to manage from a developer perspective. However, the conversation scope is more granular than the session scope. It has its own distinct lifecycle managed by Seam and a set of lifecycle boundaries, which are controlled explicitly by the application logic and therefore match the boundaries of a use case [11]. A conversation may be either temporary or long-running, as shown in Figure 4.2. By default, a temporary conversation exists for every web request. It is initialized after the view of a JSF request is restored and lasts until a response is rendered to a client. The lifespan of a temporary conversation scope is similar to the event scope. The only exception is a navigation redirect, which may be (and often is) part of the request processing. During processing of a request that involves a redirect, two event scopes would be active (each for a given part of a request) whereas a temporary conversation covers the entire logical request, allowing a state (for example a status message) to be preserved until a response is rendered. A temporary conversation may be turned into long-running. This causes the conversation state to be propagated for a series of request until the conversation is terminated (which turns the conversation back to temporary and, as a result, the conversation is removed after a subsequent response rendering). A conversation may never cross session boundaries. Seam provides multiple ways of conversation management: method-level annotations which after an invocation of the method mark a conversation as long-running or temporary, respectively; programmatic API represented by the Conversation and Manager built-in components; view-layer tags for controlling conversation propagation directly from the view layer; navigation directives that enable conversations boundaries to be specified in page navigation rules. 15

23 4.3. SEAM SCOPES Figure 4.2: A conversation is temporary by default but can be turned into long-running. Session scope The session scope represents a user session a set of requests originating from single identified user. Session state is kept until the user logs out or the session expires. This scope is useful for keeping state relevant to every interaction of a given user with an application, such as user identity. Seam internally uses the session context provided by the Servlet specification, where state is kept on the server and may be subject to passivation. Application scope Similarly to the session scope, the application scope also encapsulates the application context provided by the Servlet specification. State kept in this context is available applicationwide until the application is shut down. Business process scope A business process is a collection of related, structured activities or tasks that produce a specific service or product [13]. Business Process Management System (BPMS) is an enterprise software that supports modelling, deployment and management of business processes. Seam provides an integration with one of the BPMS implementations jbpm. For this purpose, a special Seam scope called business process is available. A state, associated with the business process scope is associated with the business process itself and managed by jbpm. A business process may span multiple interactions with multiple users. Context boundaries of business process are defined externally in the business process definition. The state stored in the business process context is persistent and kept across application restarts. Stateless scope In contrast to Seam scopes defined above, the stateless scope does not carry any state. Every time a component instance is requested, an independent instance is returned. In Seam, this scope is used mostly for stateless session beans, because no other scope is suitable for this type of component. 16

24 4.4. CDI CONTEXTS 4.4 CDI contexts The CDI specification recognizes two major types of scopes: Normal scopes Pseudo scopes A client view on a component stored in a context differs based on the type of scope the given context represents. When a client component obtains a reference to a normal-scoped component, it is never a direct reference. CDI places a client proxy between the client and the target component. The client proxy forwards method invocations to the actual instance of the target component. This allows components with a wider scope to reference a component instance with a narrower scope. The client proxy guarantees, that a method is always invoked on an actual instance associated with the narrower scope and therefore prevents the former component from keeping a stale reference. In addition, use of client proxies simplifies passivation. By default, when a Java object is passivated, an entire object graph (all objects referenced by the object transitively) is passivated. Supposing a passivated object would hold a direct reference to a wider-scope object, this wider-scope object would need to be passivated as well. When the reference is proxied, this is not necessary. Only a client proxy, which holds almost no state, is passivated. The client proxy is able to restore the target reference on activation. Figure 4.3: Client proxies The use of client proxies introduces limitations on types of Java objects that can be stored in a normal context. The following criteria must be met by a normal-scoped component class: it has a non-private constructor with no parameters it is not final and has no non-private non-static final method 17

25 4.5. CDI SCOPES it is not a primitive type or an array On the other hand, there are pseudo scopes where a client proxy is never required and thus no special criteria are enforced. Pseudo scopes are in this respect similar to Seam scopes. The content of a CDI context cannot be modified by clients. A context may contain at most one instance of the given component. These instances are added to the context exclusively by the container. Moreover, once set, the component instance cannot be overridden by another instance nor can it be unset. The component instance reference is kept until the context ends. These restrictions have positive implications. CDI components declare their dependencies upfront. If a normal-scoped component instance is requested and it does not exist in the context yet, it is always instantiated by the container. Given these facts, the container is able to provide certain guarantees about safety of a deployment. At deployment time, the container is able to calculate a dependency graph and determine whether dependencies of all components are satisfied and unambiguous. If this is not the case, the container refuses to deploy the application. As a result, more software bugs may be discovered at deployment time as opposed to run time when using Seam. 4.5 CDI scopes CDI provides a smaller set of built-in scopes compared to Seam. However, the CDI SPI allows extensions to provide their own scopes. Servlet scopes The request scope, session scope and application scope are direct counterparts to Seam s event scope, session scope and application scope, respectively. Similarly to Seam, these scopes are mostly backed by the Servlet contexts. Each of these scopes is a normal scope. Conversation scope The conversation scope provided by CDI is a simplified derivate of Seam s conversation scope. Similarly to Seam, a conversation can either be transient or long-running. A transient conversation (a rough equivalent to the temporary conversation in Seam) is by default active for every web request. The state of a transient conversation is not propagated across requests. Unlike Seam, a transient conversation is not even propagated across navigation redirects. A transient conversation may be marked long-running by an application. In such a case, the conversation state is preserved throughout subsequent requests until it is terminated. A long-running conversation may be terminated either by marking it as transient or automatically if it remains inactive for a given period. CDI provides an API for controlling conversations. The built-in Conversation component may be injected into application code to control conversation timeout, and transition between transient and long-running states. 18

26 4.6. EMULATION OF SEAM CONTEXTS Dependent scope The dependent scope is a pseudo scope. Unlike normal scopes, whose component instances can be shared between multiple requesting components, a dependent component is always created separately for each requesting component. Such a dependent component instance is bound to the lifecycle of the requesting component. Therefore, the same instance of the dependent component is available to the requesting component until the requesting component is destroyed. Figure 4.4: Dependent component instances are never shared by multiple clients. Because the dependent component is never shared and its lifetime is always identical to the requesting component, it is not necessary to use a client proxy. As explained later, this is an important property used heavily for backwards compatibility purposes. 4.6 Emulation of Seam contexts Two major context-related problems emerge when migrating Seam application to CDI. Due to usage of client proxies, a subset of Java types can be bound to a normal scope. This is a problem if the legacy application uses a normal-scoped component whose type cannot be proxied (e.g. an application-scoped string) Reference holder pattern Proxies are needed for cases when a component of a narrower scope (A) is used by a component with a wider scope (B). In this scenario, the client proxy guarantees that B always accesses an instance of A taken from the currently active context. Without the proxy, B would be left with a stale reference. Figure 4.5: Client proxies are not necessary in certain situations However, when a normal scoped component is always used from components with equal or narrower scope, the client proxy is not required. Nevertheless, the CDI specifi- 19

27 4.6. EMULATION OF SEAM CONTEXTS cation does not recognize this case and always requires a client proxy for a normal scoped component. Furthermore, as of CDI 1.0, there is no portable way of unwrapping the client proxy in order to obtain the direct reference. The Classic extension works around this problem by using a mechanism which has been throughout the implementation of this thesis isolated into a reusable pattern, and named the reference holder pattern. This approach uses a single-purpose component of a proxyable type that holds the direct reference. This component is bound to a normal scope while the underlying reference is exposed using a pseudo-scoped (dependent) producer method. As a result, the original component is dependent-scoped (not proxied), but because it is backed by a normal-scoped component, its actual lifecycle is the same as if the component was normal scoped. It can also be shared within multiple components just as if it was normal scoped. Figure 4.6: The reference holder pattern Pull versus Push/Pull Context model The other major context-related migration difficulty is the fundamental difference between the level of control a client has over the content of a context. CDI uses the pull-style context model where components only passively read the contextual references. The container is the only authority that may change the content of a context by storing a component instance after it is created. In contrast, Seam 2 uses the push/pull model which in addition to the pull model enables components to modify the context by overriding or unsetting values of a contextual variable Rewritable context The classic library emulates the push/pull model on top of CDI contexts. Every context is equipped with a special component called rewritable context. This component represents an inner rewritable object store. Every time a component attempts to modify the content of a context, this change is reflected within the rewritable context. Likewise, when a component 20

28 4.6. EMULATION OF SEAM CONTEXTS instance is requested, the rewritable context is checked first. If the requested component instance is found in the rewritable context, it is served from there. Otherwise, the request is delegated to the CDI context. The rewritable context internally uses a threadsafe map structure. It is necessary to modify the dependency injection mechanism to take the rewritable context into account. Chapter 6, Dependency injection explains this problem in greater detail. In addition, the fact that contextual instances are also referenced from the view layer using EL expressions has to be taken into account. Java EE provides an extension point, which allows for the EL resolution process to be altered by an extension. The extension point is represented by the javax.el.elresover abstract class. The classic extension provides its own implementation of the abstract class 2 with support for the rewritable context. The value associated with name alpha is overridden using the rewritable context. Although Instance 3 is still referenced from the context, Instance 1 is preferred by both DI and EL. Figure 4.7: Rewritable context Mapping Seam scopes to CDI Servlet scopes Both Seam and CDI define the same semantics of the application, session and event/request scope. Therefore, the migration process is straightforward. The only modification necessary is to replace the Seam scope definition with its CDI counterpart (assuming that the involved components are either proxyable or the reference holder pattern is applied). Business process scope The business process scope in Seam is implemented by integrating with a proprietary (not standardized) BPM solution as the Java EE specification does not define a portable runtime environment for running business processes. For these reasons, the business process scope is not addressed in this thesis nor is it implemented by the Classic extension. 2. cz.muni.fi.xharting.classic.bijection.rewritablecontextawareelresolver 21

29 4.6. EMULATION OF SEAM CONTEXTS Page scope The View scope is a direct equivalent to the page scope. It was added in version 2.0 of the JavaServer Faces specification. A state stored in the view scope is kept while the same JSF page is re-displayed. As soon as the user navigates to a different page, the state goes out of scope [2]. Although the JSF specification does not make the view scope accessible in other way than programmatically, portable extensions exist that provide a facade on top of the view scope for it to be usable as a CDI scope. Both Apache CODI and Seam 3 Faces are open-source project providing this functionality. When migrating an application, it is enough to include one of the mentioned implementations and change the scope declaration on all page-scoped components. The classic extension uses a modified version of the view context from the Seam 3 Faces module to implement the page scope. Conversation scope Fundamental differences exist between implementations of the conversation scope in Seam and CDI, which make the migration process complex. In Seam, for each web request a conversation exists. This conversation is temporary, which means that its state is not propagated over multiple requests unless it is marked as long-running. An equivalent exists in CDI which shares the aforementioned characteristics. The term transient conversation is used to refer to this equivalent. However, the transient and temporary conversations are not completely equivalent. If the processing of a request involves a navigation redirect, Seam treats both physical requests (the one before and the one after the redirect) as a single logical request. The state, which is stored in a temporary conversation during the first part of the request is available later when the second part is processed even if the conversation is not long-running. This feature is often used in Seam applications for displaying UI messages, where the message is generated in the first part of the request, stored in a temporary conversation, and displayed in the second part of the request. The transient conversation in CDI does not recognize the notion of a logical request and instead creates a separate transient conversation for each physical request. As a result, the state stored in a conversation during processing of the initial request is not available after a redirect. Furthermore, the conversation scope management in Seam provides a richer set of operations. Multiple long-running conversations may exist in parallel. Seam supports switching between long-running conversations. This involves both the actual implementation as well as a conversation management UI component which enables an application user to switch between parallel conversations. In addition, it is possible to nest conversations in Seam. When a nested conversation is created, the original conversation is suspended. The nested conversation owns its own set of contextual variables. When the nested conversation terminates, the original conversation is restored. Seam provides several ways of conversation management whereas CDI itself provides 22

30 4.6. EMULATION OF SEAM CONTEXTS Figure 4.8: The difference in navigation redirect handling between the transient conversation in CDI and temporary conversation in Seam. only the programmatic API. (The API can be used to build alternative controls such as a view layer component). The CDI specification does not have a built-in support for conversation switching nor does it support nested conversations. There is also a difference between temporary and transient conversations. Due to the complexity of these features, it is beyond the scope of this thesis to re-implement the features on top of CDI. The Classic extension performs the following steps automatically: Translation of scope definitions found on Seam components into the CDI conversation scope definitions Emulation of the Conversation API with the conversation management API provided by CDI (some parts of the API are not implemented due to lacking underlying functionality) Emulation of method-level annotations The rest of the migration process needs to be performed manually. The Flash 3 scope provided by JSF 2.0 may be used in places where an application relies on a temporary conversation. Alternatively, an implementation of the conversation scope, provided by the Apache CODI 4 project, addresses some of the aforementioned problems such as the propagation of a transient conversation and nested conversations. Stateless scope 3. Flash.html

31 4.6. EMULATION OF SEAM CONTEXTS The stateless scope is used mostly for stateless session beans in Seam applications. In CDI, the dependent scope is the only legal scope for this type of component. Semantically, these two scopes are equal in the context of stateless session beans. Besides, CDI makes it possible to implement a truly stateless CDI scope. This functionality is provided by the Classic extension 5 because the stateless scope is used also for implementing unwrapping methods, as explained in Section Because the scope does not carry any state, implementation of a matching context is trivial. public class StatelessContext implements Context { public Class<? extends Annotation> getscope() { return StatelessScoped.class; public <T> T get(contextual<t> contextual, CreationalContext<T> ctx) { return contextual.create(ctx); public <T> T get(contextual<t> contextual) { return null; public boolean isactive() { return true; Example 4.6.1: Simple implementation of the Stateless context. The implementation is registered with the CDI container. The problem of such implementation is that it never destroys the created instance callback is never invoked). Because stateless scoped components are not supposed to carry any state, it is safe to assume that such callback is not necessary (there should not be state requiring cleanup). If this assumption is not sufficient, it is possible to verify that no stateless scoped component in the deployment declares callback and issue an error if this is not met. 5. Note that the provided stateless scope cannot be used for stateless session beans. 24

32 Chapter 5 Components Components are the building blocks of an application. In a container-managed application, components implement the business logic using services provided by the container. 5.1 Seam components types Seam defines multiple types of components. The most basic component type is a JavaBean. JavaBean is a Java class whose instances are managed by the Seam container. From the implementation point of view, few restrictions are imposed: To make a Java class a Seam component, the class must be a non-final non-abstract class with a public non-parametric constructor. Besides, each Seam component has to be marked explicitly in order to be recognized by the container. This can be done either by annotating the component class with annotation or in an XML descriptor. Mandatory part of this step is assigning a name. Every Seam component is required to have a name, which is unique across the application. The name is used to reference the component from other components or from the presentation layer. The scope of a component can either be specified explicitly or is defaulted by public class Person { private String name;... Example 5.1.1: Simple Seam component Even though Seam does not depend on the EJB specification, it provides deep integration with the EJB component model. Again, session and message driven beans need to be explicitly given a name to become Seam-managed components. Enterprise JavaBeans The integration allows EJB components to benefit from Seam services. This advantage is most significant for stateful session beans where the Seam container can take over the 25

33 5.1. SEAM public class CustomerService private EntityManager entitymanager; public void addcustomer(customer customer) { entitymanager.persist(customer); Example 5.1.2: Stateless session beans as a Seam component task of managing the lifecycle of a component provided the component is bound to a scope. As mentioned above, the lifecycle of a stateful session bean would otherwise need to be managed directly by the application code. JPA entities A JPA entity is also a valid type of a Seam component. The pattern commonly used in Seam applications is to have Seam instantiate a JPA entity and store it in a context. The state of this transient (not yet stored in the database) entity object is modified by an application user (for example as a reaction to submitting an HTTP form). Finally, the Seam-managed entity is stored in a database. Figure 5.1: Seam-managed JPA entity Factory methods Very often, additional control is needed when creating a component instance. For example, it is not possible to load a database record simply by instantiating a JPA entity object. The entity itself is not capable of obtaining the required state from a database. Instead, it is necessary to use the JPA API (EntityManager), which loads the database record and creates an entity instance. For cases like these, Seam provides factory methods. A factory 26

34 5.1. SEAM COMPONENTS TYPES method is a Java method placed on another Seam component. These methods are capable of providing a bean instance. Just like the class-defined components, factory methods need to be identified with a unique name. A factory method is marked with public List<Customer> getcustomerlist() { return... ; Example 5.1.3: Seam factory method A special type of a factory method is the so-called Manager component, also known as the unwrapping method. Similarly to factory methods, a method which is annotated with annotation is invoked to create a component instance. However, this method is invoked on every access to the given component. Thus, the defining component (a class component that defines the method) has a complete control over the lifecycle of the created component. A product of an unwrapping method is identified by the name of the defining component. Therefore, each component may declare at most one unwrapping method Roles A role consists of a name and a scope of a component. By default, each component has a single implicit role. Additional roles can be defined using = "loggeduser", scope = ScopeType.SESSION) public class Person { private String name;... This mechanism enables a single Java class to act as a base for multiple Seam components Component creation A Seam component can indicate whether the container should attempt to instantiate the component when an instance of it is requested and no contextual instance is available. This is achieved by placing annotation on a component class. Similarly, factory methods can use the create member of annotation for the very same purpose. 27

35 5.2. CDI COMPONENT TYPES 5.2 CDI component types Similarly to the Seam component model, there are multiple types of CDI components. The basic component type is the managed bean. The managed bean resembles JavaBeans supported by Seam. Depending on the scope of the component, the requirements imposed on a Java class may be stricter. Reasons for this difference are explained in the next chapter. The key difference between Seam and CDI is the component registration process. The CDI specification defines the term Bean Archive. The term refers to a java archive or a folder on the Java classpath which contains a file named beans.xml. In the bean archive, every Java class that fulfills the aforementioned criteria is implicitly recognized as a managed bean. Unlike Seam, a name is not a mandatory part of a CDI component and is only needed when a component is to be referenced from the presentation layer. For inter-component referencing, a mechanism called typesafe resolution (explained later in Section 6.2 ), is used. A CDI component can be given a name using annotation. public class Person { private String name;... Example 5.2.1: A plain Java class located in a bean archive is implicitly a CDI bean with the dependent scope. A name is optional. Session Beans (EJB) Session beans are another type of a CDI components. Every session bean located in a bean archive is implicitly a CDI component and can make use of CDI services. Producers Similarly to Seam, CDI also defines a mechanism enabling a Java method to act as a source of component instances. A special type of explicitly designated Java method, called producer method serves this purpose. Semantics of the producer method is very similar to the Seam public List<Customer> getcustomerlist() { return... ; Example 5.2.2: CDI producer method In addition to producer methods, CDI allows for a Java field located on a CDI component to act as a component instance source. Example documents such a use-case. 28

36 private int minimum = 1; 5.3. AUTOMATED MIGRATION OF SEAM COMPONENTS Example 5.2.3: CDI producer field In CDI, JPA entities are not recommended to be used as CDI components [7] because CDI-managed entities cannot be persisted or merged. The reason for this is that the JPA provider requires direct access to the entity, not only to the client proxy. Thus, entities should always be instantiated using the new Java operator. However, once an entity is managed by JPA, it can be turned into a CDI component using a producer method, as illustrated in Example CDI provides a deep integration also with other types of Java EE components. Such components can make use of CDI services while their lifecycle is not managed by CDI. These components are called non-contextual components and this category includes servlets, message driven beans, web service endpoints and others. 5.3 Automated migration of Seam components The process of automated conversion of a Seam component into a native CDI component consists of three steps: it is necessary to discover Seam components deployed in the application, process metadata of these components and transform them into a form understood by the CDI container, and register the transformed metadata with the CDI container Mutable metadata in Java In the Java language, an annotation is a mechanism for adding metadata to the source code. Such metadata can be applied on classes, methods, variables, parameters, and packages similarly to Java modifiers. An annotation itself does not directly change source code semantics. It affects the behavior of tools and libraries that interact with the Java program. Mere presence of an annotation on a given declaration represents a piece of information. Moreover, annotations are capable of carrying additional data in form of key-value pairs. Java is a reflexive language. At runtime, a program element is able to inspect information about itself or other program elements including information about annotations. Frameworks and containers (such as Seam) make heavy use of this ability. On the one hand, annotations are processed by the Java compiler which guarantees type safety. On the other, because the compilation process is necessary to modify metadata represented by an annotation, annotations cannot be used for deployment-specific configuration. Similarly, the reflection API offers an immutable view to the element structure without the option to manipulate the metadata at runtime. This fact limits the extensibility of libraries that make use of annotations. The CDI specification provides an API that abstracts from the Java reflection mechanism. Besides providing a somewhat higher level of abstraction, the API allows alternative meta- 29

37 5.3. AUTOMATED MIGRATION OF SEAM COMPONENTS data sources to override the metadata available in a class definitions. A class diagram that illustrates the API is available in Appendix C The discovery phase A CDI container always scans a deployed application for Java classes and uses the result of the scanning for its internal purposes. Besides, it makes the result of scanning available to extensions. A CDI extension may define an observer method (callback) which gets invoked for any annotated type discovered in a bean archive of an application. In addition, a portable extension can modify the metadata of a Java class (using the aforementioned mechanism) before the class is further processed by the container. This gives an extension significant control over the deployment. A major limitation of the CDI specification 1 is that once the container begins to notify extensions of discovered annotated types, it is no longer possible to register additional annotated types within the container. Combined with the fact that extensions are notified of annotated types in sequential order, and the fact that the actual order is not guaranteed, this mechanism enough is not satisfactory for needs of the Classic extension. It would only be possible to use this mechanism if the installation of a Seam component was always independent from an installation of other Seam components. As explained in Section 9.1.1, this is not the case with Seam components. An alternative approach is for an extension to perform scanning on its own. Java libraries supporting runtime scanning such as Reflections or Scannotation are available and can be used for this purpose. The Classic extension uses the Reflections library 2 and executes an application scan. The scanning occurs early in the application deployment, even before CDI scans the application. Based on the discovered Java classes, the Classic library builds a meta-model capturing every piece of information necessary for transformation of Seam components. The model is used later in the processing phase. A diagram of this data structure is attached in Appendix A The processing phase There are two ways of registering Seam components as CDI components: a low-level approach where an annotated type is modified directly and a higher-level approach where the Bean SPI is used. The former approach includes adding CDI metadata transformed from Seam-specific configuration such as name, scope, etc. into the annotated type. The main advantage of this approach is that the resulting component is a native CDI component. Therefore, the CDI container handles all the low-level infrastructure operations such as instantiating the component, building an interceptor chain, and others. The classic library uses this approach for class-based components (JavaBeans and Session beans). The Seam name is simply applied to the annotated type. The Seam scope is transformed according to the rules defined in Section 4.6. Other metadata related to dependency 1. This limitation is planned to be removed for CDI cz.muni.fi.xharting.classic.bootstrap.scan.reflectionsscanner 30

38 5.3. AUTOMATED MIGRATION OF SEAM COMPONENTS injection and interceptors is processed and transformed. Roles CDI does not support component roles. Therefore, special treatment is required. For every non-implicit role that a Seam component defines, the Classic library creates a copy of the processed declaring annotated type with the name and scope reflecting the role 3. This naive approach is semantically equivalent to how roles are implemented in Seam. For example, if such an annotated type declares a factory method, the CDI container identifies a conflict, because multiple equal factory methods would be registered. The same conflict would be recognized by Seam. Factories and unwrapping methods Another way of registering Seam components is using the Bean SPI. The Bean SPI provides a high-level abstraction over the source of a CDI component, because metadata required by CDI are directly exposed. The Bean interface defines everything the container needs to manage instances of a certain CDI component [8]. The Classic extension provides an implementation 4 of this interface to represent Seam factory methods as CDI components. For the purpose of Seam integration, the most important methods are getname() and getscope(). These inform the container of an identifier of a factory method and its scope, respectively. In addition, the create() method is invoked by the container when a new component instance is requested. The LegacyFactory implementation forwards this call to a method of the underlying component and propagates the returned value. Seam supports a special type of factory method which is unknown to CDI. Such a factory method, called a void factory, does not return a value. Instead, it relies on the fact that the factory method invocation triggers the outjection mechanism (explained in Section ) which populates the requested contextual variable. This type of factory requires special handling. Instead of the value returned by the underlying method, the Bean implementation returns the value of a matching field. An alternative approach is to return a placeholder value and rely on the outjection emulation layer. It is essential to guarantee that the dependency injection mechanism prefers the outjected value over the placeholder. The Classic extension uses the former approach. There are two ways of implementing Seam unwrapping methods on top of CDI. The first approach is to use an existing implementation available in the Solder library, which is an open-source CDI extension. [10]. This implementation wraps the result of the method invocation with a dynamic proxy, which invokes the unwrapping method every time a proxied method is invoked. As a result, the desired per-invocation resolution is achieved. The Classic extension uses its own implementation: unwrapping methods are imple- 3. Although AnnotatedType represents a Java class, multiple annotated type implementations representing the same class may be registered with the CDI container. 4. cz.muni.fi.xharting.classic.factory.legacyfactory 31

39 5.3. AUTOMATED MIGRATION OF SEAM COMPONENTS public interface Contextual<T> { public T create(creationalcontext<t> creationalcontext); public void destroy(t instance, CreationalContext<T> creationalcontext); public interface Bean<T> extends Contextual<T> { public Set<Type> gettypes(); public Set<Annotation> getqualifiers(); public Class<? extends Annotation> getscope(); public String getname(); public Set<Class<? extends Annotation>> getstereotypes(); public Class<?> getbeanclass(); public boolean isalternative(); public boolean isnullable(); public Set<InjectionPoint> getinjectionpoints(); Example 5.3.1: Contextual and Bean interfaces. mented as a special type of a factory method, which is always bound to the stateless scope. Because the stateless scope is implemented as a normal scope, the CDI container always provides a proxied client view to its components. Therefore, the resulting architecture is identical to the one described in the previous paragraph. However, this second approach is simpler because the low-level implementation of the dynamic proxy is handed over to the CDI container. Besides setting the scope, the name of the hosting component is applied to the unwrapping method. Hence, the hosting component receives an artificial identifier used for internal lookup only. JPA entities As explained in Section 5.1 and Section 5.2, a JPA entity is a supported component type in Seam whereas, due to the use of client proxies, entities are discouraged from being used as CDI components. The Classic extension bridges this gap by using the reference holder pattern ( Section ). As a result, the negative influence client proxies have on JPA operations is eliminated and a behavior equivalent to Seam is achieved. 32

40 Chapter 6 Dependency injection Dependency Injection (DI) is a specific form of the inversion of control principle, where the concern being inverted is the process of obtaining a dependency. In traditional software architectures, software components create and manage their dependencies. With dependency injection, it is possible for software components to specify their dependencies declaratively and let an infrastructure code (the dependency injection container) to supply the dependencies when needed [16]. In the Java environment, the following types of dependency injection are recognized: Dynamic dependency injection Dynamic dependency injection is performed every time a method of a component is invoked. When used in a contextual model, this approach always guarantees that actual contextual instances are injected. The disadvantage is the overhead. Because dependencies are usually declared per component, dependency injection is performed every time, even if a given method does not require the dependencies [3]. Static dependency injection Static dependency injection 1 is performed only once per component lifecycle. This type of injection is used for non-contextual injection (EJB injection, JAX-RS component injection, etc.). This approach can be used for contextual injection provided client proxies are used for the contextual instances, as explained in Section Dependency injection in Seam Seam uses a combination of static and dynamic dependency injection. Static injection is used for initial component values. These values can be defined in an XML descriptor, properties file or via environment variables and enable the application to be configured per deployment. These values, which are known at the deployment time and do not change throughout the application life time, may be injected into Seam components. Dynamic dependency injection is used in Seam for injecting values of contextual instances, mainly other Seam components. A dependency is declared using annota- 1. The term static dependency injection is often confused with injection of static members of a Java class. 33

41 6.1. DEPENDENCY INJECTION IN SEAM tion on a Java field of a component. The name of a dependency is either specified explicitly as the value of the annotation or can be implied from the name of the Java public class Car private Engine engine; Example 6.1.1: Dependency injection in Seam A name uniquely identifies a contextual variable. However, two different contexts can have a contextual variable with the same name. Seam resolves this ambiguity by giving each context a priority and iterating available contexts in the order defined by their priority. This priority is inversely proportional to the scale of a given context; the narrowest context is searched first. If the priority search yields a result, it is injected into the component. Otherwise, there are two options: The container may be asked to create a component instance, store it in a contextual variable, and use it for a dependency injection. This is not the default behavior but can be requested either directly on the injection point 2 (using the create attribute of annotation) or on a target component using annotation. No value is injected, leaving the injection point null Dependency outjection As discussed in Section 4.2, Seam allows its components to modify the content of contextual variables. Dependency outjection is a declarative approach of doing so. Similarly to dependency injection, annotation is used to bind a field of a Seam component to a contextual variable. After every method invocation on a component, the value of a field annotated with annotation is stored in a contextual variable Disinjection Disinjection is the last step of the dependency injection procedure. Disinjection is performed after a method invocation completes and does a clean-up of a component. This prevents injected values from leaking and keeps the component in a consistent state. In Seam literature, the combination of dependency injection, outjection and disinjection is referred to as dependency bijection. 2. a field annotated with annotation 34

42 6.2. DEPENDENCY INJECTION IN public class Authenticator = "user", scope = ScopeType.SESSION) private User user; Example 6.1.2: Dependency outjection in Seam Figure 6.1: Seam Bijection 6.2 Dependency injection in CDI In CDI, the dependency injection is static and based on a mechanism called typesafe resolution. When resolving a component to be injected to an injection point, the container considers the Java type of a component and its qualifiers. A qualifier is a special type of a Java annotation used to distinguish between multiple components sharing the same type. Qualifiers are also used for event resolution ( Chapter 7, Events ). For the purpose of this thesis, details of the typesafe resolution mechanism are not important. Similarly to Seam, the CDI specification allows a dependency to be obtained based on its name. This is possible either using qualifier or programmatically via the BeanManager API. The Classic extension leverages the latter approach as part of its Seam emulation layer. 6.3 Emulation of Seam dependency injection There are several specifics of the Seam dependency injection mechanism that need to be handled in order to emulate it successfully on top of CDI. Unlike CDI, Seam uses dynamic injection. As explained above, this difference itself is 35

43 6.3. EMULATION OF SEAM DEPENDENCY INJECTION not a problem because both models are equivalent with regards to stale reference protection. However, the fact that a null reference may be a result of the dependency injection mechanism is something unknown to CDI 3 Legacy applications may rely on this behavior and check the existence of a contextual variable by inspecting whether an injection point was injected or not. Therefore, the dependency emulation layer cannot simply delegate all the work to the CDI dependency injection mechanism. The entire concept of dependency outjection must be emulated. Moreover, although both Seam and CDI require component names to be unique within an application, Seam allows the same name to be used in multiple contexts. Therefore, the priority search used by Seam has to be implemented on top of CDI. Similarly to Seam itself, the Classic library uses an interceptor (explained in detail in Chapter 8, Interceptors ) to implement dynamic dependency injection. The interceptor uses the CDI SPI to obtain contextual references from CDI and the rewritable context for implementing priority search in application-set contextual values. The interceptor also propagates the values of outjection points to the rewritable context after each method invocation. At first glance, a CDI producer field may look very similar to a Seam outjecting field. However, the semantics of each is very different. Because CDI uses the pull context model, a producer field is always the only source of a given CDI component. On the contrary, the value a Seam contextual variable may be modified by multiple outjecting fields as well as programmatically. Therefore, a producer field itself cannot serve as a general replacement of an outjecting field. The algorithm used by the Classic extension for dependency injection is expressed in the form of an activity diagram in Appendix D Circular dependencies and concurrent access Both Seam and CDI support cycles in the dependency graph 4. Such scenario is, however, treated specially by Seam. At no time during the execution of a component s method is bijection applied to that component a second time [11]. Such special treatment improves performance by reducing the overhead of dependency bijection. More importantly, it guarantees consistency of reentrant method calls. A reentrant method call occurs when a method invocation on a component causes another method (or the same method recursively) to be invoked on the same component while the execution of the former method is not finished yet. Reentrant method calls are used often by an application code when implementing the visitor or double dispatch design pattern. If both the methods are invoked through the client proxy (not using the this Java keyword), the consistency of a component would be threatened if the dependency injection was implemented naively (performing bijection on every invocation). In such a case, disinjection carried out 3. Null is not a valid value of a normal scope component. It is however possible to use null with the dependent scope. 4. The CDI specification supports circular dependency injection unless there is component in the cycle. 36

44 6.3. EMULATION OF SEAM DEPENDENCY INJECTION after the invocation of the inner method would wipe out the injected fields of the component. Because the invocation of the outer method would be still proceeding at that time, it would be operating on an inconsistent state of the component. Likewise, multiple concurrent method invocations on a Seam component would cause the same problem. Therefore, either access to a Seam component should be synchronized or the BijectionInterceptor should be suppressed for such a component. The latter can be achieved by using annotation on a component class. Seam guarantees that dependency bijection is not performed for a reentrant method call. It does so by keeping an information about whether a component instance is injected. The information is kept in an instance of the BijectionInterceptor. Because the interceptor shares the lifecycle with the target component, the information is available on reentrant method calls as well and in such case the interceptor decides to omit bijection. The intention was to use the same technique in the Classic extension. However, during the implementation of the extension, a bug was discovered in the reference implementation of CDI 5. The bug causes the state associated with an interceptor instance not to be available on every method invocation on a given component instance. Therefore, the Classic extension keeps the state, which is necessary to prevent bijection on a reentrant method invocation, in a thread-local data structure [1]

45 Chapter 7 Events Dependency injection allows for building decoupled systems because components do not need to manage the lifecycle of their dependencies. Furthermore, both Seam and CDI support even more decoupled architecture where the involved components exchange messages instead of invoking methods. These messages, called events, may be produced or consumed by a component. The container always acts as a mediator and routes the events to a set of matched components. This enables components to cooperate with no compile-time dependency. 7.1 Contextual events in Seam In Seam, an event object is always represented by a string of characters. Once an event is fired, the Seam container delivers the event by invoking matching observer methods, which are specially marked Java methods of Seam components. Every observer method that observes the given type of event (an equal string of characters) is notified. Except the event object itself, an event may carry additional Java objects as a payload. These object are passed as method parameters to the observer method. An event may be raised either programmatically by calling the Seam API or declaratively, where a component method is marked to produce a given type of event. Every time the method invocation succeeds, the event is public class HelloWorld { public void sayhello() { Events.instance().raiseEvent("hello", "Jozef"); Example 7.1.1: Event raising By default, the observer notification is synchronous. The call to the fireevent method blocks until all the observer methods are invoked. Moreover, Seam supports other notification modes: 38

46 7.2. CDI public class HelloListener public void sayhello(string name) { System.out.println("Hello " + name); Example 7.1.2: Event observing. asynchronous the observer notification is scheduled and executed in a separate thread timed the observer notification is scheduled for a given time or after a given delay and executed asynchronously transaction success the observer notification is scheduled and executed after the current transaction completes successfully transaction completion the observer notification is scheduled and executed after the current transaction completes, disregarding the success of the transaction Seam provides a large set of built-in events. These can be observed by an application or an extension code allowing them to react when a certain point in the lifecycle of an application is reached. For example, an application may observe the org.jboss.seam.security.loginsuccessful event to be notified when a user logs in. 7.2 CDI events Unlike Seam, the process of observer method resolution is typesafe in CDI. A CDI event is represented by a payload (any Java object) and a set of qualifiers 1. The Java types of the event payload together with qualifiers determine which observer methods are notified of the event. The CDI specification itself supports both synchronous delivery of events as well as transactional observer methods which are invoked in specific points in a life-cycle of a transaction. Unlike Seam, where an entire event can be bound to a specific transaction phase, it is the observer method which declares the transaction phase in case of CDI. As a result, observer method invocations for the same event may be executed in different phases of a transaction, which is not possible with Seam. 1. These are the same qualifiers as those used for dependency injection, which are explained in Section

47 public class private Event<String> event; 7.3. EMULATION OF THE SEAM EVENTING MODEL public void sayhello() { event.fire("jozef"); public class HelloListener { Example 7.2.1: Event raising public void listen(@observes(during = String name) { System.out.println("Hello " + name); Example 7.2.2: Event observing 7.3 Emulation of the Seam eventing model The Classic library emulates Seam events using a combination of a single-purpose payload object and qualifier. The qualifier 2 identifies the event type the string value. In addition, the qualifier carries an information about the transaction phase the event should be executed EventQualifier { String name(); TransactionPhase transactionphase(); Example 7.3.1: Qualifier used for event identification The payload object 3 is a simple carrier of objects that may be fired together with the event. The EventQualifier and EventPayload classes allow for the eventing API, which is used for raising events in Seam, to be re-implemented using CDI. The other part of the equation is adapting the observer methods. The CDI SPI allows additional observer methods to be register by CDI extensions. Just as extensions provide implementations of the Bean interface to register additional compo- 2. cz.muni.fi.xharting.classic.event.eventqualifier 3. cz.muni.fi.xharting.classic.event.eventpayload 40

48 7.3. EMULATION OF THE SEAM EVENTING MODEL public class EventPayload implements Serializable { private final Object[] parameters;... Example 7.3.2: Object used as event payload nents, the ObserverMethod interface can be implemented to register additional observer methods. Again, this interface abstracts from implementation details of an observer method. public interface ObserverMethod<T> { public Class<?> getbeanclass(); public Type getobservedtype(); public Set<Annotation> getobservedqualifiers(); public Reception getreception(); public TransactionPhase gettransactionphase(); public void notify(t event); Example 7.3.3: The ObserverMethod interface The getobservedtype() and getobserverqualifiers() methods are implemented to return the EventPayload and EventQualifier respectively. The getbeanclass() method returns the class of the hosting component. The getreception() method is supposed to indicate whether the observer method should be invoked even if a contextual instance of the hosting component is not available. Unfortunately, the API provides no method for the container to find out what the underlying component is, making the getreception() method effectively useless. This oversight in the specification 4, which was discover during the development of the Classic extension, was reported. The gettransactionphase() method indicates, which phase of a transaction the observer method should be invoked in. As mentioned above, there is a fundamental difference in transactional events between Seam and CDI. While in Seam an event is bound to a phase of a transaction, in CDI it is an observer method. The classic library uses an event delivery matrix to work around this problem. Each observer method is registered three times once for each transaction phase (IN_PROGRESS 5, AFTER_COMPLETION, AFTER_SUCCESS). The EventQualifier identifies an event based Synchronous event delivery 41

49 7.3. EMULATION OF THE SEAM EVENTING MODEL on a combination of its name and its transaction phase. In addition, the set of transaction phases to which a CDI observer method can be bound is superior to the one supported by Seam. These facts combined allow for transaction events to be emulated completely. Finally, the notify() method is called by the container when an event is fired. The implementation of the ObserverMethod 6 supplied with the Classic extension looks up the hosting component instance, unwraps the event parameters from the event payload and uses that to invoke the legacy observer method. Figure 7.1: Event notification matrix There is no direct alternative for asynchronous delivery of events in the CDI specification. However, the recent version of the EJB specification provides an asynchronous method invocation. As a result, it is trivial to achieve the behavior of Seam s asynchronous events by using a combination of CDI events and the EJB asynchronous services. The Classic extension uses this approach. Similarly, the timed events have no direct alternative in the CDI eventing model. Nevertheless, the Classic extension implements this functionality by using a combination of CDI events and the timer service provided by the EJB container. 6. cz.muni.fi.xharting.classic.event.legacyobservermethod 42

50 Chapter 8 Interceptors Aspect-oriented programming (AOP) is a programming paradigm which allows cross-cutting concerns 1 to be separated from the rest of the application logic and re-used on different places. Typical examples of such concerns are logging, authentication, and error detection and recovery. Interceptors are said to be a pragmatic approach to AOP. They are considered to be sufficient for most use-cases while at the same time leaving out the complexity of AOP. [5] 8.1 EJB 3.0 Interceptors Historically, Interceptors were introduced as part of the EJB 3.0 specification. The specification defines the syntax and semantics of an interceptor method. Such method can be bound to a method of an EJB component and intercept its invocation. As a result, when the intercepted method is invoked by a client, the interceptor method in invoked instead. Hence, the interceptor method has control over the execution. It can perform additional logic before or after the execution of the target method, modify the parameters or the result of the target method invocation or perhaps omit the invocation entirely (e.g. when a result can be obtained from a cache). Multiple interceptor methods can be associated with a component method, forming an interceptor Object intercept(invocationcontext ctx) throws Exception { long before = System.currentTimeMillis(); Object result = ctx.proceed(); long after = System.currentTimeMillis(); System.out.println("Invocation took " + (after - before) + " miliseconds"); return result; Example 8.1.1: Sample interceptor method. InvocationContext carries information about the current method invocation, such as the target object, the method being invoked, and the method parameters. 1. Concerns which affect various parts of a system and are therefore difficult to decompose cleanly, often resulting in code duplication or tangled dependencies between parts of the system. [14] 43

51 8.1. EJB 3.0 INTERCEPTORS The InvocationContext.proceed() method is used to hand over the invocation to the next interceptor in the chain or to the target method. Figure 8.1: Interceptor chain An interceptor method can be defined directly on an EJB component, binding the interceptor method to every method of the component. More often, an interceptor method is defined in a separate class. Such interceptor can be re-used by multiple components. An interceptor class can be associated directly with a component method or with a component class associating each method of the component with the interceptor class. The association is done either using the Interceptors annotation or in an TransactionInterceptor.class, AuditInterceptor.class ) public class PaymentProcessor implements PaymentProcessorLocal{... Example 8.1.2: Interceptor classes can be bound directly to a component class Multiple interceptor classes may be specified in the Interceptors annotation. The order in which the classes are specified implies the order of the interceptor chain. EJB interceptors are always totally ordered. The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated. When the target instance is created, a corresponding interceptor instance is created for each associated interceptor class. These interceptor instances are destroyed when the target instance is removed [9]. In addition to method interceptors, the EJB specification defines lifecycle event interceptors, which are used to attach additional logic to specific points in a lifecycle of an EJB component before / after component construction before / after component passivation 44

52 8.2. SEAM INTERCEPTORS 8.2 Seam Interceptors Seam interceptors are an enhancement of the EJB interceptors. In addition to EJB components, a Seam interceptor can be bound to a method of any Seam-managed component (not only EJB). Both EJB and Seam interceptor methods share the semantics of an interceptor method. As of syntax, Seam defines an exact copy of the interceptor API (such and InvocationContext ). This API clone, located in the following Java packages: org.jboss.seam.intercept org.jboss.seam.annotation is equivalent to the original interceptor API and is only present in Seam to allow Seam interceptors to run independently of the EJB container. Both APIs can be used to define a Seam interceptor. An alternative way of binding an interceptor class to a component is supported by Seam. annotation, used by EJB interceptors, makes a component dependent directly on an implementation of a given logic (e.g. an intercepted component depends directly on a class named SecurityInterceptor ). In contrast, Seam enables for an annotation to be created to represent a piece of functionality brought by an interceptor. As a result, an interceptor can be bound to a component indirectly, without exposing the mechanism by which the functionality is delivered. In addition, such annotation may carry additional metadata used to configure the backing = "admin") public void removeuser(long id) {... Example 8.2.1: Seam binding annotation Furthermore, multiple lifecycle schemas are available for a Seam interceptor. Besides the default behavior, an interceptor may be stateless. In such case, the container optimizes its memory footprint by creating a single interceptor instance which serves every interception. Seam also does not require total ordering of an interceptor chain. Partial ordering, where an interceptor declares its position in relation to other interceptors (either before or after), is sufficient. Interceptors are used heavily inside of Seam s codebase to implement some of the core functionality. Services, such as dependency injection, asynchronous processing, declarative transactions, security and event processing, are all internally implemented using Seam interceptors. 45

53 8.3. INTERCEPTORS IN JAVA EE Interceptors in Java EE 6 In EJB 3.1, the interceptors functionality is extracted from the specification and becomes a standalone part of the Java EE platform. As a result, other component types such as managed beans may benefit from method interception. The CDI specification introduces the concept of interceptor bindings. The concept is inspired by the binding annotations used in Seam. Similarly, an interceptor binding annotation which represents a given piece of logic may be defined while the underlying implementation remains hidden from an interceptor user. Unlike Seam binding annotations, a CDI interceptor bindings do not specify its implementation (the interceptor class). The association works the other way around, where an interceptor class declares, which interceptor bindings it supports. Figure 8.2: Different ways of interceptor binding This allows for an API (the interceptor binding) to be completely independent (e.g. packaged in a separate Java archive) from its implementation (the interceptor class). This is not possible with Seam binding annotations. An interceptor that uses interceptor bindings must be enabled explicitly in the bean deployment descriptor, named beans.xml. The order in which the interceptor classes are listed in the descriptor implies the order of the interceptor chain. These interceptors are always executed after other types of interceptors (e.g. those bound Consequently, the interceptor chain is always totally ordered. 8.4 Automated migration of Seam interceptors The way an interceptor method is defined is common to all of the aforementioned types of interceptors. Thus, no changes are required to an implementation of an interceptor provided it only uses the following APIs: Java SE APIs Java EE APIs APIs of a library, which is available in the target environment Seam APIs, provided all the used APIs are emulated by a compatibility layer 46

54 8.4.1 Interceptor registration and lifecycle 8.4. AUTOMATED MIGRATION OF SEAM INTERCEPTORS Similarly to the Bean interface, CDI provides an SPI that abstracts from the way an interceptor is implemented and enables alternative interceptor types to be registered with the CDI container. The Interceptor interface serves the purpose. public interface Interceptor<T> extends Bean<T> { public Set<Annotation> getinterceptorbindings(); public boolean intercepts(interceptiontype type); public Object intercept(interceptiontype type, T instance, InvocationContext ctx); Example 8.4.1: The Interceptor SPI The Classic extension provides an implementation of the Interceptor interface. Early in the bootstrap of a legacy application, the deployment is scanned for Seam interceptors. For each occurrence, an instance of the Interceptor implementation is registered with the CDI runtime. The CDI container uses the intercepts() method to find out what type of interceptor it deals with (e.g. method interceptor or lifecycle interceptor). The Classic extension infers this information from reading the Seam-specific annotation from the original interceptor class. The Interceptor interface is a subinterface of the Bean interface. The CDI container uses methods of the Bean interface for controlling the construction and destruction of an interceptor instance. The classic extension makes use of it as it is essential for implementing Seam stateless interceptors properly. The intercept() method is called by the container to perform the actual interception. The Classic extension simply forwards the call the a method of the underlying interceptor instance. It is necessary to wrap the InvocationContext object in a wrapper that properly implements not only the InvocationContext interface but also the Seam s clone of it. Furthermore, because the intercept() method cannot throw checked exceptions while the underlying interceptor method may do so, it is necessary to wrap every checked exception within a wrapper runtime exception. This oversight in CDI has been previously identified 2 and is likely to be fixed in the next version of the specification. Similarly, the implementation part of this thesis revealed several defects 3 in the reference implementation of CDI. As a result, the automated migration of interceptors is only partially functional at the time of writing of this thesis and WELD

55 8.4.2 Binding annotations 8.4. AUTOMATED MIGRATION OF SEAM INTERCEPTORS Seam binding annotations are fairly similar to CDI interceptor bindings. For an automated migration tool, the biggest challenge is dealing with the difference in the way an annotation is associated with an interceptor ClassicInterceptorBinding { Class<?> value(); Example 8.4.2: Interceptor binding used by the Classic extension for emulating Seam binding annotations. For this purpose, the Classic extension uses a single-purpose interceptor binding which is associated with every legacy interceptor. The binding itself carries information about the interceptor it represents in an annotation member. When a CDI container resolves an interceptor for a given interceptor binding, it takes its member values into account. Therefore, uniquely identifies an interceptor. What remains is to scan Seam binding annotations on component classes and methods. For each such interceptor, the Classic extension determines which interceptor class the annotation is associated with. Based on this information, an instance of the Classic interceptor binding annotation is prepared and applied to the annotation. This instance associates the interceptor binding with the migrated interceptor. Subsequently, the annotation is registered as a CDI interceptor binding in the BeforeBeanDiscovery bootstrap phase. This approach is sufficient for scenarios in which a Seam binding annotation is associated with a single interceptor. Although rarely used, it is technically possible to associate a Seam binding annotation with multiple interceptor classes. The aforementioned approach would not work in such a case, because in Java, it is not possible to apply multiple instances of the same annotation type to the same target declaration [6]. Therefore, the Classic extension does not support Seam multi-interceptor binding annotations and requires manual migration to be performed. However, it is technically possible to automate this process. To do so, it is necessary to establish a mechanism for dynamically adding synthetic annotation types at runtime (e.g. using bytecode manipulation) Interceptor ordering CDI 1.0 is surprisingly weak when it comes to manipulation of interceptor ordering and enablement. There is no portable way for an extension to manipulate the list of enabled interceptor classes. This limitation has been recognized 4 and is likely to be removed in the next version of the CDI specification. In the meantime, it is necessary to modify the bean

56 8.4. AUTOMATED MIGRATION OF SEAM INTERCEPTORS descriptor manually for the Classic extension to work properly. A template 5 is available in the source codes of the Classic extension. 5. impl/src/main/resources/beans.xml 49

57 Chapter 9 Other core services This chapter summarizes the rest of core services provided by Seam and provides a strategy for their migration. 9.1 Conditional component installation Even if a program component is physically present in an application, it may not necessarily be available to the rest of the application. A component is said to be installed when it is physically present in an application and is available for lookup and injection into other components in the same application. Conditional installation is a term referring to a capability of modifying the set of installed components at the deployment time based on the target environment. Such a capability is useful for several reasons: Components can be replaced by mock implementation for testing purposes. Multiple implementations of a component may exist (e.g. for localization purposes). The desired implementation is selected at the deployment time. A component may be extended by another component without tight coupling to the rest of the system Conditional installation of Seam components Seam offers annotation for controlling whether a given component should be installed or not. The following concepts are encapsulate by the installation mechanism provided by Seam: explicit prevention from installation installation dependencies installation precedence 50

58 9.1. CONDITIONAL COMPONENT INSTALLATION A component can be explicitly prevented from being installed as illustrated in Example Moreover, annotation can be used to declare class-level or component-level dependencies, causing the declaring component to be installed only when all of these dependencies are satisfied. A Class-level dependency is considered satisfied when the class is available on the classpath. Similarly, a component-level dependency is satisfied when the dependency (identified by a component name) is installed within the public class MockComponent {... Example 9.1.1: The component is explicitly prevented from being installed Furthermore, the concept of component selection from within multiple candidates is implemented using an explicit precedence. The precedence is expressed in a form of an integer. If multiple beans with the same name exist, the bean with the higher precedence is selected. The value of the install annotation as well as the precedence of a component can be overridden in the Seam deployment descriptor ( components.xml ) Component installation in CDI The CDI specification itself does not define a single replacement for all the functionality represented by annotation. Instead, these concepts are handled separately. Firstly, a component can be prevented from being installed entirely. As explained in Section 5.3.1, a CDI extension may be notified of every Java class discovered by the container in an application. For each Java class, the extension may decide to suppress component installation by using the ProcessAnnotatedType.veto() method. Solder provides a shortcut where each class annotated with annotation is explicitly prevented from further processing. In the context of component classes, annotation is semantically equivalent Secondly, Solder provides annotation for expressing class-level dependencies. No direct equivalent for component installation based on component-level dependencies exists in the Java EE specification nor in the Solder extension. However, it is possible to implement such extension using the CDI SPI Classic extension The Classic extension does not make use of the facilities provided by the CDI specification, such as vetoing, alternatives or specialization. This decision was made for several reasons: The ProcessAnnotatedType event, which allows a CDI component to be vetoed occurs early in the deployment of an application. Because components are processed 51

59 9.2. EAGER COMPONENT INSTANTIATION sequentially, the state of component s dependencies may be unknown at that time. Therefore, it is not possible to emulate Seam conditional installation this way. Alternatives, used by CDI applications for component overriding could be used as an equivalent to installation precedence used by Seam. However, a CDI alternative has to be manually enabled in the bean descriptor. A portable extension is not able to alter the set of enabled alternatives. As a result, this part of the migration process could not be automated. Instead of reusing CDI facilities, the Classic extension contains its own conditional installation processing logic. The logic was taken from Seam codebase and modified to use deployment scanning used by the Classic extension, as explained in Section Eager component instantiation By default, in both Seam and CDI, a component instance is not instantiated by the container unless it is requested by another component. However, there are situation when it is desired for a bean to be instantiated as soon as its context @Startup public class PaymentProcessor { Example 9.2.1: Eager component instantiation in Seam There are several alternatives in pure Java EE environment. Firstly, a singleton session bean may be designated as startup, causing it to be instantiated just after application initialization. Because such bean can make use of implicit transactional processing support, singletons are often used for putting the persistent storage into an initial state. Another option is to use the lifecycle listeners provided by the Servlet specification. A callback method can be defined by implementing the ServletContextListener or HttpSessionListener interface. Each of the interfaces defines two methods, one of them called at startup and the other at tear down of an application or a session, respectively Classic extension None of the aforementioned alternatives is completely equivalent to the functionality provided by Seam. Therefore, in order to provide complete backwards compatibility, the Classic extension provides its own solution based on Servlet listener callbacks. At bootstrap, the extension collects information about startup components including startup dependencies and 52

60 9.2. EAGER COMPONENT INSTANTIATION organizes this information in a data structure. In addition, it checks for cycles in the dependency graph and aborts the deployment if any cycle is found 1. When the Servlet container notifies the Classic extension of a context (either session or an application) startup, the extension instantiates affected components. This part is often misunderstood by application developers 2. It is tempting to think that performing a lookup for a component and acquiring its reference implies that a component instance has been instantiated by the container. As explained in the Section 4.4, CDI requires normal-scoped contextual instances to be placed behind a proxy. As a result, an actual instance may not exist yet even if a client already received a reference because it is a reference to the client proxy and not to the actual component instance. Every CDI implementation implements the lazy initialization of components, which means that component instantiation is postponed until it is really needed until a method is invoked on the component. CDI does not provide a direct way of forcing component instantiation. The Classic extension works around the problem by invoking the tostring() method of the component instance. This enforces component instantiation. This method, which is present on every Java object, is assumed to have no side effects and not to be computationallyintensive. 1. This check is not done in Seam and therefore a cycle in the dependency graph leads to a stack overflow error a blog of a developer blogging about his incorrect solution of the problem 53

61 Chapter 10 Conclusions The primary goal of this thesis was to research possibilities of automated migration of existing Seam codebase to more modern Java EE 6 environment, with focus on core services of the Seam programming model. We have explained core Seam services, compared them with the Java EE 6 services and a migration path has been suggested. The thesis has delved deeper into areas where the migration process turned out to be problematic. These migration problems have been analyzed and solutions (such as rewritable contexts, the reference holder pattern, or the event delivery matrix) have been designed and verified in the implementation part of the thesis. The implementation part of the thesis has delivered a migration tool named the Classic extension. This tool has been built mainly around the extensibility mechanism of the CDI specification. It demonstrates that the specification makes such automated migration possible at deployment time by manipulating deployment metadata. In the cases, in which this solution was not sufficient, the extension has provided runtime emulation of the legacy environment. An extensive testsuite has been developed in order to verify the functionality of the extension. The functionality was also verified on a sample Seam application which was migrated to the Java EE 6 environment. The implementation effort revealed several weaknesses and ambiguities in the CDI specification. These findings were reported and thus contributed to the development of the next version of the Java EE platform. In addition, several bugs identified in the reference implementation of the specification were reported. In future, this thesis may be extended. One of the possible directions is to enhance the Classic extension to go beyond the core programming model and turn it into a complete migration solution. This thesis focused on migration of an existing application to a newer environment and does not deal with coexistence of both legacy and current components. This thesis leaves room for future research in this field. 54

62 Appendix A Metadata class diagram The data structure used by the Classic extension to capture metadata about a Seam application. 55

63 Appendix B Bootstrap activity diagram Activities performed by the classic extension during application bootstrap. 56

64 B. BOOTSTRAP ACTIVITY DIAGRAM 57

65 Appendix C CDI alternative metadata source API The abstraction layer that allows class metadata to be manipulated. 58

66 Appendix D Dependency injection algorithm The algorithm used by the classic extension for injection of a dependency via priority search. 59