geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject Re: Who are working on the JCA integration part
Date Mon, 18 Aug 2003 17:08:31 GMT
This one time, at band camp, David Jencks said:

First, I invite anyone interested to visit the Volunteer-Topics page on
the wiki and put your name under the J2EE Connector Architecture topic:

Second, I think that David should probably lead this effort as he has
extensive experience from the JBoss project.

I need to learn more about the interceptor stack in Geronimo. Please
see my comments below:

DJ>Based on my experience implementing and maintaining the JBoss JCA 
DJ>support, I have  a couple of strong recommendations.
DJ>1. Adapter supplied components (ManagedConnectionFactory, 
DJ>ResourceAdapter, ActivationSpec and Administered Object at least) 
DJ>should be deployed as ModelMBeans.  In JBoss I did this by generating 
DJ>xmbean descriptors from ra.xml using xsl.  This seems to be too 
DJ>complicated to maintain, so I hope there is a simpler approach.

I agree that all adapter components should be ModelMBeans because they can
be easily configured on the fly. What about using the XDoclet jmxdoclet
to generate the MBean interfaces and we just extend XDoclet to provide
support for the generation of the ra.xml?

DJ>2. ConnectionManager should be implemented as an interceptor stack.  
DJ>The interceptor needs "getConnection" and "returnConnection" methods.  
DJ>Here is a very rough sketch of a possible stack of interceptors:
DJ>Top (implements ConnectionManager, deals with finding the correct stack 
DJ>upon deserialization)
DJ>Method call connection handle caching.  Part of support for hooking up 
DJ>a connection handle to an appropriate ManagedConnection upon a new call 
DJ>with a different security context.  Also will probably support 
DJ>enrolling existing connection (handles) in a new Transaction started 
DJ>through UserTransaction.
DJ>Transaction level ManagedConnection caching.  This is definitely 
DJ>required for LocalTransaction support and seems to be required for all 
DJ>XA drivers as well despite the XA spec.  getConnection looks for a 
DJ>connection associated with the current transaction (and security 
DJ>context and ConnectionRequestInfo), returnConnection calls the next 
DJ>interceptor only if there is no transaction.
DJ>Pooling.  getConnection looks in the pool for an appropriate 
DJ>connection, returnConnection tries to put the connection back in the 
DJ>pool.  Only if these fail is the next interceptor called.
DJ>Default.  getConnection creates a new connection, returnConnection 
DJ>destroys it.

I need to dig into the Geronimo interceptor stack more to see exactly
what's happening and how we'll work with it.

DJ>I have the copyright on the (initial) WorkManager implementation from 
DJ>JBoss 4/Elba and am happy to donate the code to Geronimo, although I 
DJ>still don't understand clearly if this is allowed.  In any case it is 
DJ>fairly simple code.
DJ>I still don't have any very satisfactory ideas on deploying an inbound 
DJ>adapter: this will depend to some extent on how ejbs/mdbs are deployed.

I'm not sure how this has been implemented. We need to take a peek at
the deployment code.

DJ>Although I was hoping to be implementing these ideas by now, I don't 
DJ>have any time right now and it is not clear when I will be able to work 
DJ>on this.

perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

The Castor Project

Apache Geronimo

View raw message