al.truisme's questions

Estou usando @MessagingGatewaypara fazer a ponte entre spring-mvc @Controllere spring-integration. A @MessagingGatewaydeclaração fica assim:

package a.b.c;

import org.springframework.integration.annotation.*;
import org.springframework.stereotype.Component;

@MessagingGateway(name="inboundGateway" defaultRequestTimeout="2000"
                                        defaultReplyTimeout="2000")

@Component
public interace InboundGateway {

    @Gateway(requestChannel = "getSomething")
    Message<SomeValue> getSomething(@Headers Map<String, Object> headers);

}

que é referenciado por um controlador

@Controller
@RequestMapping("/some/base/path")
public class SomeController {

    private final InboundGateway inboundGateway;

    public SomeController(InboundGateway inboundGateway) {
        this.inboundGateway = inboundGateway;
    }

    @GetMapping(value = "things", produces = { "application/json" })
    public ResponseEntity<SomeValue> getSomething(RequestContext<String> requestContext) {
        Message<SomeValue> response = inboundGateway.getSomething(requestContext);
        ....
}

Eu estava pensando que as definições de defaultRequestTimeoute defaultReplyTimeoutgerariam um tempo limite inboundGatewayse a resposta não fosse retornada dentro do tempo especificado.

Porém, estou vendo que o tempo utilizado no método getSomething()pode ultrapassar o tempo especificado, neste exemplo, 2 segundos. Parece que os 2 segundos são usados ​​como tempo limite para as chamadas para sistemas downstream, mas não como tempo limite para o retorno de getSomething().

Estou entendendo isso corretamente? Existe alguma maneira simples e declarativa de gerenciar o tempo limite no inboundGatewaynível? Qualquer indicação será apreciada.

Estou olhando os exemplos do spring-batch e estou surpreso ao ver um método construtor de bean sendo chamado diretamente, em vez de por meio de uma referência de bean. Estou me perguntando se isso é um erro.

Em https://github.com/TechPrimers/spring-batch-example-1/blob/master/src/main/java/com/techprimers/springbatchexample1/config/SpringBatchConfig.java

...
@Configuration
@EnableBatchProcessing
public class SpringBatchConfig {

    ...

    @Bean
    public FlatFileItemReader<User> itemReader() {

        FlatFileItemReader<User> flatFileItemReader = new FlatFileItemReader<>();
        ...
        flatFileItemReader.setLineMapper(lineMapper());
        return flatFileItemReader;
    }

    @Bean
    public LineMapper<User> lineMapper() {
      ...
    }

Enquanto o método construtor do bean lineMapper()é anotado como @Bean, o método construtor do bean itemReader()não injeta o bean em seu construtor, mas sim o chama lineMethod()diretamente.

Eu esperava esta definição de itemReader():

@Bean
public FlatFileItemReader<User> itemReader(LineMapper<User> lineMapper) {

    FlatFileItemReader<User> flatFileItemReader = new FlatFileItemReader<>();
    ...
    flatFileItemReader.setLineMapper(lineMapper);
    return flatFileItemReader;
}

Isso não é um erro nas amostras atuais do spring-batch? Ou eu estou esquecendo de alguma coisa? Talvez @Configurationfaça algo mágico e converta chamadas diretas para construtores em um bean com proxy? Talvez lineMapper()nem precise ser um feijão?

Obrigado por qualquer visão.