Hi All, Reading recent replies on Quarkus PR [55677] it does not looks like this proposal is viable... unfortunately.
If we go with a mixed approach similar to our PR [4984], how about the following proposal? * Keep the JDBC persistence code generic and unaware of DataSource implementations (i.e. do not try to "manage" it there) * Handle custom DataSources at the CDI layer in the runtime/* modules (ServiceProducers or similar (shared) code). This layer will choose whether to use the Quarkus-managed DataSource (default), or load the driver dynamically and "manually" configure the DataSource. Custom downstream builds will keep the option to override the DataSource via CDI mechanics. * Do not try to make custom DataSource configuration to be the same as the Quarkus configuration. It can only cause maintenance headache. Define separate, documented configuration options for the dynamic path. Users of the dynamic driver will have to handle deployment differences anyway. * Use Agroal on both paths for consistency. * Add a small integration test for the dynamic path based on MySQL (test-only GPL deps are ok, I guess). As Alex noted above, we'll need to review observability in the custom DataSource case. I believe that no OTel support will be available there by default, which probably needs to be documented (at least). [4984] https://github.com/apache/polaris/pull/4984 [55677] https://github.com/quarkusio/quarkus/pull/55677 Cheers, Dmitri. On Mon, Jul 27, 2026 at 8:23 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi all, > > I previously mentioned the potential for confusion in my review of the > PR. I believe our next steps depend on timing: if a native solution in > Agroal/Quarkus is achievable soon, that would be the ideal path. > Otherwise, I think PR #4984 could serve as a suitable temporary > mitigation. > > Regards, > JB > > On Mon, Jul 27, 2026 at 9:30 AM Alexandre Dutra <[email protected]> wrote: > > > > Hi Yufei, > > > > I am still uncomfortable with the approach taken in #4984 of mixing > > managed and unmanaged datasources. IMHO it's confusing from a > > configuration and observability perspective, and I fear that > > maintaining unmanaged datasources will prove way more complicated than > > "just" starting and stopping a datasource manually. > > > > Thanks, > > Alex > > > > > > On Sun, Jul 26, 2026 at 8:14 PM Yufei Gu <[email protected]> wrote: > > > > > > Thanks for chiming in, JB! That's essentially the approach in my > PR(4984 > > > <https://github.com/apache/polaris/pull/4984>), which corresponds to > Option > > > 2 in Robert's email. Are we OK moving foward with this? > > > > > > Per-realm routing is a potential use case, not the scope of this > effort. > > > > > > Yufei > > > > > > > > > On Sun, Jul 26, 2026 at 10:03 AM Jean-Baptiste Onofré <[email protected] > > > > > wrote: > > > > > > > Hi > > > > > > > > As already said, I still think Quarkus/Agroal stays the default and > > > > single supported pool. I think adding a narrow, JVM-only, documented > > > > runtime driver escape hatch is right. > > > > > > > > Concretely, I would: > > > > 1. Split the PR: runtime driver loading is a small, defensible > > > > feature. The second pool, and per-realm routing are not imho, and > > > > should not ride in on its coattails. > > > > 2. I think per-realm routing is a way bigger architectural decision. > > > > 3. I think we should have an explicit agreement on the contract > before > > > > merging. > > > > > > > > The best would be to use Agroal, supporting a runtime-mounted driver > > > > in JVM mode. I will ping my Quarkus contacts to get the status of > > > > that. > > > > > > > > Regards > > > > JB > > > > > > > > > > > > > > > > On Fri, Jul 24, 2026 at 10:24 PM Yufei Gu <[email protected]> > wrote: > > > > > > > > > > Robert, > > > > > > > > > > I don't think these are hypothetical use cases. They've been > recurring > > > > > design topics in Polaris for well over a year. > > > > > > > > > > - A JDBC driver supplied at runtime instead of being on the > build time > > > > > classpath is important for proprietary and Apache license > incompatible > > > > > drivers, such as MySQL. This has been discussed in the > community for > > > > some > > > > > time, and PR #4281[4] was blocked by this limitation. > > > > > - We've also discussed realm based datasource routing > repeatedly. For > > > > > example: > > > > > - Issue #3890 [1] tracks multi datasource support and > explicitly > > > > > discusses whether separation should be per realm or by > workload. > > > > > - PR #1482 [2] proposed a concrete realm to datasource > mapping. The > > > > > discussion wasn't that the use case was invalid, but that > > > > Quarkus's build > > > > > time datasource model made it difficult. > > > > > - PR #3960 [3] introduced DataSourceResolver as groundwork > for > > > > > datasource routing. The feedback was to refine the design, > not > > > > > that the use > > > > > case itself shouldn't be supported. > > > > > > > > > > Given this history, I don't think the question is whether these > are real > > > > > use cases. The project has already acknowledged them multiple > times. > > > > > > > > > > Romain, thanks for the suggestion. I wish this could be resolved > upstream > > > > > in Quarkus, but I don't have much hope, since build time dependency > > > > > resolution is one of Quarkus's core design principles. > > > > > > > > > > [1] https://github.com/apache/polaris/issues/3890 > > > > > > > > > > [2] https://github.com/apache/polaris/pull/1482 > > > > > > > > > > [3] https://github.com/apache/polaris/pull/3960 > > > > > > > > > > [4] https://github.com/apache/polaris/pull/4281 > > > > > > > > > > Yufei > > > > > > > > > > > > > > > On Fri, Jul 24, 2026 at 8:54 AM Romain Manni-Bucau < > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > If down stream users need to build anything instead of mount the > driver > > > > > > then polaris becomes a lib and not a server, think very few > consumer > > > > see it > > > > > > this way nor would like it so I would favor runtime support. > > > > > > > > > > > > The side note is that it is always better to not compète with > its own > > > > stack > > > > > > so maybe two push back to quarkus natively before acting there. > > > > > > > > > > > > > > > > > > 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 ven. 24 juil. 2026, 17:50, Robert Stupp <[email protected]> a > écrit : > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
