You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
spring-boot/spring-boot-actuator/pom.xml

374 lines
11 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-parent</artifactId>
<version>2.0.0.BUILD-SNAPSHOT</version>
<relativePath>../spring-boot-parent</relativePath>
</parent>
11 years ago
<artifactId>spring-boot-actuator</artifactId>
<name>Spring Boot Actuator</name>
<description>Spring Boot Actuator</description>
<url>http://projects.spring.io/spring-boot/</url>
<organization>
<name>Pivotal Software, Inc.</name>
<url>http://www.spring.io</url>
</organization>
<properties>
<main.basedir>${basedir}/..</main.basedir>
</properties>
<dependencies>
<!-- Compile -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-autoconfigure</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<!-- Optional -->
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>io.searchbox</groupId>
<artifactId>jest</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.hateoas</groupId>
<artifactId>spring-hateoas</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.plugin</groupId>
<artifactId>spring-plugin-core</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.webjars</groupId>
<artifactId>hal-browser</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.github.ben-manes.caffeine</groupId>
<artifactId>caffeine</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-spring</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.timgroup</groupId>
<artifactId>java-statsd-client</artifactId>
<optional>true</optional>
</dependency>
Refactor metrics to expose richer feature set Main user-facing interface is still Counter/GaugeService but the back end behind that has more options. The Default*Services write metrics to a MetricWriter and there are some variants of that, and also variants of MetricReader (basic read-only actions). MetricRepository is now a combination of MetricReader, MetricWriter and some more methods that make it a bit more repository like. There is also a MultiMetricReader and a MultiMetricRepository for the common case where metrics are stored in related (often open ended) groups. Examples would be complex metrics like histograms and "rich" metrics with averages and statistics attached (which are both closed) and "field counters" which count the occurrences of values of a particular named field or slot in an incoming message (e.g. counting Twitter hastags, open ended). In memory and redis implementations are provided for the repositories. Generally speaking the in memory repository should be used as a local buffer and then scheduled "exports" can be executed to copy metric values accross to a remote repository for aggregation. There is an Exporter interface to support this and a few implementations dealing with different strategies for storing the results (singly or grouped). Codahale metrics are also supported through the MetricWriter interface. Currently implemented through a naming convention (since Codahale has a fixed object model this makes sense): metrics beginning with "histogram" are Histograms, "timer" for Timers, "meter" for Meters etc. Support for message driven metric consumption and production are provided through a MetricWriterMessageHandler and a MessageChannelMetricWriter. No support yet for pagination in the repositories, or for HATEOAS style HTTP endpoints.
11 years ago
<dependency>
<groupId>io.dropwizard.metrics</groupId>
Refactor metrics to expose richer feature set Main user-facing interface is still Counter/GaugeService but the back end behind that has more options. The Default*Services write metrics to a MetricWriter and there are some variants of that, and also variants of MetricReader (basic read-only actions). MetricRepository is now a combination of MetricReader, MetricWriter and some more methods that make it a bit more repository like. There is also a MultiMetricReader and a MultiMetricRepository for the common case where metrics are stored in related (often open ended) groups. Examples would be complex metrics like histograms and "rich" metrics with averages and statistics attached (which are both closed) and "field counters" which count the occurrences of values of a particular named field or slot in an incoming message (e.g. counting Twitter hastags, open ended). In memory and redis implementations are provided for the repositories. Generally speaking the in memory repository should be used as a local buffer and then scheduled "exports" can be executed to copy metric values accross to a remote repository for aggregation. There is an Exporter interface to support this and a few implementations dealing with different strategies for storing the results (singly or grouped). Codahale metrics are also supported through the MetricWriter interface. Currently implemented through a naming convention (since Codahale has a fixed object model this makes sense): metrics beginning with "histogram" are Histograms, "timer" for Timers, "meter" for Meters etc. Support for message driven metric consumption and production are provided through a MetricWriterMessageHandler and a MessageChannelMetricWriter. No support yet for pagination in the repositories, or for HATEOAS style HTTP endpoints.
11 years ago
<artifactId>metrics-core</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>javax.cache</groupId>
<artifactId>cache-api</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>javax.jms</groupId>
<artifactId>javax.jms-api</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<optional>true</optional>
11 years ago
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-broker</artifactId>
<optional>true</optional>
<exclusions>
<exclusion>
<artifactId>geronimo-jms_1.1_spec</artifactId>
<groupId>org.apache.geronimo.specs</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-spring4-embedded</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-core</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-messaging</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-cassandra</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-couchbase</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-ldap</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-mongodb</artifactId>
<optional>true</optional>
</dependency>
Refactor metrics to expose richer feature set Main user-facing interface is still Counter/GaugeService but the back end behind that has more options. The Default*Services write metrics to a MetricWriter and there are some variants of that, and also variants of MetricReader (basic read-only actions). MetricRepository is now a combination of MetricReader, MetricWriter and some more methods that make it a bit more repository like. There is also a MultiMetricReader and a MultiMetricRepository for the common case where metrics are stored in related (often open ended) groups. Examples would be complex metrics like histograms and "rich" metrics with averages and statistics attached (which are both closed) and "field counters" which count the occurrences of values of a particular named field or slot in an incoming message (e.g. counting Twitter hastags, open ended). In memory and redis implementations are provided for the repositories. Generally speaking the in memory repository should be used as a local buffer and then scheduled "exports" can be executed to copy metric values accross to a remote repository for aggregation. There is an Exporter interface to support this and a few implementations dealing with different strategies for storing the results (singly or grouped). Codahale metrics are also supported through the MetricWriter interface. Currently implemented through a naming convention (since Codahale has a fixed object model this makes sense): metrics beginning with "histogram" are Histograms, "timer" for Timers, "meter" for Meters etc. Support for message driven metric consumption and production are provided through a MetricWriterMessageHandler and a MessageChannelMetricWriter. No support yet for pagination in the repositories, or for HATEOAS style HTTP endpoints.
11 years ago
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-neo4j</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
Refactor metrics to expose richer feature set Main user-facing interface is still Counter/GaugeService but the back end behind that has more options. The Default*Services write metrics to a MetricWriter and there are some variants of that, and also variants of MetricReader (basic read-only actions). MetricRepository is now a combination of MetricReader, MetricWriter and some more methods that make it a bit more repository like. There is also a MultiMetricReader and a MultiMetricRepository for the common case where metrics are stored in related (often open ended) groups. Examples would be complex metrics like histograms and "rich" metrics with averages and statistics attached (which are both closed) and "field counters" which count the occurrences of values of a particular named field or slot in an incoming message (e.g. counting Twitter hastags, open ended). In memory and redis implementations are provided for the repositories. Generally speaking the in memory repository should be used as a local buffer and then scheduled "exports" can be executed to copy metric values accross to a remote repository for aggregation. There is an Exporter interface to support this and a few implementations dealing with different strategies for storing the results (singly or grouped). Codahale metrics are also supported through the MetricWriter interface. Currently implemented through a naming convention (since Codahale has a fixed object model this makes sense): metrics beginning with "histogram" are Histograms, "timer" for Timers, "meter" for Meters etc. Support for message driven metric consumption and production are provided through a MetricWriterMessageHandler and a MessageChannelMetricWriter. No support yet for pagination in the repositories, or for HATEOAS style HTTP endpoints.
11 years ago
<artifactId>spring-data-redis</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-solr</artifactId>
<optional>true</optional>
<exclusions>
<!-- the version of solr here is incompatible with jackson-xml because of an old woodstox -->
<exclusion>
<artifactId>wstx-asl</artifactId>
<groupId>org.codehaus.woodstox</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-core</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-config</artifactId>
11 years ago
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-core</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-el</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.jolokia</groupId>
11 years ago
<artifactId>jolokia-core</artifactId>
<optional>true</optional>
11 years ago
</dependency>
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.amqp</groupId>
<artifactId>spring-rabbit</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-jdbc</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-dbcp2</artifactId>
<optional>true</optional>
</dependency>
<!-- Annotation processing -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-autoconfigure-processor</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
<optional>true</optional>
</dependency>
<!-- Test -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot</artifactId>
<type>test-jar</type>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-test-support</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-test</artifactId>
<type>test-jar</type>
<scope>test</scope>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.jayway.jsonpath</groupId>
<artifactId>json-path</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.undertow</groupId>
<artifactId>undertow-core</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.undertow</groupId>
<artifactId>undertow-servlet</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.jboss.spec.javax.servlet</groupId>
<artifactId>jboss-servlet-api_3.1_spec</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.skyscreamer</groupId>
<artifactId>jsonassert</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-elasticsearch</artifactId>
<scope>test</scope>
</dependency>
Simplify Jackson-related auto-configuration for HATEOAS and Data REST This commit simplifies the Jackson-related auto-configuration that’s applied when Spring HATEOAS and Spring Data REST are on the classpath. Previously, Boot used Jackson2HalModule to apply the HAL-related ObjectMapper configuration to the context’s primary ObjectMapper. This was to allow HAL-formatted responses to be sent for requests accepted application/json (see gh-2147). This had the unwanted side-effect of polluting the primary ObjectMapper with HAL-specific functionality. Furthermore, Jackson2HalModule is an internal of Spring HATEOAS that @olivergierke has asked us to avoid using. This commit replaces the use of Jackson2HalModule with a new approach. Now, the message converters of any RequestMappingHandlerAdapter beans are examined and any TypeConstrainedMappingJackson2HttpMessageConverter instances are modified to support application/json in addition to their default support for application/hal+json. This behaviour can be disabled by setting spring.hateoas.use-hal-as-default-json-media-type to false. This property is named after Spring Data REST’s configuration option which has the same effect when using Spring Data REST. The new property replaces the old spring.hateoas.apply-to-primary-object-mapper property. Previously, when Spring Data REST was on the classpath, JacksonAutoConfiguration would be switched off resulting in the context containing multiple ObjectMappers, none of which was primary. This commit configures RepositoryRestMvcAutoConfiguration to run after JacksonAutoConfiguration. This gives the latter a chance to create its primary ObjectMapper before the former adds its ObjectMapper beans to the context. Previously, the actuator’s hypermedia support assumed that the HttpMessageConverters bean would contain every HttpMessageConverter being used by Spring MVC. When Spring HATEOAS is on the classpath this isn’t the case as it post-processes RequestMappingHandlerAdapter beans and adds a TypeConstrainedMappingJackson2HttpMessageConverter to them. This wasn’t a problem in the past as the primary ObjectMapper, used by a vanilla MappingJackson2HttpMessageConverter, was configured with Spring HATEOAS’sJackson2HalModule. Now that this pollution has been tidied up the assumption described above no longer holds true. MvcEndpointAdvice, which adds links to the actuator’s json responses, has been updated to look at the HttpMessageConverters of every RequestMappingHandlerAdapter when it’s trying to find a converter to use to write a response with additional hypermedia links. Integration tests have been added to spring-boot-actuator to ensure that the changes described above have not regressed the ability to configure its json output using spring.jackson.* properties (see gh-1729). Closes gh-3891
9 years ago
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-rest-webmvc</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-jmx</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.yaml</groupId>
<artifactId>snakeyaml</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</project>