On Feb 3, 2007, at 1:54 AM, Dominique Labar wrote:

Q? related to the JCA 1.5 - Gbean
Do the JCA 1.5 specifications allow to supersede the default (or by geronimo-ra.xml defined) connection pool by a private one? in another words, how to make a private PoolingSupport class accessible by the (Geronimo) connector module? For example, to implement requirements of a calendar based resources allocation, or regulated by private policies?

Something like this was available in geronimo 1.0 but was disabled in 1.1 and following versions. It would be fairly easy to re-enable it in 2.0, but it would be completely untested (except by you :-)

The way this would work is that you would write a gbean to replace GenericConnectionManager, include an instance of it in your geronimo- ra plan, and refer to it in the connectiondefinition-instance element instead of including the geronimo specific connection manager configuration.

Since a connection manager does a lot of work that is rather tricky and the pool is only a small part of that I would very strongly recommend that your connection manager gbean subclass AbstractConnectionManager and basically change the GenericConnectionManager.InterceptorsImpl class to set up an interceptor stack that includes your pool instead of the geronimo pool. Currently this is done in this (line 89 of the 1.2 branch):

            stack = pooling.addPoolingInterceptors(stack);

Another approach might be to modify the xml and GenericConnectionManager to allow specifying the AbstractSinglePoolConnectionInterceptor subclass that you want to use. This might end up being a lot easier to configure substitute pools for but would require a bit more change in geronimo code and I probably wouldn't have time to implement it before 2.0. I might be able to apply a patch.

Anyway to answer your specific question, according to the jca specs the connection manager (which the pooling is part of) is part of the application server and the spec does not say anything about configuring, modifying, or replacing it: any such facilities are completely app-server-specific and non-portable. The spec only talks about the interactions of the connection manager and the ra-provided classes.

thanks
david jencks


Thanks
Dom.


Reply via email to