Terry Lam

我有一个6.4.3的，直接改好了。你要就丢个邮箱

我这样跟issue问题一样，使用版本是3.2.3.

1.是的@ApolloConfig 也是需要修改增加一个appId的，当时有比较多的类也是需要增加appid的，就不一一列了。 2. EnableApolloConfig 的伪代码。secret是非必填的，有默认值。 @EnableApolloConfig(value = {"application","kafka"},multipleConfig = {@MultipleConfig(appId = "shop",namespaces = {"shop-common","shop2-common"},secret = "${apollo.shop.secret}"), @MultipleConfig(appId = "pay",namespaces = {"pay-common"},secret = "${apollo.pay.secret}")})

```@ApolloConfig ``` 我看代码是你们用来进行config注入的。而```@MultipleConfig``` 是配套在```@EnableApolloConfig```中 作为多appid的配置。如果```@ApolloConfig``` 用于 config的注入，也用于```@EnableApolloConfig``` 中多appid的配置，会不会太混淆了？是不是含义保持单一比较好呢？ 另外还有个问题，现在的设计，注解部分，如果不同namespace存在相同key名，将会以加载顺序优先的config的值进行返回。我在想能不能按appid+namespace 分组获取到对应的config，再取值对注解的值进行反射。 我在想能不能打破的你原来的设计，AutoUpdateConfigChangeListener的resolvePropertyValue，直接解析SpringEl,然后跟根据appid+namespace 获取到对应的config，就设置值。 现有代码如下： ```private Object resolvePropertyValue(SpringValue springValue) { // value will never be null, as @Value and @ApolloJsonValue will not...

> 从含义上而言其实差不多，都是指定 appid/namespace 来注入配置。@EnableApolloConfig 是注入到 spring 的 property sources 中，`@ApolloConfig` 是注入到某个 field 中。 如果 `@ApolloConfig ` 作为`@EnableApolloConfig`的multiple部分,是需要增加secret字段，但是觉得这个注解本来是是注入到某个 field的，增加secret还是怪怪的。感觉还是增加一个新注解好点的样子？ > 这个是为了适配 spring 的 property source 体系。如果要根据 appid+namespace 获取值的话就是完全不同的用法了，比如提供一个不同于 @Value 的注解。 是的，`@Value`属于Spring体系，要适配property...

ok.先用回property source来适配各种，只做一个多appid的拉取。重复的key，走回原有逻辑。后续提交pr给你

**_I have read the CLA Document and I hereby sign the CLA_**

I have changed the Email for submitting code to [email protected], and changed the name to TerryLam2010. Have not submitted open source request merge before,help me please....

Jason, my unit tests pass perfectly when I run them locally, but fail when I run them on GitHub.