If you don't need integration with transactions, security or want to be able to use the thread pooling from jca 1.5 (for jboss-4.0.x) then jca may be overkill. Otherwise, this is the correct approach. Search for jca 1.5 example adaptor and you'll find code samples:
Thanks for the quick response.
I'm not sure if I'll need the threading support or the transactions, but it is conceivable that I might need the security in the not-too-distant future.
I've gone through the document on developers.sun.com, and it feels kinda like a square peg and a round hole. The objects I wish to keep in the pool are not database connections so things like getRecordFactory() (which is required by the ConnectionFactory interface) will have "Unsupported Operation" exceptions thrown in their body. Am I misunderstanding the purpose of JCA?
The things I'd like to get are:
* Pooled objects;
* Easy creation of other pools of objects, with slightly different configurations (still containing objects of same interface, though) via XML config files
Look at this:
May be this might be of help.
Like scott said, it would be an overkill to use JCA unless you require all the three features provided by JCA:
1. Connection management
2. Transaction management
Kaylan, thanks for the pointer to commons-pool. I'm aware of this, and it does support the pooled objects, but it lacks a simple way of adding new pools with configuration files. I had also hoped to build it in such a way that it could be deployed on any J2EE server and just work.
Anyone else have any thoughts? Is there no standard J2EE way to do what I'm proposing, or is the standard way JCA? It certainly feels like JCA gets me a lot of the way where I'd like to go, but it just "feels" wrong...squeezing a non DB connection object into a framework that seems to have been built around the concept of database connections.
JCA is not only directed to DB-stuff. See chap 7 in the examples in the pay for doc for 3.2 for instance. (an example of an filesystem access adapter.)
Vanilla EJB is restricted in many way, for instance you are not allowed to access disk, create threads etc. A way to get around these restrictions and still go with the spec, is to write a JCA. Your JCA does not have to support features that you do not need (DB-like behaviour, transactions, CCI and so on) Though the possibillity to support EJB transactions, CCI makes them even more useful. I have written a few adapters which only uses the connectionpool properties, since that was what I needed at the time.
If you need more info: I have looked at an article written by Willy Farrel called "Introduction to the J2EE Connector Architecture" It is geared to Websphere, but combined with the example, it will propably clear things out. As I remeber, also the Sun J2EE tutorial is OK. There is also a book "J2EE Connector Architecture and Enterprise Application Integration" by Rahul Sharma, Beth Stearns, Tony Ng which points out the details.