Thanks for your input.
I act the fact that this requirement is not addressed by the JCA 1.5 Spec.
Definitely the portability is my main concern, so I will explore if others
(J2EE engines) offer a solution and will keep you informed about my
discoveries. (my focus was the outgoing flavor).
Dom.
2007/2/3, David Jencks <[EMAIL PROTECTED]>:
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.
>
