Как избежать конфликта с пружинной валидацией, которая помещается в разные модули? - PullRequest
0 голосов
/ 13 февраля 2019

Допустим, я определил некоторый bean-компонент, подобный этому:

@Component
@Validated
public class MyComponent {
    public void someMethod(@NotNull Integer myIntValue) {
        System.out.println(myIntValue);
    }
}

Это упаковано в некоторый jar-файл, например: com.comppany:component:1.0.jar

Этот jar-файл должен зависеть (include?) from:

  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
    <version>2.1.0.RELEASE</version>
  </dependency>
  <dependency>
    <groupId>javax.validation</groupId>
    <artifactId>validation-api</artifactId>
    <version>2.0.1.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>6.0.13.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator-annotation-processor</artifactId>
    <version>6.0.13.Final</version>
  </dependency>

Вопрос заключается в следующем: что, если этот jar-файл будет добавлен в качестве зависимости к другому проекту, в котором есть другая реализация валидации JSR-303 (например, валидатор Commons из apache)?Есть ли способ защититься от этой ситуации?1. Использовать одну проверку для модуля «компонент», а другую для другого?2. или может быть проверено во время компиляции (как?), Что цель, которая импортирует «компонентный» модуль, имеет такую ​​же проверку JSR-303?

1 Ответ

0 голосов
/ 13 февраля 2019

Я видел optional, используемый для этого.Вы сможете собрать библиотеку с указанным валидатором Hibernate.Клиенты, использующие вашу библиотеку, будут либо явно указывать зависимость валидатора Hibernate, либо библиотеку валидатора, совместимую с JSR-303, по своему выбору.

Это предполагает, что в аннотации @Validated явно не упоминается пакет 'hibernate' воператор import и использует вместо этого API.

Это может привести к тому, что приложение не будет собираться, если не указана зависимость, но это может быть нормально, поскольку это сделает клиента явным с выбором зависимости.

Этот SO ответ дает дополнительную информацию, а вот документация Maven .

Альтернатива - оставить то, что у вас есть, и если кто-то захочетчтобы использовать другую библиотеку, они исключают зависимость Hibernate из зависимости от этой библиотеки и добавляют свою собственную.Это хорошо, если клиент просто хочет, чтобы приложение работало, не задумываясь о том, какую зависимость JSR-303 использовать.

Выбор зависит от того, как вы ожидаете, что люди будут использовать эту библиотеку.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...