You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The older datasources implement the interface FirebirdConnectionProperties to specify properties common to all datasources. The new implementations of ConnectionPoolDataSource and XADataSource does not implement this interface.
The JDBC 4.1 spec states:
"DataSource properties are not intended to be directly accessible by JDBC clients.
This design is reinforced by defining the access methods on the implementation
class rather than on the public DataSource interface used by applications.
Furthermore, the object that the client manipulates can be a wrapper that only
implements the DataSource interface. The setter and getter methods for the
properties need not be exposed to the client."
For migration purposes it would however be better if the new datasources implement this interface and all its properties (potentially marking some of the properties as deprecated on the interface).
For example: For unclear reasons the older datasources have a 'database' property which takes the full host:port/path (or host/port:path) instead of the databaseName specified in the JDBC spec (to be used in conjunction with serverName and portNumber). The new ConnectionPoolDataSource and XADataSource implementations do not include this database property in favour of the standards defined databaseName, serverName and portNumber.
The reason for this interface was not to expose it to the public, but to guarantee that all parts of driver handle the same set of properties - when a property is added to the interface, all classes that implement this interface, won't compile. So, I think it makes sense to keep the interface in place for exactly this purpose.
As to the "need not be exposed to the client", I guess they mean that in the documentation we should not tell that "if you cast datasource to that interface, you will have access to this and that" and not that no getter/setter should be implemented - how would the connection pools set the properties then?
I guess the main reason for that comment in the spec is that they consider configuration DataSource to be purely a concern for application server, and the user of a datasource should not access the properties.
In any case, I probably should not have included that comment in this ticket: my intention is to implement those properties for the new datasources as well, if only to meet expectations of current users.
Submitted by: @mrotteveel
The older datasources implement the interface FirebirdConnectionProperties to specify properties common to all datasources. The new implementations of ConnectionPoolDataSource and XADataSource does not implement this interface.
The JDBC 4.1 spec states:
"DataSource properties are not intended to be directly accessible by JDBC clients.
This design is reinforced by defining the access methods on the implementation
class rather than on the public DataSource interface used by applications.
Furthermore, the object that the client manipulates can be a wrapper that only
implements the DataSource interface. The setter and getter methods for the
properties need not be exposed to the client."
For migration purposes it would however be better if the new datasources implement this interface and all its properties (potentially marking some of the properties as deprecated on the interface).
For example: For unclear reasons the older datasources have a 'database' property which takes the full host:port/path (or host/port:path) instead of the databaseName specified in the JDBC spec (to be used in conjunction with serverName and portNumber). The new ConnectionPoolDataSource and XADataSource implementations do not include this database property in favour of the standards defined databaseName, serverName and portNumber.
Commits: 7959ef7
The text was updated successfully, but these errors were encountered: