Use of command in docker mode could Autoconfigure the wrong bean

[philwinder]

For both executor and docker mode, mesos.command is used. But the Executor TaskInfoFactory is triggered on mesos.command: https://github.com/ContainerSolutions/mesos-starter/blob/master/spring-boot-starter-mesos/src/main/java/com/containersolutions/mesos/config/autoconfigure/MesosSchedulerConfiguration.java#L121

Hence, it's only by luck that the Docker TaskInfoFactory is instantiated, because the Executor version is valid because of the use of a mesos.command.

[mwl]

I might need to check again, but since both taskInfoFactoryDocker and taskInfoFactoryCommand are annotated with @ConditionalOnMissingBean(TaskInfoFactory.class) only the first one would be added to the context. So if mess.docker.images has a value a TaskInfoFactory will be placed in the context and therefore taskInfoFactoryCommand will be ignored.

    @Bean
    @ConditionalOnMissingBean(TaskInfoFactory.class)
    @ConditionalOnProperty(prefix = "mesos.docker", name = {"image"})
    public TaskInfoFactory taskInfoFactoryDocker() {
        return new TaskInfoFactoryDocker();
    }

    @Bean
    @ConditionalOnMissingBean(TaskInfoFactory.class)
    @ConditionalOnProperty(prefix = "mesos", name = {"command"})
    public TaskInfoFactory taskInfoFactoryCommand() {
        return new TaskInfoFactoryCommand();
    }

You can check this by adding --debug to command line arguments when starting up the application.

[philwinder]

Only by order. Flip the code around and the other is instantiated.

[mwl]

Instead of matching on command.

Either that, or moving it to another config class where you can add @AutoConfigureBefore annotations.