terrymanu commented on issue #26805:
URL:
https://github.com/apache/shardingsphere/issues/26805#issuecomment-3638021599
## Problem Understanding
You’re on 5.3.1 with ShardingSphere-JDBC, using a custom/wrapped
DataSource that hides url/username getters. At startup, resource metadata
construction throws an NPE, and you’re asking if there’s a correct way to avoid
the reflection dependency.
## Root Cause
ShardingSphere gathers standard connection properties (url, username,
etc.) via DataSourcePropertiesCreator/DataSourcePoolReflection or via a
DataSourcePoolMetaData SPI mapping for that DataSource type. This avoids
opening real connections during startup while still
detecting database type/instance for routing checks. Your custom wrapper
exposes neither standard getters nor a DataSourcePoolMetaData SPI, so
standardProps.get("url")/get("username") are null and toString() causes the
NPE. This is an unsupported custom DataSource usage
rather than a generic framework bug.
## Analysis
- The design explicitly avoids getConnection().getMetaData() to prevent
real connections at startup (some pools disallow it or it’s too costly) and
keeps metadata acquisition in SPI/reflection.
- Built-in pools (e.g., HikariCP) ship with DataSourcePoolMetaData so
url/username are known. Custom or wrapped DataSources must supply that layer
themselves.
- Your current workaround (adding getUrl()/getUsername() getters on the
wrapper) works because it supplies the missing metadata access points; the more
standard approach is to implement the SPI.
## Conclusion
This is caused by a custom DataSource that hasn’t been adapted per
ShardingSphere’s expectations, not a general bug.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
