-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incompatibility with Postgres Data Source #125
Comments
Might this be related to the currently open PR (#115 ) ? I seem to recall there being a chain of related problems around this. But ultimately I think it was determined that the "driver wrapping" approach might be deficient for several reasons. It might very well be the case that using the datasource interface to produce wrapped/proxied connections might be better. This probably entails extracting the driver wrapping logic from the wrapper class(es) and using it in the datasource implementation class? |
right, i was hoping the original author of the PR could resolve the issues with the build but I'll have to take a look. it might just need a rebase or something simple 😉 |
PR #115 has been debugged and merged, so I'll close this ticket out |
Hi,
I am having an issue with your library when I attempt to use it in conjunction with a Postgres data source.
The following very basic code:
Produces the error:
Due primarily to the fact that the Postgres BaseDataSource includes hardcoded assumptions that the jdbc protocol will always be 'postgresql'. See here and here.
Am I doing something wrong here? All of your test code appears to use the
DriverManager.getConnection
interface, which works because it bypasses that DataSource abstraction.Additionally, I am unable to bypass your DriverWrapper, due to the fact that it is auto-loaded by the Java service loader paradigm. This causes issues because if I do not use the 'postgresql_postGIS' protocol, when DriverManager.getConnection is invoked via
BaseDataSource.getConnection
, the DriverWrapper throws a SQL exceptionUnknown protocol or subprotocol in url
. This is already documented as an issue in ticket #113. As a result, I fear that my only path forward might be to repackage your jar without the META-INF service loader file, or to repackage the jar with a fix for #113 included.Thanks
The text was updated successfully, but these errors were encountered: