Common classes used in different Spring Cloud implementations
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

187 lines
5.5 KiB

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://maven.apache.org/POM/4.0.0"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-commons-parent</artifactId>
2 years ago
<version>4.0.1-SNAPSHOT</version>
<relativePath>..</relativePath>
</parent>
<artifactId>spring-cloud-commons</artifactId>
<packaging>jar</packaging>
<name>Spring Cloud Commons</name>
<description>Spring Cloud Commons</description>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<phase>test-compile</phase>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
<configuration>
<excludes>
<exclude>**/*.properties</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.-->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<versionRange>[3.0.0,)</versionRange>
<goals>
<goal>test-jar</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
<properties>
<evictor.version>1.0.0</evictor.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-webflux</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-crypto</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-rsa</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.integration</groupId>
<artifactId>spring-integration-jmx</artifactId>
<optional>true</optional>
</dependency>
Added hypermedia support in the form of a RemoteResource abstraction. This commit introduces support to easily discover resources in remote service APIs and periodically validating they're still available. The core concept is a RemoteResource and its primary implementation DiscoveredResource which consists of a ServiceInstanceProvider and a TraversalDescription. The service instance provider abstracts the location of the service the DiscoveredResource is hosted at. Currently there are two implementations available: a StaticServiceInstanceProvider that — as the name suggests — returns a statically configured instance, as well as the DynamicServiceInstanceProvider which takes a DiscoveryClient and service name as input to dynamically discover the ServiceInstance on request. The TraversalDefinition is a SAM type that allows to define the path traversals that shall be executed to discover the target resource within the service instance. This allows the following configuration: DiscoveryClient client = … ServiceInstanceProvider provider = new DynamicServiceInstanceProvider(client, "stores"); RemoteResource resource = new DiscoveredResource(provider, traverson -> traverson.follow("stores", "search", "by-location"); This will cause the following to happen: 1. In this default state the resource is undiscovered and calls to getLink() will return null. 2. A call to verifyOrDiscover() will trigger resource discovery, i.e. lookup the service instance using the discovery client, execute the path traversal as defined and store the final link discovered ("by-location") in the discovered resource. 3. Calls to getLink() will return that link. Calls to verifyOrDiscover() will issue a HEAD request to verify the resource is still available and reset the link if not. Subsequent calls to verifyOrDiscover() will trigger rediscovery. That means that we basically shield against either the service instance becoming unavailable or the resource becoming unavailable within the service instance (due to some URI restructuring or the like). The calls to verifyOrDiscover() are currently automated by a RemoteResourceRefresher which is auto-configured if a RemoteResource is declared as Spring bean and its initial and fixed delay can be configured via properties in the spring.cloud.hypermedia namespace.
9 years ago
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-hateoas</artifactId>
<optional>true</optional>
</dependency>
<!--<dependency>
<groupId>org.springframework.security.oauth.boot</groupId>
<artifactId>spring-security-oauth2-autoconfigure</artifactId>
<optional>true</optional>
<exclusions>
<exclusion>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.activation</groupId>
<artifactId>jakarta.activation</artifactId>
</exclusion>
<exclusion>
<groupId>javax.activation</groupId>
<artifactId>javax.activation-api</artifactId>
</exclusion>
</exclusions>
</dependency>-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-autoconfigure-processor</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
<optional>true</optional>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
<exclusion>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
</exclusion>
</exclusions>
</dependency>
Added hypermedia support in the form of a RemoteResource abstraction. This commit introduces support to easily discover resources in remote service APIs and periodically validating they're still available. The core concept is a RemoteResource and its primary implementation DiscoveredResource which consists of a ServiceInstanceProvider and a TraversalDescription. The service instance provider abstracts the location of the service the DiscoveredResource is hosted at. Currently there are two implementations available: a StaticServiceInstanceProvider that — as the name suggests — returns a statically configured instance, as well as the DynamicServiceInstanceProvider which takes a DiscoveryClient and service name as input to dynamically discover the ServiceInstance on request. The TraversalDefinition is a SAM type that allows to define the path traversals that shall be executed to discover the target resource within the service instance. This allows the following configuration: DiscoveryClient client = … ServiceInstanceProvider provider = new DynamicServiceInstanceProvider(client, "stores"); RemoteResource resource = new DiscoveredResource(provider, traverson -> traverson.follow("stores", "search", "by-location"); This will cause the following to happen: 1. In this default state the resource is undiscovered and calls to getLink() will return null. 2. A call to verifyOrDiscover() will trigger resource discovery, i.e. lookup the service instance using the discovery client, execute the path traversal as defined and store the final link discovered ("by-location") in the discovered resource. 3. Calls to getLink() will return that link. Calls to verifyOrDiscover() will issue a HEAD request to verify the resource is still available and reset the link if not. Subsequent calls to verifyOrDiscover() will trigger rediscovery. That means that we basically shield against either the service instance becoming unavailable or the resource becoming unavailable within the service instance (due to some URI restructuring or the like). The calls to verifyOrDiscover() are currently automated by a RemoteResourceRefresher which is auto-configured if a RemoteResource is declared as Spring bean and its initial and fixed delay can be configured via properties in the spring.cloud.hypermedia namespace.
9 years ago
<dependency>
<groupId>com.jayway.jsonpath</groupId>
<artifactId>json-path</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents.client5</groupId>
<artifactId>httpclient5</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-test-support</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.projectreactor</groupId>
<artifactId>reactor-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-observation-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</project>