Repository navigation
Pojo Interception API
This page introduces the POJO interception API that may be available in iPOJO 2.0 release.
It aims to facilitate the interception of :
- field accesses
- method calls
- object constructions
It allows to simply intercept a method call or a field access in a single method, without scattering the code in several callbacks (before, after, exception, ...). The design of this API comes directly from the interceptor pattern. It allows to perform some actions before (e.g. change parameters, change value) and after (e.g. check value, change result) the intercepted element (method invocation, field access) is touched. In certain circumstances, the access to the element can even be completely bypassed.
For now, the proposed POJO interception API is developed in a fork of the Apache Felix project. The feature branch feature/interception-api is regularly updated with corrections/improvements.
This section explains the general philosophy behind the POJO interception API : the interceptor pattern approach and its generic implementation.
The goal is to intercept accesses to Something. The thing that will intercept is called an Interceptor. In the classic case, Someone want to access this Something.
Now we want to intercept all accesses to Something. This interception must be completely transparent for Someone, who may ignore the interception. From Someone's point of view, everything must happen as if the access to Something is direct. So the Interceptor must behave exactly as if it was really Something.
The relation between the Interceptor and Something is not very clear, because the Interceptor is free to completely change the access (e.g. parameters), to access other elements, or to bypass the access to Something.
Now the interceptor pattern principles has been defined, we can refine it to fit the POJO model. POJO stands for Plain Old Java Object, and is composed by:
- instance fields
- instance methods
- constructors
Real Java objects may contain more than that: inner classes, enums, class (static) methods... but we focus here on the simplest POJO model, the one that's used to create iPOJO components.
All the POJO accesses are synchronous; it means that when Someone accesses the POJO, it waits for a response (even a void one). So the interceptor pattern needs a slight modification :
