Hi Yufei, Option 1 would not provide either capability at runtime in the upstream Polaris distribution. Optional drivers would be added through a downstream build or assembly, and datasource creation would remain Quarkus-managed.
That is intentional rather than a missing part of option 1. I mentioned runtime driver loading and per-realm routing because they are the two use cases stated for the POC, not because I think the project has already agreed that Polaris itself must support both. The concrete current ask I see is a viable path for optional drivers that Polaris cannot distribute in ASF releases. Runtime loading is one possible answer to that ask. A downstream build or assembly is another. Dynamic per-realm datasource creation is a separate future design. I do not think it should become an implicit requirement for the optional-driver decision before its isolation, lifecycle, resource, and operational contract has been discussed. So before evaluating option 1 against option 2's capabilities, I think we need to decide whether runtime driver loading and Polaris-owned dynamic datasource creation are project requirements. If both are requirements, option 1 is naturally excluded. If they are not, the POC's additional capabilities should not by themselves become acceptance criteria for every alternative. My preference remains to preserve the Quarkus-managed path and address the optional-driver ask as narrowly as possible. Cheers, Robert On Thu, Jul 23, 2026 at 8:59 PM Yufei Gu <[email protected]> wrote: > > > > That ask does not by itself justify moving all supported deployments away > > from Quarkus datasource management. > > Doing so would make Polaris responsible for configuration compatibility, > > lifecycle, health, metrics, tracing, credentials-provider integration, > > shutdown, upgrades, and the support matrix currently covered by Quarkus. > > > > 1. Keep Quarkus-managed data-sources and document the downstream > > build/assembly path for optional drivers. > > 2. Keep Quarkus-managed data-sources as the default and add a > deliberately > > limited JVM-only runtime-driver escape hatch. > > 3. Replace Quarkus-managed data-sources completely. > > > My current preference is ... (option1). > > > Robert, one thing I'm still unclear about is how option 1 would support the > following use cases that you mentioned: > > - Loading optional JDBC drivers at runtime. > - Creating datasources dynamically as a building block for future per > realm routing. > > My PR proposes option 2 because it addresses these use cases while keeping > the existing Quarkus managed deployment path unchanged. > > Yufei > > > On Thu, Jul 23, 2026 at 8:59 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Yufei, > > > > I wonder why you chose Hikari initially in your PR 4984. Understanding > that > > rationale could be helpful for this discussion. > > > > Thanks, > > Dmitri. > > > > On Wed, Jul 22, 2026 at 11:28 PM Yufei Gu <[email protected]> wrote: > > > > > Looks like we have two options at this point: Hikari (Alex, me) and > > Agroal > > > (Dmitri, JB, Romain). > > > > > > Is there any further investigation we should do before making a > decision? > > > Or are we ready to start a vote? > > > > > > Yufei > > > > > > > > > On Thu, Jul 16, 2026 at 10:15 PM Romain Manni-Bucau < > > [email protected] > > > > > > > wrote: > > > > > > > Maybe add "is there more than one committer" on the project as a > > > criteria. > > > > Agroal is far to be my preferred pool but it is as easy as others in > > > terms > > > > of config starting from properties ([1]) and using its listeners. > > > > Also note that I assume all properties will not be exposed but > > abstracted > > > > by polaris configuration (potentially enabling a switch later or a > > > > multipool support like in Apache TomEE) so maybe it is the first > thing > > to > > > > define, the needed properties and callbacks? > > > > > > > > [1] > > > > > > > > > > > > > > https://github.com/agroal/agroal/blob/517fd36ab0cf1faebaae7d57a55c788d499a4c88/agroal-api/src/main/java/io/agroal/api/configuration/supplier/AgroalPropertiesReader.java#L56 > > > > > > > > Romain Manni-Bucau > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > > <https://dotnetbirdie.github.io/> | Blog < > > https://rmannibucau.github.io/ > > > > > > > > | Old > > > > Blog <http://rmannibucau.wordpress.com> | Github > > > > <https://github.com/rmannibucau> | LinkedIn > > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > > < > > > > > > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > > > > > > > > > > Le jeu. 16 juil. 2026 à 22:18, Alexandre Dutra <[email protected]> a > > > > écrit : > > > > > > > > > Hi all, > > > > > > > > > > I don't think the actual pool implementation matters much, but I > > would > > > > > weigh in some important criteria before choosing: > > > > > > > > > > - Is it easily configurable? > > > > > - Is it easily instrumentable? > > > > > - Is it well documented & maintained? > > > > > > > > > > While Agroal is the de facto choice for Quarkus (it's a JBoss > lib), I > > > > > am not sure it outperforms Hikari for all the criteria above. > > > > > > > > > > Thanks, > > > > > Alex > > > > > > > > > > On Thu, Jul 16, 2026 at 6:22 PM Yufei Gu <[email protected]> > > wrote: > > > > > > > > > > > > Thanks everyone for chiming in. Agroal is a good option as well. > It > > > > looks > > > > > > like we're reaching consensus on direct datasource management at > > > > runtime. > > > > > > I'll start working on the implementation soon. > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > On Thu, Jul 16, 2026 at 4:16 AM Jean-Baptiste Onofré < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I agree that direct datasource management at runtime is a > better > > > > > > > approach than relying on quarkus-datasource, which currently > > > requires > > > > > > > build-time dependencies. > > > > > > > > > > > > > > However, we can stay within the Quarkus ecosystem and avoid > > > > > > > introducing new dependencies by using Agroal, which is already > > > > > > > included in our dependencies. This also keeps the door open to > > > > > > > combining it with Panache in the future, should we decide to do > > so. > > > > > > > > > > > > > > Regards, > > > > > > > JB > > > > > > > > > > > > > > On Thu, Jul 16, 2026 at 1:28 AM Yufei Gu <[email protected] > > > > > > wrote: > > > > > > > > > > > > > > > > > If our goal is to transition entirely to a "runtime-driven" > > > > > > > architecture, > > > > > > > > we should commit to it completely by fully removing the > > > > > > > > io.quarkus:quarkus-datasource > > > > > > > > dependency and switching to Hikari unconditionally. > > > > > > > > > > > > > > > > Good point, Alex! I'm open to that. If the community agrees, > I > > > can > > > > > make > > > > > > > > that change. > > > > > > > > > > > > > > > > Romain, I chose Hikari because it is lean, fast, simple. I'm > > open > > > > to > > > > > > > > alternatives like dbcp2 if its evaluation proves better. As > you > > > > said, > > > > > > > both > > > > > > > > have pros and cons. > > > > > > > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 15, 2026 at 11:03 AM Romain Manni-Bucau < > > > > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Dumb question: why hikari? it has some issues like not > > > respecting > > > > > its > > > > > > > conf > > > > > > > > > intentionally (max size in particular is the one which > hurts > > > > since > > > > > you > > > > > > > > > overconsume for a moment your database connections == > prevent > > > > some > > > > > > > services > > > > > > > > > to connect when scaled and tuned at max count), there is no > > > > silver > > > > > > > bullet > > > > > > > > > but something like dbcp2 can be neat to start _there_ if > > agroal > > > > is > > > > > not > > > > > > > used > > > > > > > > > as a base no - that said I dont see why switching at all, > > > agroal > > > > > can be > > > > > > > > > used without build time integration and stay consistent > with > > it > > > > if > > > > > a > > > > > > > day it > > > > > > > > > comes back? > > > > > > > > > > > > > > > > > > > > > > > > > > > Romain Manni-Bucau > > > > > > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > > > > > > > <https://dotnetbirdie.github.io/> | Blog < > > > > > > > https://rmannibucau.github.io/> > > > > > > > > > | Old > > > > > > > > > Blog <http://rmannibucau.wordpress.com> | Github > > > > > > > > > <https://github.com/rmannibucau> | LinkedIn > > > > > > > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > > > > > > > > > > > > > Javaccino founder (Java/.NET service - contact via > linkedin) > > > > > > > > > > > > > > > > > > > > > > > > > > > Le mer. 15 juil. 2026 à 19:13, Alexandre Dutra < > > > > [email protected]> > > > > > a > > > > > > > > > écrit : > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > If jdbc-url is set, Polaris creates and owns the Hikari > > > > > > > datasource. If > > > > > > > > > > it is not set, we keep using the existing Quarkus > > datasource > > > > > path. > > > > > > > > > > > > > > > > > > > > I have strong reservations regarding this design. > > > > > > > > > > > > > > > > > > > > Alternating between a Hikari pool and an Agroal pool > > > depending > > > > > on the > > > > > > > > > > configuration introduces unnecessary complexity and > > potential > > > > > > > > > > confusion. A major drawback is that bugs, performance > > > > > > > characteristics, > > > > > > > > > > and configuration issues will vary across deployments > > purely > > > > > based on > > > > > > > > > > the underlying connection pool in use. > > > > > > > > > > > > > > > > > > > > If our goal is to transition entirely to a > "runtime-driven" > > > > > > > > > > architecture, we should commit to it completely by fully > > > > > removing the > > > > > > > > > > io.quarkus:quarkus-datasource dependency and switching to > > > > Hikari > > > > > > > > > > unconditionally. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > On Tue, Jul 7, 2026 at 7:10 PM Yufei Gu < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Robert, JB, Dmitri, > > > > > > > > > > > > > > > > > > > > > > Thanks, this feedback makes sense. > > > > > > > > > > > > > > > > > > > > > > There are really two motivations here: runtime loading > of > > > > JDBC > > > > > > > drivers, > > > > > > > > > > and > > > > > > > > > > > dynamic datasource creation. The former is useful for > ASF > > > > > binaries > > > > > > > > > where > > > > > > > > > > a > > > > > > > > > > > driver is supplied after Polaris is built. The latter > is > > a > > > > > building > > > > > > > > > block > > > > > > > > > > > for future per realm datasources. > > > > > > > > > > > > > > > > > > > > > > I'm OK that Quarkus/Agroal remains the default for > > > supported > > > > > > > backends. > > > > > > > > > > > That's already part of the POC. > > > > > > > > > > > > > > > > > > > > > > The gap I'm trying to address is where those > assumptions > > no > > > > > longer > > > > > > > > > hold. > > > > > > > > > > > Quarkus can select from predefined datasources, but > they > > > > still > > > > > > > need to > > > > > > > > > be > > > > > > > > > > > configured ahead of time. It doesn't currently provide > > > > Polaris > > > > > > > with a > > > > > > > > > > clean > > > > > > > > > > > way to create new datasources dynamically. > > > > > > > > > > > > > > > > > > > > > > So my intent is for the contract to be: > > > > > > > > > > > > > > > > > > > > > > - Quarkus/Agroal remains the default. > > > > > > > > > > > - Polaris managed JDBC is a JVM only escape hatch > for > > > > > runtime > > > > > > > > > provided > > > > > > > > > > > drivers and dynamically created datasources. > > > > > > > > > > > - Polaris owns the pool and driver lifecycle on that > > > path. > > > > > > > > > > > - Per realm datasource routing should be a separate > > > design > > > > > > > > > discussion. > > > > > > > > > > > It's out of scope for this POC. > > > > > > > > > > > > > > > > > > > > > > JB, I agree we should continue using Quarkus JDBC > drivers > > > for > > > > > the > > > > > > > > > > backends > > > > > > > > > > > we support directly. This path is mainly for the cases > > > > outside > > > > > that > > > > > > > > > > model. > > > > > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 7, 2026 at 8:03 AM Jean-Baptiste Onofré < > > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > > > > > > > Regarding JDBC drivers in the Quarkus ecosystem (in > > > > > > > > > quarkus-extensions > > > > > > > > > > or > > > > > > > > > > > > quarkiverse), I think we can just leverage the > quarkus > > > JDBC > > > > > > > drivers. > > > > > > > > > > > > Using another loading mechanism could be problematic > > for > > > > > future > > > > > > > > > > features > > > > > > > > > > > > (imagine with we want to try native app buld). > > > > > > > > > > > > > > > > > > > > > > > > What is the problem with using the Quarkus JDBC > > drivers? > > > > > > > > > > > > I remember that we agreed to be opinionated about the > > > JDBC > > > > > > > backends > > > > > > > > > we > > > > > > > > > > want > > > > > > > > > > > > to support, so we can be opinionated about the JDBC > > > drivers > > > > > :) > > > > > > > > > > > > > > > > > > > > > > > > I'm not against it, but I would like to understand > > better > > > > the > > > > > > > > > > rationale. > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > JB > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 7, 2026 at 3:03 PM Robert Stupp < > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for pushing this forward. > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that runtime-provided JDBC drivers are a > real > > > > > problem > > > > > > > to > > > > > > > > > > solve. > > > > > > > > > > > > > For ASF-distributed binaries, there are valid cases > > > where > > > > > > > Polaris > > > > > > > > > > should > > > > > > > > > > > > > not bundle a driver, but operators still need a way > > to > > > > > provide > > > > > > > one. > > > > > > > > > > > > > > > > > > > > > > > > > > My concern is that this PR does more than load > > runtime > > > > > driver > > > > > > > jars. > > > > > > > > > > > > > It also introduces a second datasource stack: > > > > > Quarkus/Agroal > > > > > > > via > > > > > > > > > > > > > `quarkus.datasource.*` on one side, and > Polaris-owned > > > > > Hikari > > > > > > > pools > > > > > > > > > > via > > > > > > > > > > > > > `polaris.persistence.relational.jdbc.*` on the > other. > > > > > > > > > > > > > > > > > > > > > > > > > > Those two paths look similar to operators, but they > > do > > > > not > > > > > > > have the > > > > > > > > > > same > > > > > > > > > > > > > contract. > > > > > > > > > > > > > The Quarkus path brings Quarkus/Agroal lifecycle, > > > health, > > > > > > > metrics, > > > > > > > > > > > > > credentials/secret-manager integrations, and the > > > broader > > > > > > > datasource > > > > > > > > > > > > config > > > > > > > > > > > > > surface; those are all important for operators. > > > > > > > > > > > > > The Polaris-managed path means Polaris owns pool > > > > lifecycle, > > > > > > > driver > > > > > > > > > > > > loading, > > > > > > > > > > > > > classloader behavior, and a separate config/support > > > > > surface. > > > > > > > > > > > > > > > > > > > > > > > > > > So I do not think this is ready to move forward as > > just > > > > > > > “another > > > > > > > > > JDBC > > > > > > > > > > > > > configuration option.” > > > > > > > > > > > > > > > > > > > > > > > > > > Before I would consider this mergeable, I think we > > need > > > > > > > explicit > > > > > > > > > > > > agreement > > > > > > > > > > > > > on the contract: > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Is Polaris-managed JDBC only a narrow escape > hatch > > > for > > > > > > > > > > > > runtime-provided > > > > > > > > > > > > > driver jars, or a peer supported datasource path? > > > > > > > > > > > > > 2. Which Quarkus/Agroal integrations are > > intentionally > > > > not > > > > > > > > > available > > > > > > > > > > on > > > > > > > > > > > > > that path? > > > > > > > > > > > > > 3. What lifecycle does Polaris own for pools, > loaded > > > > > drivers, > > > > > > > > > > shutdown, > > > > > > > > > > > > and > > > > > > > > > > > > > driver upgrades? > > > > > > > > > > > > > 4. Is this meant to be part of future per-realm > > > > datasource > > > > > > > routing? > > > > > > > > > > If > > > > > > > > > > > > so, > > > > > > > > > > > > > I think that needs a separate design discussion. > > > > > > > > > > > > > > > > > > > > > > > > > > Until that contract is agreed, I do not think we > > should > > > > > present > > > > > > > > > this > > > > > > > > > > as a > > > > > > > > > > > > > second supported JDBC path or treat the PR as > > mergeable > > > > > with > > > > > > > > > > > > documentation > > > > > > > > > > > > > updates alone. > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 7, 2026 at 3:48 AM Dmitri Bourlatchkov > < > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the update. That approach to loading > the > > > > > driver > > > > > > > can > > > > > > > > > > work, I > > > > > > > > > > > > > > think. > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I'm not sure whether it is preferable > to a > > > > > proper > > > > > > > > > Quarkus > > > > > > > > > > > > > > downstream build. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Adding jars to Polaris still requires some form > of > > > > > downstream > > > > > > > > > > build, > > > > > > > > > > > > > > whether it is tar-based or docker-based. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Performing a full Quarkus build downstream offers > > > some > > > > > > > > > advantages, > > > > > > > > > > > > > though: > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Integration tests can be executed with the > > specific > > > > > driver. > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Dependencies are resolved / validated at build > > > time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Quarkus manages the DataSource lifecycle. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I wonder what other people think too. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 6, 2026 at 9:22 PM Yufei Gu < > > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Dmitri, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good catch. The initial POC only proved the > > driver > > > > > works if > > > > > > > > > it’s > > > > > > > > > > > > > already > > > > > > > > > > > > > > > visible to the runtime classloader. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the approach so the Polaris-managed > > JDBC > > > > > > > datasource > > > > > > > > > can > > > > > > > > > > > > load > > > > > > > > > > > > > > > driver jars explicitly before creating Hikari. > In > > > the > > > > > > > binary > > > > > > > > > > > > > > distribution, > > > > > > > > > > > > > > > users can drop jars into: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > server/jdbc-drivers/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For admin-tool bootstrap/purge, the same > applies > > > > under: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > admin/jdbc-drivers/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > They can also override the location with: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.driver-directory=/path/to/jdbc-drivers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So this does not depend on adding jars to > > lib/main > > > or > > > > > > > > > rebuilding > > > > > > > > > > the > > > > > > > > > > > > > > > Quarkus fast-jar metadata. The jar just needs > to > > be > > > > > present > > > > > > > > > > before > > > > > > > > > > > > > > Polaris > > > > > > > > > > > > > > > creates the datasource. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 6, 2026 at 3:25 PM Dmitri > > Bourlatchkov > > > < > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you provide some more details about how > > > > > exactly a > > > > > > > 3rd > > > > > > > > > > party > > > > > > > > > > > > > JDBC > > > > > > > > > > > > > > > > driver is incorporated into Polaris? I might > > have > > > > > missed > > > > > > > that > > > > > > > > > > in > > > > > > > > > > > > the > > > > > > > > > > > > > > PR, > > > > > > > > > > > > > > > > but it was not apparent to me at first > reading. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 6, 2026 at 6:22 PM Yufei Gu < > > > > > > > > > [email protected]> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I put together a small POC( > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/4984 > > > > > > > > > > > > > > > ) > > > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > the relational JDBC backend so Polaris can > > > create > > > > > its > > > > > > > own > > > > > > > > > > JDBC > > > > > > > > > > > > > > > datasource > > > > > > > > > > > > > > > > > from config, instead of always relying on > the > > > > > Quarkus > > > > > > > > > > datasource. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The config looks like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.jdbc-url=jdbc:postgresql://... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.driver=org.postgresql.Driver > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.username=... > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.password=... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If jdbc-url is set, Polaris creates and > owns > > > the > > > > > Hikari > > > > > > > > > > > > datasource. > > > > > > > > > > > > > > If > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > is not set, we keep using the existing > > Quarkus > > > > > > > datasource > > > > > > > > > > path. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also added tests showing that: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - We can create datasources dynamically > > from > > > > > config > > > > > > > > > > > > > > > > > - Different configurations can create > > > > > independent > > > > > > > > > > datasources, > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > could help future per-realm datasource > > > support > > > > > > > > > > > > > > > > > - A JDBC driver can be supplied at > runtime > > > > from > > > > > a > > > > > > > jar > > > > > > > > > > instead > > > > > > > > > > > > of > > > > > > > > > > > > > > > being > > > > > > > > > > > > > > > > > on the build-time classpath. This is > very > > > > > helpful > > > > > > > for > > > > > > > > > > > > > proprietary > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > Apache license-incompatible drivers, > like > > > > MySQL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This POC does not yet implement full > > per-realm > > > > > > > datasource > > > > > > > > > > > > routing. > > > > > > > > > > > > > It > > > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > demonstrates the lower-level building > blocks: > > > > > Polaris > > > > > > > can > > > > > > > > > > create > > > > > > > > > > > > > > > managed > > > > > > > > > > > > > > > > > JDBC pools from config, multiple pools can > be > > > > > created > > > > > > > > > > > > > independently, > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > the JDBC driver can be supplied at runtime. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Feedback is welcome before I turn this > into a > > > > > formal > > > > > > > PR. > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
