John Little's questions

O Snowflake tem drivers Java JDBC finos, padrão (grossos?) e FIPS. Não preciso de FIPS.

Eu presumi que fino significa leve, sem potes necessários, e grosso significa pesado e incluiria quaisquer potes dependentes.

Portanto, thin seria melhor se você quiser tornar o aplicativo mais rápido para carregar e ter menos conflitos de dependência.

No entanto, tenho visto discussões sobre drivers Oracle tipo 1 a 4 que parecem implicar o oposto.

Qual é a diferença e qual devo escolher para um aplicativo Spring Boot que se conecta diretamente ao Snowflake via JDBC?

=== atualização 1 ===

Eu tentei ambos os drivers snowflake. O Maven não conseguiu resolver todas as dependências necessárias para o driver "thin", então, para economizar tempo, usei o "padrão" deles, que funciona imediatamente com o Maven + Spring Boot.

@Autowired não está funcionando, e não sabemos o porquê. O serviço e o controlador estão em módulos e pacotes diferentes, mas presumimos que isso não importa. Podemos instanciar manualmente o serviço, para que o módulo controlador consiga "ver" o módulo comum.

A execução do aplicativo resulta no seguinte erro:

Parameter 0 of constructor in com.xx.campaign_api.controller.MyController required a bean of type 'com.xx.campaign.common.service.MyService' that could not be found.

Temos um projeto multimódulo spring boot 3.4.2 com o seguinte pom:

<project xxx
    <groupId>org.springframework</groupId>
    <artifactId>our-service</artifactId>
    <version>0.1.0</version>
    <packaging>pom</packaging>

    <modules>
        <module>campaign-common</module>
        <module>campaign-api</module>
        <module>campaign-schedule</module>
    </modules>
</project>

no módulo api temos um controlador rest como este:

package com.xx.campaign_api.controller;
import com.xx.campaign.common.service.MyService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    private MyService testService;

    @Autowired
    public MyController(MyService testService) {  // THIS LINE IS FAILING
        this.testService = testService;
    }

    @GetMapping("/test")
    public String test() {
    return testService.test();
    }
}

O serviço se parece com isto:

package com.xxx.campaign.common.service;
import org.springframework.stereotype.Service;

@Service
public class MyServiceImpl implements MyService {
    @Override
    public String test() {
        return "test3";
    }
}

package com.xxx.campaign.common.service;
public interface MyService {
    public String test();
}

A classe principal se parece com isso:

package com.xx.campaign_api;
@SpringBootApplication
public class CampaignApiApplication {
    public static void main(String[] args) {
        SpringApplication.run(CampaignApiApplication.class, args);
    }
}

no pom do módulo controlador, temos:

    <dependency>
        <groupId>xx</groupId>
        <artifactId>campaign-common</artifactId>
        <version>0.0.1-SNAPSHOT</version>
        <scope>compile</scope>
    </dependency>

Eu também tentei isso:

package com.xx.campaign_api.controller
@SpringBootApplication(scanBasePackages = "com.xx")
@RestController
public class GaController {

    private MyService myService;

    @Autowired
    public GaController(MyService myService) {  // THIS LINE IS FAILING
        this.myService = myService;
    }

Mas este aplicativo não inicia com este erro:

Web application could not be started as there was no org.springframework.boot.web.servlet.server.ServletWebServerFactory bean defined in the context.

Temos o Spring Boot 2.7 + Kafka e podemos consumir mensagens desta forma:

@KafkaListener(topics = "${kafka.topic.stuff}")
public void consume(@Payload String message) {
    log.info("in kafka consumer");
   // process event
}

No entanto, não sabemos se elas estão sendo processadas de forma síncrona (portanto, se demorarmos muito para processar uma mensagem, isso atrasará o processamento da próxima).

Normalmente, podemos ver se ele está processando usando novos threads na saída do log, mas, por algum motivo, esta informação está faltando:

2025-01-06T17:40:00,143Z INFO  pool-2-thread-1 c.c.g.scheduler.SomemScheduler [correlationToken:ANP-06c003a1-d31c-42f6-9d2d-a9cdb5bfde96] => some event scheduler started..

2025-01-06T17:40:07,721Z INFO  org.springframework.kafka.KafkaListenerEndpointContainer#0-0-C-1 c.c.g.s.cdm.consumer.MyConsumer [] => in kafka consumer
2025-01-06T17:40:14,665Z INFO  org.springframework.kafka.KafkaListenerEndpointContainer#0-0-C-1 org.apache.kafka.clients.NetworkClient [] => [Consumer clientId=consumer-SWH-1, groupId=SWH] Node -1 disconnected.

Aqui podemos ver que as linhas registradas em nosso código mostram o nome do thread, mas aquelas registradas dentro do ouvinte do Kafka não, então não podemos ver se ele está criando novos threads ou não.

Em nosso logback.xml temos:

<pattern>%date{"yyyy-MM-dd'T'HH:mm:ss,SSSXXX", UTC} %-5level %thread %logger{42} [%X{correlationTokenKV}] => %msg%n</pattern>

A questão é:

1. O Kafka é um serviço de atendimento ao consumidor?
2. Se não, como fazemos isso?
3. Por que nosso formato de log padrão não está sendo usado?
4. Como fazemos o Kafka usar nosso formatador de log ou, pelo menos, gerar a saída do thread?

Incluímos Kafka assim:

    <dependency>
        <groupId>org.springframework.kafka</groupId>
        <artifactId>spring-kafka</artifactId>
    </dependency>

Alguém acidentalmente criou uma ramificação chamada "bugfix" em nosso repositório BitBucket Cloud há algum tempo, e isso foi mesclado em develop e master. Isso significa que obtemos um erro refs se tentarmos enviar qualquer ramificação que comece com bugfix, por exemplo, "bugfix/ABC-234_somefix"

Não sabemos como foi feita a fusão (por exemplo, se foi mesclada, compactada, rebaseada ou algo parecido).

Podemos assumir que é seguro excluir esta ramificação antiga?

Se pesquisarmos o código-fonte do projeto spring boot 2.0.3 (todos os arquivos), não há menção ao nio.

De acordo com a documentação do spring , o nio está desabilitado por padrão, então não esperamos usá-lo.

Entretanto, quando o aplicativo inicia, ele diz "restartedMain org.apache.coyote.http11.Http11NioProtocol [] => Inicializando ProtocolHandler ["http-nio-8080"]"

Isso significa que estamos usando nio? Se sim, os documentos estão errados sobre o padrão de não usá-lo?

2024-10-23T09:10:56,001Z INFO  restartedMain o.s.b.web.embedded.tomcat.TomcatWebServer [] => Tomcat initialized with port(s): 8080 (http)
2024-10-23T09:10:56,031Z INFO  restartedMain org.apache.coyote.http11.Http11NioProtocol [] => Initializing ProtocolHandler ["http-nio-8080"]
2024-10-23T09:10:56,052Z INFO  restartedMain org.apache.catalina.core.StandardService [] => Starting service [Tomcat]
2024-10-23T09:10:56,052Z INFO  restartedMain org.apache.catalina.core.StandardEngine [] => Starting Servlet Engine: Apache Tomcat/8.5.31

Usamos spring boot open feign com nossos aplicativos java 8 spring boot 2.0.3. O open feign é usado para fazer chamadas REST para outros serviços. Estamos tentando fazer com que o agente java do New Relic "veja" as chamadas feign como parte dos traces, mas ele não as instrumenta de forma alguma.

1. O Open Feign é um cliente web ou é uma biblioteca que usa um cliente web?
2. Como descobrimos qual cliente web ele está usando?
3. como mudaríamos isso?

Disseram-nos que o New Relic suporta apenas os seguintes clientes http, só podemos supor que o Feign não esteja usando nenhum deles:

Akka HTTP 2.4.5 to latest
Akka Http Core from 0.4 to latest
AsyncHttpClient 2.0.0-RC1 to latest
HttpAsyncClient 4.1 to latest
Apache Httpclient from 3.1 to 5.x
java.net.HttpURLConnection
OkHttp 3.6.0 to latest
Ning AsyncHttpClient 1.x
Spring webclient from 5.0.0.release to latest
STTP v2

É assim que incluímos fingir:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
            <version>2.0.0.RELEASE</version>
        </dependency>

Várias pessoas tiveram problemas semelhantes, mas o que foi marcado como solução para elas não resolveu o problema para mim.

Pom.xml:

:
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-webflux</artifactId>
            <scope>test</scope>
        </dependency>
:

ClienteControllerTest2.java

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.reactive.AutoConfigureWebTestClient;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.reactive.server.WebTestClient;

import static org.springframework.http.HttpHeaders.ACCEPT;
import static org.springframework.http.MediaType.APPLICATION_JSON;
import static org.springframework.http.MediaType.APPLICATION_JSON_VALUE;

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureWebTestClient
public class CustomerControllerTest2 {

    @Autowired
    private WebTestClient webTestClient;

    @Test
    void shouldReturnManyCustomers(){
        this.webTestClient
                .get()
                .uri("/customers")
                .header(ACCEPT,APPLICATION_JSON_VALUE)
                .exchange()
                .expectStatus()
                .is2xxSuccessful()
                .expectHeader()
                .contentType(APPLICATION_JSON)
                .expectBody()
                .jsonPath("$.length()").isNumber()
                .jsonPath("$[0].id").isEqualTo(1);
    }
}

Segundo outros, a solução é adicionar "@AutoConfigureWebTestClient" e "@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)"

Mas isso não ajudou.

Quando uso TestRestTemplate não tenho problemas, por exemplo, o seguinte funciona imediatamente:

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.SpringBootTest.WebEnvironment;
import org.springframework.boot.test.web.client.TestRestTemplate;
import org.springframework.boot.test.web.server.LocalServerPort;

import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
public class CustomerControllerTest {

    @LocalServerPort
    private int port;

    @Autowired
    private TestRestTemplate restTemplate;

    @Test
    void greetingShouldReturnDefaultMessage() throws Exception {
        assertThat(this.restTemplate.getForObject("http://localhost:" + port + "/customers",
                String.class)).contains("[email protected]");

    }

}

Estes documentos:

https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.testing.spring-boot-applications.with-running-server

diga que o seguinte funcionará:

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class MyRandomPortWebTestClientTests {

    @Test
    void exampleTest(@Autowired WebTestClient webClient) {
        webClient
            .get().uri("/")
            .exchange()
            .expectStatus().isOk()
            .expectBody(String.class).isEqualTo("Hello World");
    }

}

Mas isso também fornece o mesmo "Nenhum bean qualificado do tipo 'org.springframework.test.web.reactive.server.WebTestClient' disponível: esperado pelo menos 1 bean que se qualifique como candidato a autowire."

Curiosamente, se eu executar o "mvn test", os testes TestRestTemplate e TesWebClient funcionarão. Se eu executar os testes usando o intellij, ele falhará. No intellij, parece não saber como executar nada por padrão, mas há uma configuração de execução "All in package" no junit, que é a única maneira que vejo para executar os testes, e isso executa todos os testes TestRestTemplate sem problemas, mas todos os testes baseados no WebTestClient falham sem o problema de bean qualificado.