Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConfigCenterConfig's member field's key wrong #3682

Closed
2 tasks
tswstarplanet opened this issue Mar 17, 2019 · 3 comments · Fixed by #3688
Closed
2 tasks

ConfigCenterConfig's member field's key wrong #3682

tswstarplanet opened this issue Mar 17, 2019 · 3 comments · Fixed by #3688

Comments

@tswstarplanet
Copy link
Contributor

tswstarplanet commented Mar 17, 2019

  • I have searched the issues of this repository and believe that this is not a duplicate.
  • I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

  • Dubbo version: 2.7.1-SNAPSHOT
  • Operating System version: MacOS 10.14
  • Java version: 1.8

I find some member fields of ConfigCenterConfig are annotated by @parameter, and the 'useKeyAsProperty' property of the annotation is set 'false'.
For example, the 'check' member field is annotated by @parameter, and its key is "config.check", but the 'useKeyAsProperty' is false.
So the key of this field in URL's parameters is 'check' because the 'useKeyAsProperty' is false, but in config center configuration class like ApolloDynamicConfiguration, the class use 'config.check' to get the property from parameters of URL.
So I think we should adjust the setting.
How about set the 'useKeyAsProperty' to true ?
I want to listen others' proposals.

Steps to reproduce this issue

config

<dubbo:configcenter address:xxx check="false"/>

Expected Result

the key in url's parameters should be "config.check", because in apollo dynamic configuration class, it use the key to get the check property
What do you expected from the above steps?

Actual Result

the key in parameters is check

If there is an exception, please attach the exception trace:

Just put your stack trace here!
@tswstarplanet tswstarplanet changed the title ConfigCenterConfig's check key wrong ConfigCenterConfig's member field's key wrong Mar 17, 2019
@chickenlj
Copy link
Contributor

So the key of this field in URL's parameters is 'check' because the 'useKeyAsProperty' is false, but in config center configuration class like ApolloDynamicConfiguration, the class use 'config.check' to get the property from parameters of URL.

I don't think the problem you described exists.
To clarify the relations between check and useKeyAsProperty and also to avoid misunderstanding, I add some comments on @parameter, please help to check.

@slankka
Copy link
Contributor

slankka commented Jul 23, 2019

I noticed the properties of ConfigCenterConfig is not read correctly by org.apache.dubbo.configcenter.support.apollo.ApolloDynamicConfiguration

Dubbo Version 2.7.1
The namespace is changed to consumer, but the program still access the default namespace:dubbo

        ConfigCenterConfig configCenterConfig = new ConfigCenterConfig();
        configCenterConfig.setAddress("xxx.com");
        configCenterConfig.setProtocol("apollo");
        configCenterConfig.setNamespace("consumer");

The code in ApolloDynamicConfiguration:

//CONFIG_NAMESPACE_KEY = "config.namespace"
//DEFAULT_GROUP = "dubbo"
dubboConfig = ConfigService.getConfig(url.getParameter(CONFIG_NAMESPACE_KEY, DEFAULT_GROUP));

And it always be "dubbo", due to the url field parameters has no config.namespace but namespace:

ApolloDyC_20190723121050

The namespace is set by config.namespace, then it works fine.

 @Bean
    public ConfigCenterConfig configCenterConfig() {
        ConfigCenterConfig apollo = new ConfigCenterBuilder()
                .address("xxx.com")
                .protocol("apollo")
                .namespace("consumer")
                .appendParameter("config.namespace", "consumer")
                .build();

        return apollo;
    }

@slankka
Copy link
Contributor

slankka commented Jul 23, 2019

#4411 The problem has been solved. Please ignore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants