Provide a clear extensibility model for connectors

[TimHess]

Steeltoe Connectors have been completely rebuilt for the 4.0 release and are not currently designed for extensibility.

This issue will be used to track progress and feature requests for that effort.

Please feel free to comment about your use cases and expectations.

[Levyks]

are there any updates regarding this issue now that 4.0 is officially out? now that oracle support was dropped out, I was really looking forward to having some way to add it back even if it was in a hacked-together kinda way

[TimHess]

@Levyks we don't have any updates because no use cases or expectations have been provided. We only removed Oracle because we didn't have a way to test it and didn't want to ship something we couldn't actually test. Can you provide more information on what you're looking for?

[Levyks]

@Levyks we don't have any updates because no use cases or expectations have been provided. We only removed Oracle because we didn't have a way to test it and didn't want to ship something we couldn't actually test. Can you provide more information on what you're looking for?

I mean, some way to implement our own connectors for niche/non-supported stuff, in a way that it could be packaged into non-official community packages.

I'm not sure about what the API would look like, but from my understand, at the end of the day, a connector is just something that:

• Extracts info from Configuration
• Register services into DI using the extracted info (Options objects, connection providers and so on)
• [Optionally] Register health contributors for those services

So maybe some sort of interface that we could override to do that stuff?

But for my own specifc use-case of using Oracle in my app, just making RelationalDatabaseHealthContributor public and generic would already make my life 100% easier (#1595, solves #1594)

EDIT:

After looking a bit further into some of the official connectors' implementations, maybe we just need to expose some of the internal classes like ConnectorConfigurer, ConnectionStringPostProcessor, ConnectorAddOptionsBuilder and some others.

And then creating a entry in the docs like we have for "Creating a Custom Health Contributor"

[TimHess]

@Levyks we don't have any updates because no use cases or expectations have been provided. We only removed Oracle because we didn't have a way to test it and didn't want to ship something we couldn't actually test. Can you provide more information on what you're looking for?

I mean, some way to implement our own connectors for niche/non-supported stuff, in a way that it could be packaged into non-official community packages.

Sorry, I think I didn't ask the right question... Why do you want to do that (what do you expect to gain using the Steeltoe abstractions)? While Steeltoe Connectors provide an alternate way of managing the components of a connectionstring, they were primarily built to provide a seamless transition from a local development to cloud platforms, specifically those that provide some form of service binding abstraction (like VCAP_SERVICES and cloud native service bindings). I would be interested to hear about any other situations where Connectors are being used!

I'm not sure about what the API would look like, but from my understand, at the end of the day, a connector is just something that:

• Extracts info from Configuration
• Register services into DI using the extracted info (Options objects, connection providers and so on)
• [Optionally] Register health contributors for those services

So maybe some sort of interface that we could override to do that stuff?

But for my own specifc use-case of using Oracle in my app, just making RelationalDatabaseHealthContributor public and generic would already make my life 100% easier (#1595, solves #1594)

EDIT:

After looking a bit further into some of the official connectors' implementations, maybe we just need to expose some of the internal classes like ConnectorConfigurer, ConnectionStringPostProcessor, ConnectorAddOptionsBuilder and some others.

And then creating a entry in the docs like we have for "Creating a Custom Health Contributor"

All of that looks like relatively accurate for "what" is needed to resolve this issue, but in order to get the clearest "how" we need the "why", that's what's still missing. So, for you (or anybody else willing to provide input here) we would like to know:

• What cloud platform you're running on
• The type of service a connection is managed for (eg: Oracle)
• How that connection is managed (eg: a Cloud Foundry tile, user provided service, something else)
• What format the credentials are provided in (eg: supported MySQL credentials )

I'll add that we are in the process of ensuring that Steeltoe meshes well with Aspire, and Connectors are one of the pieces of the puzzle that may need some adaptation to fit. It may be more complicated than making a few abstractions public.