Как бороться с весенними бобами (маршаллерами) в абстрактном классе конфигурации? - PullRequest
0 голосов
/ 31 августа 2018

Я устанавливаю подключения к сервисам Soap другого приложения в нашей компании. Существует несколько мыльных сервисов, каждый из которых имеет свои собственные wsdl / xsd, но также имеет много общих объектов схемы.

При создании первого соединения я настроил класс Client:

public Service1Client extends WebServiceGatewaySupport{
  (unrelated internal code)
}

Который создается в виде компонента в классе Configuration со следующей настройкой:

@Configuration
public class Service1Configuration{
  private static final String COMMON_PACKAGE = "uninportant";
  private static final String HEADER_PACKAGE = "uninportant";
  private static final String SERVICE_PACKAGE = "uninportant";

  @Bean
  Jaxb2Marshaller marshaller(){
    Jaxb2Marshaller marshaller = new Jaxb2Marshaller();
    marshaller.setContextPaths(COMMON_PACKAGE, HEADER_PACKAGE, SERVICE_PACKAGE);
    return marshaller;
  }

  @Bean
  public ServiceV1Client(Jaxb2Marshaller marshaller, WebServiceMessageSender messageSender){
    (unrelated code setting marshaller, messageSender and some properties)
  }

  @Bean
  public WebServiceMessageSender messageSender() throws etc... {
    (unrelated code)
    return new HttpComponentsMessageSender(blabla);
  }
}

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

Это один из первых случаев, когда я углубляюсь в bean-компоненты и абстрактные классы, когда мне трудно обдумывать то, чем я заканчиваю.

Вопрос 1: Должны ли оба класса конфигурации Abstract и все реализованные классы конфигурации получать теги @Configuration? или только реализованные классы?

Вопрос 2: Я застрял у Маршаллера, а точнее с: marshaller.setContextPaths(input)

Что было бы за / против создания маршаллера, содержащего contextPaths всех Сервисов, по сравнению только с их собственным сервисом?

Вопрос 3: Тогда с точки зрения реализации. Если я создаю маршаллер в абстрактном классе Configuration с аннотацией @Bean, все реализации AbstractConfiguration содержат точно такой же экземпляр маршаллера.

Другими словами, я настроил абстрактный класс так:

@Configuration
public abstract class AbstractConfiguration{
  private static final String COMMON_PACKAGE = "uninportant";
  private static final String HEADER_PACKAGE = "uninportant";

  @Bean
  Jaxb2Marshaller marshaller(){
    Jaxb2Marshaller marshaller = new Jaxb2Marshaller();
    marshaller.setContextPaths(COMMON_PACKAGE, HEADER_PACKAGE, getServiceContextPath());
    return marshaller;
  }
  protected abstract String getServiceContextPath();
}

Каждая реализация клиента / конфигурации будет иметь контекстный путь первой созданной реализации.

Если лучший путь - это реализовать его таким образом, чтобы каждый маршаллер содержал только контекст своего собственного сервиса: каков был бы лучший способ добиться этого, при этом все еще перемещая определение компонента в абстрактный класс?

...