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.