On 19/04/2013 18:34, Lance Andersen - Oracle wrote:
Hi,
We have been asked by a few JDBC driver vendors to allow a JDBC driver to be
notified when/if it was deregistered via DriverManager.deregisterDriver if
desired.
The webrev can be found at http://cr.openjdk.java.net/~lancea/8010416/webrev.01
This looks much better than the original proposal, it would have been
just too problematic to have Driver define a deregister method. Also the
proposed wording to specify Driver-implementation specific behavior when
the Driver or Connections is in use, or subsequent use, addresses the
points that I brought up in the original thread here (thanks!).
Driver
- {@linkplain DriverManager.deregister} -> I assume this should
DriverManagert#deregisterDriver
- minor alignment issue with the <p> tag.
DriverManager
- one point that isn't covered in the spec is whether the DriverAction's
deregister is invoked before or after it is deregistered. This
distinction is probably only interesting for the case that the
deregister method fails with an error/exception but it's not clear if
the driver is still registered in that case. For completeness then the
spec should probably say that any error/runtime exception is propagated
to the caller of deregisterDriver.
- could the new (and the original) registerDriver methods specify the
behavior for the case that the Driver is already registered? This brings
up the question as to whether the DriverAction is overridden if already
registered.
- the @param alignment is inconsistent in the new deregisterDriver.
- the re-wording of the original deregisterDriver looks much better.
Minor nit: "was null" -> "is null".
- DriverInfo - would be cleaner to extend the constructor to take the
DriverAction. Also an action() accessor would make the usage a bit
cleaner too.
That's all I have for now.
-Alan
