feat(client):add many path register for spring mvc client.#6348
Conversation
|
Hi, @Aias00, when you have time, could you please help review this PR? Thank you. |
|
@wy471x hi, pls fix the review |
Previously buildApiDocDTO called buildApiSuperPath (singular), so only the first class-level prefix was used in generated API docs. Now iterates over buildApiSuperPaths to produce ApiDocRegisterDTO for every prefix. Also fixes a potential NPE in buildApiPath when a method annotation has an empty path array. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Aias00
left a comment
Aias00
left a comment
There was a problem hiding this comment.
Thanks for the PR. The main route registration path looks like the right direction, but I think we should add one regression test before merging.
The new logic expands class-level paths in SpringMvcClientEventListener#handle() and also changes API doc generation to iterate buildApiSuperPaths(). However, the current unit tests only assert buildApiSuperPaths() and buildApiDocSextet(), while the integration test verifies gateway routing only.
Please add a publisher-level/unit test that captures the emitted MetaDataRegisterDTO and ApiDocRegisterDTO for a controller with multiple class-level paths, and assert the exact count and paths, for example both:
/mvc/multipath/v1/greet/mvc/multipath/v2/greet
This is important because the registration contract is now "one Java method can produce multiple registered paths", while metaDataMap is still keyed by Method and API doc generation depends on that registration flow. Even if ApiExt is path-independent today, this behavior should be locked by tests.
Also, please consider avoiding the suffix-based fallback heuristic in buildApiPath() (superPath.endsWith(formatPath(p))) or at least cover it with tests. It is hard to reason about method-vs-class annotation provenance from string shape alone.
Replace the superPath.endsWith(formatPath(p)) deduplication check with explicit annotation-provenance routing in handleMethod. When the method has its own @ShenyuSpringMvcClient, the annotation path is used directly. When falling back to the class-level annotation, @RequestMapping path is used instead — avoiding both path duplication and false-positive suffix matches. Also adds buildApiPathFromRequestMapping for the fallback path and 5 new unit tests covering buildApiPath edge cases. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
I have made the corresponding fixes and added relevant test cases for coverage. Please review them, thank you. |
|
thx for pr, have my wechat? aias00 |
Feat(#6327): Support many path register into same controller.
Make sure that:
./mvnw clean install -Dmaven.javadoc.skip=true.All changes:
Unit Tests:
1.testBuildApiDocSextetDefaultProducesConsumes
2.testBuildApiDocSextetExplicitProducesConsumesAndMethod
3.testBuildApiDocSextetMultipleMethodsProducesConsumes
close #6327