ABin-Huang opened a new pull request, #16457:
URL: https://github.com/apache/dubbo/pull/16457
## What is the purpose of the change
Close #14927.
The issue asks `@Method` / `MethodConfig` to be able to match a group of
interface methods with wildcard characters (e.g. `@Method(name = "create*",
retries = 5, timeout = 6000)`), and an explicitly configured method should
still win over a wildcard rule for the same method.
This PR implements wildcard method-name matching and **exact-match
precedence** at the config layer, so that annotation, XML, API and
properties-based configuration all benefit from the same behavior, while
staying fully backward compatible.
## Brief changelog / design
- `StringUtils`
- Add `hasWildcard(String)` to detect `*` / `?`.
- Add `isWildcardMatch(pattern, text)`: `*` matches any (possibly empty)
sequence, `?` matches exactly one character, matching is case-sensitive and
uses a two-pointer backtracking algorithm instead of regular expressions.
- `AbstractInterfaceConfig`
- Add `resolveMethodConfigs(Class<?> interfaceClass)` which returns an
ordered `List<Map.Entry<String, MethodConfig>>` of **resolved method name ->
the same `MethodConfig` instance**.
- Pass 1 expands wildcard configs with `putIfAbsent` (when several
wildcards overlap, the first declared one wins); pass 2 puts exact-named
configs so that an **exact name always overrides a wildcard** for the same
method.
- `MethodConfig` instances are intentionally **not cloned**: every
resolved name shares the same instance, which keeps non-serializable Spring
callbacks such as `oninvoke` / `onreturn` / `onthrow` working.
- `verifyMethodConfig` matches method-level configs against the interface
methods with the same wildcard rule.
- `ServiceConfig` / `ReferenceConfig`
- Iterate `resolveMethodConfigs(...)` when appending method parameters and
when building async method info, using the entry key as the actual resolved
method name. Argument-config type/index resolution in `ServiceConfig` now uses
the resolved method name as well.
- `ConfigValidationUtils`
- Add `PATTERN_METHOD_NAME_PATTERN` (`[a-zA-Z*?][0-9a-zA-Z*?]*`, allows a
bare `*`) and `checkMethodNamePattern`; `validateMethodConfig` uses the looser
pattern only when the name contains a wildcard, and keeps the strict identifier
rule otherwise.
Default behavior is unchanged: a config without a wildcard resolves exactly
as before.
### Out of scope (follow-up)
The issue also mentions placing `@Method` directly on the
implementation/interface methods. That is a larger, separate capability
(annotation discovery on implementation classes, parent classes and interface
methods) and is intentionally left to a follow-up PR; this change focuses on
wildcard matching for method-level configs.
## Verifying this change
- `StringUtilsTest`: add `testHasWildcard` and `testIsWildcardMatch` (41
tests in total).
- Add `MethodConfigWildcardTest` with 11 tests covering `*` / `?` matching,
exact-over-wildcard precedence, first-declared-wins for overlapping wildcards,
provider/consumer parameter expansion, shared-instance semantics, and the
no-match case.
- Existing `MethodConfigTest` keeps passing as regression (21 tests).
All tests pass locally.
## Documentation
- A wildcard method name accepts `*` (any sequence, including empty) and `?`
(exactly one character); matching is case-sensitive. When both an exact name
and a wildcard match the same interface method, the exact configuration takes
precedence.
## Checklist
- [x] Make sure there is a GitHub_issue field for the change (GitHub issue
#14927).
- [x] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
- [x] Check if a new dependency is required: no new dependency.
- [x] Write unit tests to verify the code.
- [x] No new generated files, binary files, or content unrelated to the
change.
--
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]
