geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject jsr-77 insanity
Date Sat, 19 Feb 2005 00:52:31 GMT
The resource adapter parts of our jsr-77 support don't agree with the 
spec right now, and the spec has little relationship with the actual 
objects and packaging of adapters.  I'm wondering what to do to fix 
this.

jsr-77 spec calls for:

ResourceAdapterModule

having 1..n

ResourceAdapter(required keys  ResourceAdapterModule, J2EEApplication, 
J2EEServer )

having exactly 1

JCAResource (required keys  J2EEServer, ResourceAdapter )

having 1..n

JCAConnectionFactory (required keys  JCAResource, J2EEServer)

having exactly 1

ManagedConnectionFactory (required keys  J2EEServer )


The actual objects and packaging of a resource adapter + geronimo plan 
is like this:

ResourceAdapterModule (rar file + plan)

contains 0 or 1 ResourceAdapterClass

which if present can have 1.. n instances

each of which can have 0..n managedconnectionfactory/connectionfactory 
pairs.


If there is no resource adapter class, there can still be several 
connection factory classes each with 0..n instances.

Currently we use the resource adapter instance gbean as the 
ResourceAdapter jsr-77 object.  Currently we don't implement 
JCAResource at all.  Furthermore the object names of the connection 
factory and managed connection factory refer only to the resource 
adapter module, not the ResourceAdapter (which may not exist, if the 
adapter has no ResourceAdapter class).

I see a couple of possible ways to proceed, neither of which is 
attractive:

1) for each ResourceAdapterModule (deployed rar + plan), have exactly 
one ResourceAdapterModule, ResourceAdapter, and JCAResource.  None of 
these correspond to functional objects.  The current 
ResourceAdapterWrapper gbean will stop being the ResourceAdapter jsr-77 
object and just be a functional gbean.  This is the simplest solution.  
It has 3 jsr-77 objects where one would do (ResourceAdapterModule, 
ResourceAdapter, JCAResource) and doesn't include the actual resource 
adapter instance in the jsr-77 official objects.

2) for resource adapters with  a ResourceAdapter class, have one 
ResourceAdapter and one JCAResource jsr-77 object per resource adapter 
instance.  For resource adapters without a ResourceAdapter class, have 
one ResourceAdapter and one JCAResource jsr-77 object per 
connectionfactory/managedconnectionfactory.  This matches the structure 
of adapters slightly better, but still has one or two extra objects per 
resource adapter instance( ResourceAdapter AND JCAResource) where one 
would do just fine.  However, this would require all the mcfs and cfs 
to get an extra key in their object names -- they'd need both 
ResourceAdapterModule and JCAResource in order to avoid possible name 
collisions.  This would require a lot of work on our name construction 
and jndi resolution.

Due to the extra work of (2) I'm going to implement (1) for now.  If 
anyone has any better ideas please speak up.

thanks
david jencks


Mime
View raw message