[jboss-jira] [JBoss JIRA] Moved: (JBJCA-18) JCA Interceptors

[Jesper Pedersen (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBJCA-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen moved JBAS-1435 to JBJCA-18:
--------------------------------------------

          Project: JBoss JCA  (was: JBoss Application Server)
              Key: JBJCA-18  (was: JBAS-1435)
      Component/s: Core
                       (was: JCA service)
    Fix Version/s:     (was: JBossAS-5.1.0.Beta1)
         Security:     (was: Public)


> JCA Interceptors
> ----------------
>
>                 Key: JBJCA-18
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-18
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Adrian Brock
>            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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira