JCA Interceptors ---------------- Key: JBJCA-18 URL: https://issues.jboss.org/browse/JBJCA-18 Project: IronJacamar Issue Type: Task Components: Core Reporter: Adrian Brock Assignee: Jesper Pedersen Priority: Minor Forums discussion thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48683 This is really a major rewrite of the JCA implementation to be less monolithic so this will need some careful design and consideration and breaking up into more fine grained tasks. The idea is to provide containers/interceptors for the components within the JCA module such that these components can be more easily customised and developed according to the needs of each user. There are three main interceptor stacks that I can think of: 1) ConnectionManager (connection allocation) This provides an interceptor stack behind the ConnectionFactory/DataSource proxy to process the allocateConnection invocation. It will look something like: ConnectionFactory proxy -> ConnectionManager interceptor -> Pooling interceptor 2) ManagedConnection/ConnectionEventListener (connection management) This stack provides most of the features that are currently performed by the BaseManagerConnection2$ConnectionListener and their supporting methods, but as an interceptor stack. As now they will largely be driven by the events from the resource adapter, and it this object that is actually pooled. 3) Resource Adaptors The JDBC and JMS adaptors should be implemented as interceptor stacks to allow optional interceptors like statistics collection, custom behaviour and also to perform vendor specific processing/workarounds. Where AOP can be used, we could actually instrument the vendor classes so we can also expose vendor specific methods, not just the JDBC interfaces. This would remove the requirement to do things like getUnderlyingConection() by user code.