An interesting idea. A lot of the work in resource adapters follows a number ofpatterns and is just boilerplate code.

Are you thinking of something like:

/**
* @jca:manageable
*/
public class POJOResource
{
...
}

Yes, it is already on our list to add aspects/interceptors to the JCA implementation in JBoss4 so you can plugin your own behaviour. This is scheduled for after the JBoss4 beta release when we have finished the required j2ee1.4 spec work.

JCA is a pain. It's complex, it's subtle, and it's easy to mess up. A better solution would be to define an advisor for any resouce, and generate the necessary JCA interfaces/managedconnections/factories behind the scenes at classload time.

This would work for

* JDBC* JMS* Mail* HTTP* Any other resource you want pooled and secure.

So far the necessary issues that would have to be addressed in an .xml file would be:

* Internally synchronized or externally synchronized

Not only could you wrap the resource, you could wrap any Foo (the client retrieval via the resource's getFoo() ). The entire resource graph could be wrapped, similar to how Connection and Statement are wrapped in the current JBossCX implementation.

This would allow anyone to turn client code into server code instantly.

Intercept the constructor. Instead of just returning an instance, look up from the pool (say an ArrayList) the first unused instance. Set a flag to say it's in use and return the instance.

Intercept the finalize(). In the AOP-all example there's an extra set of "Entering../Leaving.." output, so maybe it's using the finalize or something. That's really the closest thing we have to a deconstructor in Java, which should be fine, since that's where you're supposed to close any resources anyways.

Figure out what to call when a method is called. Should we directly call the method on the object? The idea that JCA uses is that of handles, so you're never directly pointing to the actual resource object.