Aias00 opened a new issue, #8009: URL: https://github.com/apache/shenyu/issues/8009
## Description Follow-up to the plugin orchestration review against master `34f2ed036` and design PR #8007 (`f2839049c`). Parent proposal: #7993. Owning implementation/design task: #7999. Related tasks: #7996, #7994. This issue refines the existing work breakdown; it does not assert that GRAPH execution is already implemented or that the proposed design has been accepted. HTTP/RPC API aggregation and parallel plugin execution remain out of scope. ## Problem Separate LEGACY and GRAPH execution must not create two divergent catalogs of installed plugin instances or configuration handlers. Today ShenyuWebHandler combines chain execution, enable/disable handling, sorting and extension updates. The loader and Spring wiring depend on that concrete handler. A graph plan holding an old plugin object also does not pin the plugin's live selector/rule caches or replacement data handler. ## Code and design evidence - [ShenyuWebHandler plugin events and extension updates](https://github.com/apache/shenyu/blob/34f2ed036/shenyu-web/src/main/java/org/apache/shenyu/web/handler/ShenyuWebHandler.java) - [ShenyuLoaderService.addShenyuPlugin](https://github.com/apache/shenyu/blob/34f2ed036/shenyu-web/src/main/java/org/apache/shenyu/web/loader/ShenyuLoaderService.java) - [CommonPluginDataSubscriber handler replacement](https://github.com/apache/shenyu/blob/34f2ed036/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/cache/CommonPluginDataSubscriber.java) - [gateway bean and loader wiring](https://github.com/apache/shenyu/blob/34f2ed036/shenyu-spring-boot-starter/shenyu-spring-boot-starter-gateway/src/main/java/org/apache/shenyu/springboot/starter/gateway/ShenyuConfiguration.java) ## Task List - Define a common installed-plugin catalog/lifecycle notification boundary; retain separate request execution state and legacy cursor semantics. - Decide whether to retain ShenyuWebHandler as a compatibility facade or introduce an internal registry without breaking existing consumers. - Specify the order and consistency boundary for plugin replacement, handler replacement, cache updates and graph revalidation. - Distinguish immutable topology from live business configuration; do not advertise full configuration snapshots based solely on plugin references. - Define new-request invalidation and in-flight resource retirement, including mandatory dependencies. Resource leases are needed wherever old implementations can be unloaded. ## Acceptance criteria - Both executors observe installation/enable/disable/replacement through one authoritative lifecycle boundary. - Tests cover extension replacement with a new handler and with no handler, disable/removal, active requests and compile failure. - Mandatory dependencies fail closed for new GRAPH requests, while unrelated LEGACY behavior remains unchanged. - No premature plugin resource release and no claim that topology pinning freezes live caches. ## Dependencies and sequencing Resolve the contract portion in #7994 / PR #8007 before depending implementation hardens this assumption. Deliver code and integration coverage under #7999 and the related tasks above. Existing issue dependencies remain in effect; this issue adds a focused review requirement rather than a duplicate full implementation task. -- 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]
