You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2011/04/29 18:35:06 UTC

DO NOT REPLY [Bug 48817] Skip validation query and use JDBC API for validation

https://issues.apache.org/bugzilla/show_bug.cgi?id=48817

--- Comment #15 from Glen Taylor <gt...@pgac.com> 2011-04-29 16:35:06 UTC ---
May I ask why no provision was made for _configuring_ the Validator?  I love
the pluggable validation approach, but even the JDBC4 isValid() scenario has a
configurable element (the method's timeout value).  I agree that adding
setValidatorClassName() makes sense for simple Resource configuration where
appropriate, but these being by nature "custom" is seems inevitable that a
Validator would be likely need to have config injected.

Is there a reason that setValidator() had to be removed?  It would be the most
straightforward path for those using IOC-container-wired pools, though it
wouldn't help when using a Tomcat Resource definition.

The only mechanism I can see as things are now would to use a JdbcInterceptor
to inject a configured Validator (since props can be set for JdbcInterceptors),
but that seems a little convoluted.  And what would be the appropriate hook
there?  One could use the poolStarted() event, but wouldn't the initial
connections have been started and tested by then?  Or maybe at the first
connection creation.

Could we not just make the Validator be wired in the same way as the
JdbcInterceptor, where optional properties can be defined?  I can't envision a
need for a _chain_ like the interceptors have, but configurable properties
would be very useful.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org