GSSCredential

[Mark Rotteveel]

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
> 
> 
> 
> Links:
> ------
> [1] http://oracle.com/us/design/oracle-email-sig-198324.gif