Thanks for opening this discussion, Yong! I support this change (you'll notice that I proposed it in GH comments).
Cheers, Dmitri. On Mon, Feb 2, 2026 at 9:37 PM Yong Jin Lee via dev <[email protected]> wrote: > Hi, > > I’m working on PR #3480 <https://github.com/apache/polaris/pull/3480>, > which adds proxy configuration support for federated catalogs (issue #3465 > <https://github.com/apache/polaris/issues/3465>). The PR takes a > *breaking-change* approach for ExternalCatalogFactory rather than a > deprecation path. > > *Change summary* > > `ExternalCatalogFactory` Methods now include a catalogProperties parameter: > > Before: > > - > > createCatalog(ConnectionConfigInfoDpo, PolarisCredentialManager) > - > > createGenericCatalog(ConnectionConfigInfoDpo, PolarisCredentialManager) > > After: > > - > > createCatalog(ConnectionConfigInfoDpo, PolarisCredentialManager, > Map<String, String> catalogProperties) > - > > createGenericCatalog(ConnectionConfigInfoDpo, PolarisCredentialManager, > Map<String, String> catalogProperties) > > *Rationale* > > This aligns with Polaris evolution expectations > <https://github.com/apache/polaris/blob/main/EVOLUTION.md> and avoids: > > - > > runtime WARN noise from deprecated methods on each catalog operation > - > > additional indirection/complexity from default-method delegation > > *Impact + migration* > > If you have an external implementation of ExternalCatalogFactory, you’ll > need to update the method signatures and pass/merge catalogProperties > (e.g., > via RESTUtil.merge() with your existing properties). This enables passing > HTTP client settings (proxy, timeouts, etc.) through to federated catalog > connections. > > The PR has been reviewed and approved. Please let us know if there are any > concerns. > > Thank you, > Yong-Jin >
