BurningCN commented on code in PR #10380:
URL: https://github.com/apache/dubbo/pull/10380#discussion_r932474350
##########
dubbo-config/dubbo-config-spring/src/main/java/org/apache/dubbo/config/spring/ServiceBean.java:
##########
@@ -104,6 +104,13 @@ public void afterPropertiesSet() throws Exception {
moduleModel.getDeployer().setPending();
}
+ @Override
+ public void unexport() {
+ ModuleModel moduleModel =
DubboBeanUtils.getModuleModel(applicationContext);
+ moduleModel.getConfigManager().removeConfig(this);
Review Comment:
> 应该这个词有点太随便了 当一个ref unexport的时候
>
> 1. config里面是否还要保留着这个ref相关的信息
> 2. 因为保存了相关的信息那么同样接口的ref就无法再创建了，是否合适
>
>
当然这个都是要跟设计有关，但是从来没说过一个service和ref是单例的，只有在destroy才需要销毁，至少2.7.x的service和ref的生命周期是跟unexport相关的
我又想了下，针对你上面提到的。在ModuleDeployer销毁的时候，在每个ServiceConfig#unexport发生之后就立马做了configManager的remove操作（所以你说的12情况都不存在），只是这个时机没有放在unexport里面。而且目前unexport操作目前基本都是在ModuleDeployer销毁时调用的，除非说使用者自己去执行了unexport，才出现你说的情况，但一般使用者不会去这么做。
目前的设计是执行export之前，ServiceConfig已经加入到了configManager，unexport之后才将ServiceConfig从configManager移除，即export和unexport内部都没有关注对configManager的添加或移除操作。
不过按照目前的修改，将ServiceConfig的从configManager的移除逻辑放在unexport方法中也没问题。
--
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]
