Почему я должен использовать guice-hk2-bridge?

Question

Я извиняюсь за глупый вопрос, но я действительно искал ответ на этот вопрос и не получил однозначного ответа.

Я знаю, что джерси использует hk2 в качестве DI по умолчанию, и поскольку hk2- это потеря производительности, альтернативный DI - это Guice, что лучше, нам нужно настроить джерси для использования Guice с использованием guice-hk2-bridge.

Вопрос в том, ПОЧЕМУ? Почему мы должны настроить Джерси? Почему мы не можем просто использовать? com.google.inject.Inject вместо javax.inject.Inject, используя Guice, импортируя только com.google.inject пакет?

Что такого важного в этом мосту?, я пытался работать без guice-hk2-bridge, и он отлично работал для меня... Я уверен, что есть кое-что, что я неправильно понял..

Спасибо

Answer 1

Я не уверен, сколько у вас опыта программирования с аннотациями, но просто хочу сказать, что за ними нет магии. Это просто метаданные, и решать, что делать с этими метаданными, зависит от структуры. Для вас, чтобы сказать "почему мы не можем переключиться javax.inject.Inject за com.google.inject.Inject и заставить Guice работать?"показывает отсутствие понимания этой концепции.

Любая структура DI построена вокруг контейнера для хранения всех служб, связанных с этой системой. Для HK2 контейнер является ServiceLocator для весны контейнер является ApplicationContext и для Guice контейнер является Injector, При этом Джерси тесно связан с HK2 ¹. Это означает, что HK2 привязан к ServiceLocator контейнер, Джерси также привязан к этому ServiceLocator, Поэтому, когда служба просматривается в приложении на Джерси, она просматривается через ServiceLocator, Возьмите для примера следующее

@Path("customers")
public class CustomerResource {
    @Inject
    private CustomerService service;

    @GET
    public List<Customer> findAll() {
        return service.findAll();
    }
}

С учетом вышесказанного, где-то под капотом, следующее (в псевдокоде) происходит, чтобы получить CustomerService вводить в CustomerResource

ServiceLocator locator = getServiceLocator();
CustomerService service = locator.getService(CustomerService.class);

Когда у нас есть Джерси, создайте (управляйте жизненным циклом) ресурс (CustomerResource), даже ресурс является услугой, связанной с ServiceLocator, Это то, что я имею в виду, что все в Джерси тесно связано с HK2 и ServiceLocator,

Таким образом, чтобы мы могли представить другую структуру DI, нам нужно задействовать ServiceLocator, Что делает мост, так это привязывает Guice Injector к HK2 ServiceLocator так что сервисы в Guice Injector может быть обнаружен через ServiceLocator, Если CustomerService была служба связана с Guice Injector то, что случилось бы, это то, что Джерси будет искать его в ServiceLocator и локатор посмотрел бы в Injector для этого. Это то, что делает мост.

---

_{1. Начиная с версии 2.26, Джерси фактически разрывает связи с HK2, будучи тесно связанным. Это сложно объяснить, но вкратце, нам все еще нужно использовать HK2 с Джерси, даже если они больше не связаны друг с другом.}