Конечные точки Spring Boot 2 Actuator недоступны с Jersey

У меня есть очень простое демонстрационное приложение, использующее Spring Boot 2.0.x.RELEASE.

В моем ПОМ у меня есть:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.0.4.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <java.version>1.8</java.version>
    <spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jersey</artifactId>
        <exclusions>
            <exclusion>
                <!-- We're using undertow as our embedded web container instead of tomcat -->
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-tomcat</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

    <!-- Embedded web container- serves Jersey resources -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-undertow</artifactId>
    </dependency>

    <!-- Support for Spring Actuator & Health Check Endpoints -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.hateoas</groupId>
        <artifactId>spring-hateoas</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>

</dependencies>

Мое основное приложение выглядит так:

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

    @Bean
    ResourceConfig getJerseyConfig() {
        final HashMap<String, Object> jerseyProperties = new HashMap<>();
        jerseyProperties.put(ServerProperties.MEDIA_TYPE_MAPPINGS, "json : application/json");
        ResourceConfig resourceConfig = new ResourceConfig()
                .register(TestEndpoints.class);
        resourceConfig = resourceConfig.setProperties(jerseyProperties);

        return resourceConfig;
    }
}

Когда я затем пытаюсь попасть в конечную точку исполнительного механизма, такую ​​как /actuator, я получаю 404, но я могу без проблем попасть в конечные точки в TestEndpoints.java. У меня это работало с Spring Boot 1.5.x, но теперь кажется, что Джерси не пропускает конечные точки привода. Если я полностью удалю bean-компонент ResourceConfig, то смогу попасть в конечные точки исполнительного механизма. Есть ли какая-то конфигурация, которую я должен добавить, чтобы позволить конечным точкам привода через майку?

/actuator/info?
NiVeR 31.07.2018 21:14

Мне удалось заставить это работать, проверьте stackoverflow.com/a/56325410/320087

Niraj Sonawane 27.05.2019 13:53
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
3
2
1 751
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Это потому, что по умолчанию Jersey будет использовать сопоставление URL-адресов /*, которое будет обрабатывать все запросы, включая запросы к конечным точкам исполнительных механизмов, которые он не найдет. Есть два решения; вы можете изменить базовый URL-адрес Джерси на что-то другое, например /api/*, или вы можете настроить Jersey как фильтр (вместо сервлета по умолчанию) и установить свойство, чтобы заставить Jersey пересылать все запросы, которые он не знает, в контейнер сервлета. Оба примера можно найти в эта почта.

Спасибо, добавив, что это сработало. Есть ли причина, по которой до обновления до SB 2 / Finchley я мог получить доступ к приводу без необходимости в свойствах фильтра и пересылки?

Tim 01.08.2018 13:47

Я не знаю. Это всегда было проблемой, даже до версии 2.0. Вы использовали другой базовый URI?

Paul Samsotha 01.08.2018 15:23

Это было настроено до меня, поэтому не знаю, как им удалось заставить его работать без этого. Но все было в / <service> / v <version> / * и / <service> / v <version> / management / * для привода. Это та же самая установка, которую я использую сейчас, только с обновленными версиями всего, поэтому я не вижу, как она работала раньше. Спасибо за помощь

Tim 01.08.2018 18:00

Другие вопросы по теме