GSSCredential

[Douglas Surber]

  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.

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.

Douglas



> On May 29, 2019, at 1:16 PM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:
> 
> On 2019-05-29 19:43, Lance Andersen wrote:
>> When/if an update is made it will be in  JDBC 4.4 as part of an MR.
>> I do not have a timeframe for an MR as of this time.  I am gathering
>> small things for an MR but not at that point yet.
> 
> Ok, is adding SQL:2016 DECFLOAT (mapping to java.math.BigDecimal) to Types and JDBCType also up for consideration for 4.4?
> 
>> Not sure there is a need for ConnectionBuilder to extend Wrapper given
>> you can unwrap the Connection if needed.
> 
> I was thinking unwrapping might give a natural way to access vendor specific extensions to ConnectionBuilder.
> 
> For example say there is a FooConnectionBuilder interface:
> 
> public interface FooConnectionBuilder extends java.sql.ConnectionBuilder {
>    FooConnectionBuilder setBar(Bar bar);
> }
> 
> Then you might access it through
> 
> DataSource ds = ..
> ds.createConnectionBuilder().unwrap(FooConnectionBuilder.class).setBar(...)
> 
> That allows for a fluent continuation of the builder. It would also have provided a more natural workaround for gssCredential() not being part of the current API.
> 
> One thing I now notice, is that none of the other methods (except build()) in ConnectionBuilder throw a SQLException, so maybe neither should gssCrendential(..). It should also not be necessary to document a "@throws SQLException if an error occurs." because adding the credential to the builder should only have an effect on build().
> 
> The only question then remains what to do with implementations that don't support this. Throwing UnsupportedOperationException instead of SQLFeatureNotSupportedException might be an option, or implementations could defer the exception until build() or just plain ignore it. On the other hand throwing UnsupportedOperationException instead of SQLFeatureNotSupportedException might be a deviation from the rest of the JDBC API, and ignoring it is probably not a good idea either.
> 
> Mark
> 
>>> On May 29, 2019, at 1:25 PM, Mark Rotteveel <mark at lawinegevaar.nl>
>>> wrote:
>>> On 28-5-2019 20:54, Douglas Surber wrote:
>>>> We have received a request to add the following method to
>>>> java.sql.ConnectionBuilder.
>>>> /**
>>>> * Provide a GSSCredential to authenticate the connection with
>>>> the server.
>>>> *
>>>> * @param credential used to authenticate the connection. Not
>>>> null.
>>>> * @return this ConnectionBuilder
>>>> * @throws SQLException if an error occurs.
>>>> */
>>>> ConnectionBuilder gssCredential(org.ietf.jgss.GSSCredential
>>>> credential) throws SQLException;
>>>> Any thoughts?
>>> It needs to be documented that this is an optional method, and the
>>> documentation must include a @throws SQLFeatureNotSupportedException
>>> to that effect. The default implementation should throw
>>> SQLFeatureNotSupportedException.
>>> Addition of this to ConnectionBuilder, also warrants the question if
>>> a similar method should be added to javax.sql.CommonDataSource
>>> (although maybe lifetime of credentials are a factor here)
>>> Also, looking at ConnectionBuilder, shouldn't it extend
>>> java.sql.Wrapper (eg to 'unwrap' to implementation specifics)?
>>> BTW: In what form will these changes land, is there a JDBC 4.4 in
>>> the works, or will these just be an update to the API without a
>>> formal JDBC maintenance version?
>>> Mark
>>> --
>>> Mark Rotteveel
>> [1]
>> [1] [1]
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> Links:
>> ------
>> [1] http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>