Несмотря на то, что вы решили свою проблему самостоятельно и в некотором роде разбирались в ее сути, я хотел бы представить здесь более подробную информацию (для заинтересованных читателей), а также дать некоторые рекомендации.
Давайте начнем с самого начала:
Во-первых, зависимости вашего приложения, как показано в POM Maven выше, очень запутаны!
Вы объявляете прямые «версионные» зависимости от Spring Data GemFire (то есть org.springframework.data:spring-data-gemfire:2.2.1.RELEASE) вместе с Spring Data Geode (то есть org.springframework.data:spring-data-geode:2.2.6.RELEASE, что делает не совпадает; SD GemFire 2.2.1! = SD Geode 2.2.6) вместе с Spring Boot для Apache Geode & Pivotal GemFire (SBDG) (org.springframework.geode:spring-geode-starter:1.2.6.RELEASE), а затем без необходимости извлекают SBDG * Модуль 1016 * (ядро), который все равно будет транзитивно втянут spring-geode-starter, а также объявит модуль org.apache.geode:geode-core, фу! :)
Единственная зависимость, которую вам нужно объявить в этом случае, это 1 из стартеров SBDG, либо org.springframework.geode:spring-geode-starter при использовании Apache Geode или org.springframework.geode:spring-gemfire-starter при использовании Pivotal GemFire, либо, альтернативно, при развертывании * 1023 Приложение * Spring Boot для PCF с использованием P CC (в этом случае рекомендуется зависимость spring-gemfire-starter, хотя это и не является абсолютно необходимым, так как возможно смешивать одноранговые узлы GemFire / Geode и иметь клиентов Geode для связи с серверами GemFire или наоборот).
Стартер втягивает Spring Data Geode (или Spring Data GemFire , в зависимости от Starter ), который тянет в Geode (или GemFire) биты для вас. В этом и заключается смысл управления зависимостями Maven / Gradle, и лучше свести к минимуму объявления зависимостей вашего приложения, насколько это возможно, и просто позволить фреймворку / стартеру самим определять версии переходных зависимостей, особенно если вы не t забота.
Проект Spring Boot в целом идет на все, чтобы курировать и согласовать все версии зависимостей (обе Spring и 3-ий) party libs / переходные зависимости включены) для вас. Вам нужно только выбрать версию Spring Boot на основе версий зависимостей приложения (например, Apache Geode или Pivotal GemFire), которые вам требуются.
Мы пытаемся обобщить эти для вас здесь:
https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix
В частности, см .:
https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix#version - матрица совместимости
Чтобы быть очень прозрачным, эта матрица / таблица совместимости версий примерно переводится в:
- Как разработчик, я использую или выбираю использовать SBDG
1.2.6.RELEASE. - SBDG
1.2.6.RELEASE - на основе Пружинный ботинок 2.2.6.RELEASE. - Пружинный ботинок
2.2.6.RELEASE вытягивает Данные пружины Moore-SR6. - Данные пружины
Moore-SR6 ( this ) включает Spring Data GemFire / Geode 2.2.6.RELEASE. - Spring Data Geode (SDG)
Moore-SR6/2.2.6.RELEASE равен на основе Apache Geode 1.9.x. - Spring Data GemFire (SDG)
Moore-SR6/2.2.6.RELEASE is на основе Pivotal GemFire 9.8.x. - Spring Data Geode включает необходимое (по SDG) и правильное Apache Биты Geode (зависимости).
- Spring Data GemFire включает обязательные (для SDG) и корректные Pivotal GemFire биты (зависимости).
Поэтому возникает вопрос, какую версию SBDG (т.е. какую spring-[geode|gemfire]-starter версию) вам нужно использовать с P CC в PCF?
Для этого вам необходимо иметь общее понимание что клиенты GemFire / Geode могут подключаться и взаимодействовать с серверами GemFire / Geode только той же версии, что и клиент, или более поздней версии. Более новый клиент НЕ МОЖЕТ общаться со старым сервером GemFire / Geode. Это не ограничение Spring, а само ограничение GemFire / Geode. Есть много факторов, почему это так, и я не буду объяснять это здесь (но это примерно сводится к протоколам, распределенным алгоритмам и остальным).
Например, вы можете подключить клиент GemFire 9.8 к серверу GemFire 9.8.x, и все будет хорошо. Тот же самый клиент GemFire 9.8 также может подключаться к серверам GeFire 9.9.x и 9.10.x и общаться с ними. Однако клиент GemFire 9.8 не может подключиться или общаться с сервером GemFire 9.7, 9.6, 9.5 или более ранней версии. Версии исправления или обслуживания не имеют значения AFAIR, то есть клиент GemFire 9.8.7 должен иметь возможность подключаться и взаимодействовать с сервером GemFire 9.8.4, например, при условии совпадения версий major.minor.
Итак, теперь все сводится к тому, какая версия Pivotal GemFire является версией P CC в PCF, на которой вы развертываете приложение Spring Boot ( Data Geode ) для на основе?
Для этого вам нужно обратиться к документации PCF / P CC.
Например, P CC для PCF (теперь известной как VMware Tanzue GemFire для виртуальных машин). ) версия 1.11 основана на Pivotal GemFire 9.9.1. См. здесь .
Это означает, что вы можете использовать SBDG 1.2.6.RELEASE, основанный на Spring Boot 2.2.6.RELEASE, который извлекает Spring Data Moore-SR6, который включает SDG 2.2.6.RELEASE, который основан на Apache Geode 1.9.2 / Pivotal GemFire 9.8.7. Эта комбинация хороша, потому что более старый клиент (т.е. GemFire 9.8.7) может подключаться и общаться с GemFire 9.9.1, который является базовым для PCC / VMware Tanzu GemFire для VMS 1.11.
Имеет смысл ?
Если мы посмотрим на P CC 1.10, снова это на основе Pivotal GemFire 9.9.1.
Если мы посмотрим на P CC 1.9, на основе Pivotal GemFire 9.8.6. Опять же, мы в порядке.
Если мы go вернемся к P CC 1.7, мы увидим, что P CC 1.7 был на основе Pivotal GemFire 9.7.2.
Теперь SBDG 1.2.6.RELEASE НЕ будет работать с P CC 1.7, поскольку SBDG 1.2.6.RELEASE основан на GemFire 9.8 (новее), а P CC 1.7 основан на GemFire 9.7 (старше). Клиент 9.8 не может подключиться и общаться с сервером 9.7, поэтому мы должны go вернуть версию SBDG major.minor в SBDG 1.1.x, где SBDG 1.1.x основан на Spring Boot 2.1, который получает Spring Data Lovelace/2.1, который включает SDG 2.1.x, который основан на Apache Geode 1.6 и Pivotal GemFire 9.5, соответственно.
ПРИМЕЧАНИЕ: хотя SDG «совместим» с более новыми, «базовыми» версиями GemFire / Geode, мы не «поддерживаем» комбинацию. Например, SDG Lovelace / 2.1 «основан» только на GemFire 9.5 / Geode 1.6, но «совместим» с GemFire 9.6 / 9.7 и Geode 1.7 / 1.8. Если вы выйдете за пределы GemFire 9.7, например, с 9.8 и с Geode 1.8 до 1.9, то, конечно, вам следует перейти на SDG Moore / 2.2, поскольку он «основан» на GemFire 9.8 / Geode 1.9. Совместимость! = Поддержка. В любом случае, это означает, что вы можете обновить версию своего клиентского драйвера (например, версию клиента GemFire / Geode, если необходимо). Смотрите здесь для более подробной информации. Эта вики-страница является WIP.
Веб-сайт Cloud Cache Developer также содержит сведения, которые помогут вам начать работу.
Наконец, я также создал эту * 1203 Образец * Getting Started (с Guide и Исходный код ) в самом проекте SBDG, который быстро запускается и запускается с запуска start. spring.io .
Теперь о вашей конфигурации ...
@Configuration
@ClientCacheApplication(name = "Test", logLevel = "info")
@EnableCachingDefinedRegions(
clientRegionShortcut = ClientRegionShortcut.PROXY,
serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU)
@EnableClusterAware
@EnablePdx
public class CloudConfiguration {}
Это можно упростить до:
@Configuration
@EnableCachingDefinedRegions(
serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU
)
@EnableClusterAware
public class CloudConfiguration {}
SBDG " по умолчанию автоматически настраивает"экземпляр ClientCache для вас. См. здесь .
На самом деле, вы должны быть осторожны при явном объявлении аннотаций, поскольку тогда вы переопределяете автоконфигурацию (т.е. вы переопределяете " соглашение"путем применения явной" конфигурации", которая сообщает Boot , что вы знаете, что делаете; убедитесь, что это действительно так!) См. здесь и здесь и здесь и здесь и здесь .
Многие атрибуты аннотации ( например ClientCacheApplication.name или ClientCacheApplication.logLevel) можно выразить как свойства SDG в файле Spring Boot applications.properties, что делает конфигурацию более «настраиваемой».
Например:
# Spring Boot application.properties.
spring.data.gemfire.name=Test
spring.data.gmefire.cache.log-level=INFO
См. здесь и здесь для получения более подробной информации.
Вам также не нужно явно включать PDX, так как снова SBDG автоконфигурируется PDX для вас. См. здесь .
По умолчанию ClientRegionShortcut - ПРОКСИ, хотя я тоже не возражаю против "откровенности" по этому поводу. Вам просто нужно быть осторожным в контексте Spring Boot с автоконфигурацией , поскольку вы можете "переопределить" автоконфигурацию и взять на себя ответственность за управление Конфигурация правильно на себя. Поэтому объявляйте конфигурацию намеренно, а не вслепую.
Надеюсь, это поможет!