OpenTelemetryDriver don't require DriverManager for underlying drivers

[michalvavrik]

closes: #7028

For reasons explained in the linked issue, it might be handy to register drivers directly against OpenTelemetryDriver rather than against DriverManager. I decided to also go with static registry as drivers are often instantiated connect pools (like Agroal) and it could be difficult to use instance varibles. This PR adds additional Driver collection where drivers can be registered. If driver is registered both with OpenTelemtryDriver and DriverManager, drivers registered with OpenTelemetryDriver are preferred.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: michalvavrik / name: Michal Vavřík (2b39337)

[brunobat]

Thanks @michalvavrik. It looks ok to me.

[brianmolinaspring]

@brunobat how are you? For this PR to be approved, do we need any other approver?

[brunobat]

Not mandatory, but it would be nice

[brianmolinaspring]

@brunobat ok thanks, then you could do the merge?

[michalvavrik]

@brianmolinaspring I asked Bruno to review this as I needed his expertise, but I think we will have to wait for the project maintainers (rights + they know best what's desired here).

[brianmolinaspring]

@michalvavrik Perfect, this would solve, to place the driverManager manually, that is, we would not have to do anything else but only update the libraries, right?

[trask]

thx @michalvavrik!

Is there any use-case for this outside of building native images? I'm thinking about it from docs and public API surface perspective.

[trask]

hey @michalvavrik,

would this be an alternative option? https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jdbc/library/README.md#datasource-way

just trying to understand the use case and restrictions better.

if you happen to be able to join our Thu 9am UTC-8 SIG meeting, that would be a great place to discuss further, since there are a lot of gaps in knowledge on our side about native images

https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=cDl2Z29mcm0zNThlcWp2azVpOTJoODBlNzJfMjAyMjExMTBUMTcwMDAwWiBnb29nbGUuY29tX2I3OWUzZTkwajdiYnNhMm4ycDVhbjVsZjYwQGc&tmsrc=google.com_b79e3e90j7bbsa2n2p5an5lf60%40group.calendar.google.com&scp=ALL

[michalvavrik]

@trask your digging is perfectly fine, I used Agroal with OpenTelemetryDriver and judging from OpenTelemetryDataSource and AgroalDataSource, it should be possible. I'll try to find out why we want with the driver and get back to you (as for meeting, can't tell ATM). Thank you for the time you spent reviewing this.

[brunobat]

@trask, For native mode, all classes that will be used need to be known at runtime. This will affect all Drivers. This means that we cannot create a new Otel Driver Wrapper object at runtime if tracing is needed. This needs to be known at build time.

[trask]

@trask, For native mode, all classes that will be used need to be known at runtime. This will affect all Drivers. This means that we cannot create a new Otel Driver Wrapper object at runtime if tracing is needed. This needs to be known at build time.

thx @brunobat, can you wrap the underlying driver with the OTel wrapper at build time?

[brunobat]

Yes @trask ... That can be done.

[michalvavrik]

I've got a feeling we are not moving forward to the mutual understanding about the issue and possible solutions, so I'll join the meeting on Thursday as Trask proposed.

[michalvavrik]

Hey @trask , now that we have clarified the matter during the meeting, please provide feedback on the PR (required changes, suggestions, ...) once you have a time, thanks.

[trask]

I'm good with the API shape as-is 👍

[michalvavrik]

I don't think CI failures are related to the PR; are failures known issue? My bad, there was unnecessary semicolon in one of the tests.

[trask]

👍