GSSCredential

[Mark Rotteveel]

On 29-5-2019 23:07, Douglas Surber wrote:
>    V2
> 
>    /**
>     * Provide a GSSCredential to authenticate the connection with the server.
>     * The default is to throw {@code UnsupportedOperationException}. A
>     * {@code ConnectionBuilder} that does not support this capability should
>     * override this method to do nothing and throw {@code SQLFeatureNotSupportedException}
>     * in the {@code ConnectionBuilder#build} method if this method was called.
>     *
>     * @param credential used to authenticate the connection. Not null.
>     * @return this ConnectionBuilder
>     */
>    default ConnectionBuilder gssCredential(org.ietf.jgss.GSSCredential credential) {
>      throws new UnsupportedOperationException("java.sql.ConnectionBuilder#gssCredential");
>    }
> 
> I can go either way with making ConnectionBuilder extend Wrapper. A proper DataSource type will have a covariant override of createConnectionBulider that returns the appropriate ConnectionBuilder type. A proper ConnectionBuilder type will have covariant overrides of every method that return that ConnectionBuilder type. Given that, unwrapping the DataSource is sufficient to expose all ConnectionBuilder extensions. So making ConnectionBuilder extend Wrapper isn't necessary. But it doesn't hurt anything.

I can imagine cases where code might get passed a ConnectionBuilder 
without having access to the DataSource, so then being able to unwrap 
might be helpful.

> Note that a proper implementation of DataSource (or ConnectionBuilder) unwrap will return a proxy of the correct type so that the proxy's build method can wrap the built connection.

That depends on the type of DataSource. For plain DataSource 
implementations that might not be very important, for DataSource 
providing a connection pool it could be.

Mark
-- 
Mark Rotteveel