Interceptors in OpenESB v2.1 will be slightly different from interceptors in Fuji, primarily because Fuji benefits from the modularity and features provided by OSGi.
To provide support for interceptors in OpenESB, there are two main gaps to be filled :
The com.sun.jbi.EnvironmentContext could have the following two methods :
/**
* Add an interceptor to the interceptor cache
*
* @param interceptor - the interceptor instance
* @param properties - the interceptor priorities
*/
InterceptorRegistration registerInterceptor(Object interceptor,java.util.Dictionary properties);
/**
* @return an array of InterceptorReference's one for each interceptor in the cache
*/
InterceptorReference[] getInterceptors();
The EnviromentContext will delegate to a low level InterceptorCache implementation.
The InterceptorRegistration and InterceptorReference are defined along the lines of the OSGi ServiceRegistration and ServiceReference interfaces :
/**
* Handle to a single interceptor instance in the cache.
*/
public interface InterceptorReference
{
/** @return the interceptor instance */
Object getInterceptor();
/** @return the value of the named interceptor property */
Object getProperty(String name);
/** @return a String array of all the property keys defined for the interceptor */
String[] getPropertyKeys();
}
/**
* Interceptor Registration
*/
public interface InterceptorRegistration
{
/** @return the reference to the registered interceptor */
InterceptorReference getReference();
/**
* Update the interceptor properties.
*
* @param properties - properties to be updated
*/
void setProperties(java.util.Dictionary properties);
/**
* Unregister the interceptor from the cache
*/
void unregister();
}
When a service assembly is started, the JBI runtime needs to introspect each and every class in the Service Assembly to determine if it has any interceptor methods. If it does, then an instance of the class needs to be registered in the Interceptor Cache along with the interception properties obtained from the @Intercept elements. To be able to introspect the class the runtime would need to load the class first, since the Classloader for the JBI runtime does not have the service assembly in it's class path, a new Service Assembly Classloader is required.
From my preliminary study of how classes are loaded in Open ESB, it appears that I need to do the following :
In the framework code, add new methods to create/get/remove a ServiceAssembly Classloader as follows :
ClassLoader createServiceAssemblyClassLoader(List erviceAssemblyJars, String serviceAssemblyName);
ClassLoader getServiceAssemblyClassLoader(String serviceAssemblyName);
void removeServiceAssemblyClassLoader(String serviceAssemblyName);
A new interface ServiceAssemblyClassLoaderFactory will be defined which has the three methods mentioned above for managing the Service Assembly Classloader. An instance of the ServiceAssemblyClassLoaderFactory can be obtained from the runtime Environment context i.e. com.sun.jbi.EnvironmentContext.getServiceAssemblyClassLoaderFactory(). The Deployment Service will use this class loader factory to create the Service Assembly Class Loader on demand.
The attached image shows the class loader hierarchy in the Open ESB runtime.
Interceptors in Open ESB v2.1 do not need to implement the Interceptor interface since :
There is no requirement for the Interceptor wrapper either.