morningman commented on PR #66770: URL: https://github.com/apache/doris/pull/66770#issuecomment-5598094321
> ### Compatibility concern: existing 4.1 authorization plugin JARs are not fully upgrade-compatible > Customers may have implemented `AccessControllerFactory` / `CatalogAccessController` against Doris 4.1 and installed the resulting JAR in `fe/lib`. After upgrading Doris and retaining that JAR, the old factory can still be discovered, but this does **not** mean its controller remains binary- or behavior-compatible. > > At the current head (`d106c8039fd1d6358eead58f5013195ab3c12041`), these interfaces change: > > * **Data-policy return types:** `Optional<DataMaskPolicy>` becomes `Optional<DataMaskSpec>`, and `List<? extends RowFilterPolicy>` becomes `List<RowFilterSpec>`. The old payload types are removed. Generic erasure can hide this during loading; execution can then fail resolving a deleted type or reject the returned payload. These plugins need **source changes and a rebuild**, not simply recompilation of unchanged source. This migration is already disclosed in the PR, but it means old policy plugins are not drop-in compatible. [Interface definitions](https://github.com/apache/doris/blob/d106c8039fd1d6358eead58f5013195ab3c12041/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/CatalogAccessController.java#L117-L124) > * **The `hasGlobal` overloads are removed:** existing overrides of `checkCtlPriv/checkDbPriv/checkTblPriv/checkColsPriv(boolean hasGlobal, ...)` are no longer invoked. The adapter applies its own global exemption and calls the non-boolean methods instead, so an old plugin's custom decision logic can silently stop running. [Adapter dispatch](https://github.com/apache/doris/blob/d106c8039fd1d6358eead58f5013195ab3c12041/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/LegacyAccessControllerPlugin.java#L122-L138) > * **The manager getter's JVM descriptor changes:** `getAccessControllerOrDefault(String)` now returns `AuthorizationPlugin` instead of `CatalogAccessController`. Existing compiled calls resolve the old return descriptor and fail with `NoSuchMethodError`. For example, a customer controller delegating through `getAccessManager().getAccessControllerOrDefault("internal").checkGlobalPriv(...)` can fail even if both data-policy methods always return empty. [Changed getter](https://github.com/apache/doris/blob/d106c8039fd1d6358eead58f5013195ab3c12041/fe/fe-core/src/main/java/org/apache/doris/mysql/privilege/AccessControllerManager.java#L710-L713) > * **Plugins reusing old Ranger implementation classes also need migration:** those classes leave the FE classpath, and their constructors/interfaces change. Copying the new Ranger plugin directories does not make their classes visible to an old classpath plugin or restore the old constructors. [Packaging change](https://github.com/apache/doris/blob/d106c8039fd1d6358eead58f5013195ab3c12041/fe/fe-core/pom.xml#L815-L825) > > Therefore, the statement that controllers implementing neither masking nor filtering are “unaffected” is too broad. Simple implementations using only the retained callbacks may continue working, but other existing 4.1 plugins can fail or change behavior. The retained loose-JAR directory loading path has the same API compatibility limitations. > > Could we preserve the deprecated interfaces/method descriptors and translate at the adapter boundary, or explicitly document which existing implementations require source migration? Please also add upgrade coverage using a **JAR already compiled against 4.1**, through both the `fe/lib` classpath and the legacy plugin-directory path. Tests that rebuild legacy helpers against the new interfaces do not establish old-binary compatibility. > > This conclusion is based on source/API comparison with 4.1.0 and the PR base; no customer JAR was executed. I would like say, this is a breaking update. User need to update their plugin to adopt new interface. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
