Custom configuration

[crossoverJie]

Describe the solution you'd like

• Customize the configuration file.
• Using flexible.
• Refactor the code.

[crossoverJie]

If we have multiple profiles, So I need to create multiple configuration classes.

Like this:

public class KafkaConfiguration extends AbstractCicadaConfiguration {

    public KafkaConfiguration() {
        super.setPropertiesName("kafka.properties");
    }

}

public class RedisConfiguration extends AbstractCicadaConfiguration {

    public RedisConfiguration() {
        super.setPropertiesName("redis.properties");
    }

}

When I use:

@Override
public WorkRes<DemoResVO> execute(Param paramMap) throws Exception {

    KafkaConfiguration configuration = (KafkaConfiguration) getConfiguration(KafkaConfiguration.class);
    RedisConfiguration redisConfiguration = (RedisConfiguration) ConfigurationHolder.getConfiguration(RedisConfiguration.class);

    String brokerList = configuration.get("kafka.broker.list");
    String redisHost = redisConfiguration.get("redis.host");

    LOGGER.info("Configuration brokerList=[{}],redisHost=[{}]",brokerList,redisHost);

    return res;
}

Is there a better solution?

[huangdenghe]

如果约定好子类的命名规则，将这行代码 super.setPropertiesName("redis.properties") 去掉是否更好一些，然后父类中

        String classSimpleName = getClass().getSimpleName();
        propertiesName = classSimpleName.substring(0, classSimpleName.length() - "Configuration".length())
                + ".properties";

[crossoverJie]

@huangdenghe

Great!

I've thought about it before.

But if you use it this way, we can not use like this:

kafka_publisher.properties

This may not be consistent with the actual situation.

And this class KafkaConfiguration is empty.

It feels a bit weird.

[zhuSilence]

why don't you put all keys into one file? the different environment uses a different file, How do you deal with the different environment if you do like that?

[LiWenGu]

application.properties:

# default: kafka.properties(properties.A key mean defulat configuration file name is A.properties)
properties.kafka: xxxx.properties
properties.redis: redis1.properties
# all configuration files(code use split)
properties.all: kafka.properties, redis.properties

and use maven profile deal dev/online/test env.

[crossoverJie]

@zhuSilence

Multiple profiles are for easy maintenance, similar to the namespace.

By default, the configuration file under the classpath is read.

In different environments, like this:

-Dapplication.properties=/xx/application.properties
-Dkakfa.properties=/xx/kakfa.properties

[crossoverJie]

@LiWenGu

maven profile can solve environmental problems.

But I want to change the configuration in the pro environment, I need to mvn package again.

[LiWenGu]

haha, my company use mvn package -P xx
maybe it better: application.properties

# default active(mean dev and test dev use the same redis file)
properties.redis = redis.properties

# dev
dev.properties.kafka=kafka_dev.properties

# test
test.properties.kafka=kafka_test.properties

code: Configuration.active('dev...')

[crossoverJie]

@LiWenGu

So the best way is Independent configuration center like apollo.

[Barcelonao]

大家都是中国人 为啥不说汉语 #滑稽

[crossoverJie]

@adminzhao

How to improve without self-restraint?

[LiWenGu]

@crossoverJie finally, custom configuration depend on apollo? #7 goal is how to use apollo in cicada ?

[crossoverJie]

@LiWenGu

Apollo is indeed the best way.

But cicada defined it as a lightweight framework, so it is not recommended to introduce third-party components.

[LiWenGu]

@crossoverJie

so, how you plan the configuration way specific? maybe i can contribute some code. :yum:

Although it as a lightweight framework, also need support third-party components by the Plugins(maybe support it one day).

[crossoverJie]

Prepare to do this.

7

If there are good suggestions. raise a pull request, please.