Бин с тем же именем в проблеме конфликта нескольких зависимостей - PullRequest
Новая
       20

Бин с тем же именем в проблеме конфликта нескольких зависимостей

0 голосов
/ 10 мая 2019

Новинка для весенней загрузки.

У нас есть многократно используемые bean-компоненты в нескольких базовых зависимостях.Поскольку нам нужны эти повторно используемые функции, мы наследуем эти jar-файлы в pom.xml.

Пример:

Jar1:

ClassName: UserInfo, RequestInterceptors, ClassName3, ClassName4, ClassNameN.PackageName: com.somename1.base.comps

Jar2:

ClassName: UserInfo, RequestInterceptors, ClassName3, ClassName4, ClassNameN.PackageName: com.somename2.base.comps

Поскольку имя класса схоже, возникает проблема конфликта при сборке.

К сожалению, мы не можем изменить имена классов, так как некоторые другие командыиспользуя эти банкиНет разрешения на создание другой версии этих банок.

Есть ли способ включить оба jar без исключения этих конфликтующих компонентов в аннотации @EnableAutoConfiguration или @ComponentScan?

Может кто-нибудь поделиться здесь некоторыми советами.

1 Ответ

0 голосов
/ 10 мая 2019

Решением здесь было бы назвать ваши бобы. Причиной конфликта может быть то, что имена классов совпадают. Например: 

@Configuration
public class Config{

  public com.somename2.base.comps.UserInfo somename2UserInfo(){
    return new com.somename2.base.comps.UserInfo();
  }
  public com.somename1.base.comps.UserInfo somename1UserInfo(){
    return new com.somename1.base.comps.UserInfo();
  }

}

В этом случае бины будут именоваться somename1UserInfo и somename2UserInfo, и вы можете использовать эти имена вместо этого при автопроводке, например ::

public class SomeImpl{

  @Autowired
  @Qualifier("somename1UserInfo")
  UserInfo userInfo;

  /*
   * Or you can do this
   */
  @Resource(name = "somename1UserInfo")
  UserInfo theSameUserInfo

}

Это позволит вам автоматически связывать любой боб, который будет использоваться в любом классе. Возможно, не было бы идеальным объявлять спецификатор для каждого места, где используются классы, поэтому, если в основном используется одна реализация, рассмотрите аннотацию @Primary.

...