An Oracle tutorial defines an interceptor as follows:

As previously mentioned, interceptors are generally used for technical tasks, referred to as cross-cutting tasks. This includes auditing, logging, controlling statistics, and so on. These tasks are separate from the business logic, and may be repeated over the entire application. Consequently, we can put the interceptor code into a separate class that is different from the target class that we want to intercept in order to improve code maintenance.

The concept of the interceptor was first introduced in JEE5, and it was only used for EJBs (session beans and message-driven beans). With the introduction of context and dependency injection (CDI) in JEE6, the interceptors were extended to all managed beans—that is, to beans that meet the CDI-managed bean. 

Interceptor methods are invoked on an associated target class.

We can define an interceptor within the target class as an interceptor method, or we can define an interceptor in a separate class (called an interceptor class) that contains the interceptor method. Interceptor methods are always invoked when a target class method is annotated to be intercepted and is then invoked, or when a life cycle callback method is intercepted (such as before the construction or after the destruction of a bean). It is important to note that for simple applications, we can put interceptors in the target class. However, for a more complex application, or for when the application grows in complexity, we should put the interceptor in a separate class.

Each element that you want to intercept is called an advice. We say that an interceptor decorates the advice, and each time an advice is called, an interceptor code is executed (if it exists). The location of the point where this code is executed is called the pointcut. 

The following figure shows an interceptor sequence diagram:

This sequence diagram shows a chain of interceptors. When a client calls a business method and there is a chain of interceptors associated with it, the first interceptor is called and does something (that is, this first interceptor method's code is executed), then calls the second interceptor explicitly, and so on. This continues until the last interceptor in the chain calls the bean's business method. We will see how this call is made later. For now, we can say that an element of the chain of interceptors calls the next element in the same way until the last element—which is the business method of the managed bean itself—is invoked.

We can define interceptor classes and interceptor methods using annotations, or, alternatively, we can define the deployment descriptor of the application. However, in this section, we will only cover the use of annotations. The following table shows the annotations used in interceptor methods that define the condition or when the interception occurs: