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

Question

В классе JersyConfiguration я получаю серьезные проблемы с инструментом сонара, такие как Удалите этот вызов из конструктора в переопределяемый метод «register» . Я действительно не понимаю, с помощью какого изменения кода можно решить эту проблему. Это мой код:

JerseyConfiguration

public class JerseyConfiguration extends ResourceConfig {

    @Bean
    @Primary
    public ObjectMapper objectMapper() {
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
        objectMapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
        objectMapper.enable(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES);
        objectMapper.enable(DeserializationFeature.READ_ENUMS_USING_TO_STRING);
        return objectMapper;
    }



    @Autowired
    public JerseyConfiguration() {
        register(TermsResourceImpl.class);
        register(AccessIDResourceImpl.class);
        register(CatalogResourceImpl.class);
        register(SubmitOrderResourceImpl.class);
        register(ValidateAndQuoteResourceImp.class);
        property(ServletProperties.FILTER_FORWARD_ON_404, true);
        register(DynamicLoggingFeature.class);
        register(ContextFilter.class);
        register(ServiceExceptionMapper.class);
        register(JsonParseExceptionMapper.class, 1);
        register(JsonMappingExceptionMapper.class, 1);
        register(LoggingContextJerseyFilter.class);
        register(FeatureToggleFilterBinder.class);
    }

    @Bean
    public Client jerseyClient() {
        return ClientBuilder.newClient(new ClientConfig());
    }
}

методы переопределения ResourceConfig

 @Override
 public ResourceConfig property(final String name, final Object value) {
     state.property(name, value);
     return this;
 }

 @Override
 public ResourceConfig register(final Class<?> componentClass) {
     invalidateCache();
     state.register(componentClass);
     return this;
 }

Проблема с SonarQube

Answer 1

Это не ложное срабатывание, потому что правило работает правильно. Вы вызываете метод в конструкторе, который можно изменить в подклассах. Эта структура могла вызвать проблемы. Пример:

public class BrokenCode extends JerseyConfiguration {

    @Override
    public ResourceConfig register(final Class<?> componentClass) {
        // stop invaliding cache, to break the application
        // invalidateCache();

        state.register(componentClass);
        return this;
    }
}

---

Для решения проблемы метод должен быть помечен как final. Я не знаю Джерси, поэтому у вас есть следующий вариант:

1. если создание методов как final невозможно

В некоторых случаях добавление final может нарушить работу приложения, потому что, например, прокси-серверы Dynami c создаются используемым фреймворком. В таких случаях вы можете пометить проблему только как Won't Fix (он сообщает другим разработчикам, что указанная структура не соответствует правилу, но вас это устраивает)

2. если возможно создание методов как final

Есть два варианта, в зависимости от того, какие классы вы можете редактировать:

1. если вы можете редактировать класс ResourceConfig, то измените:

@Override
public ResourceConfig register(final Class<?> componentClass) {
    invalidateCache();
    state.register(componentClass);
    return this;
}

до

@Override
public final ResourceConfig register(final Class<?> componentClass) {
    invalidateCache();
    state.register(componentClass);
    return this;
}

Если invalidateCache не private, то вы также должны отметить его как final.

если вы не можете редактировать класс ResourceConfig, тогда вы можете добавить к классу JerseyConfiguration следующий метод:

@Override
public final ResourceConfig register(final Class<?> componentClass) {
    super.register(componentClass)
}

Конечно, если invalidateCache не private тогда вы также должны добавить его:

@Override
public final void invalidateCache() {
    super.invalidateCache()
}

---

Выбранная стратегия «исправления» должна также основываться на:

• руководящих принципах используемой структуры (Джерси)
• , который может расширить JerseyConfiguration конфигурацию
• et c.

Я думаю, что это нормально, закрыть его как Won't Fix также, когда приложение:

• использует структуры из используемой документации фреймворка
• разрабатывается / поддерживается только вашей командой (никто другой не создает вручную новые экземпляры класса JerseyConfiguration)