Хорошо, поэтому у меня есть поддержка JSF bean, для которой нужна ссылка на другую (@NoneScoped) bean.
Должен ли я вставить его или использовать @ManagedProperty для получения ссылки на экземпляр из контейнера?
Зачем использовать один, а не другой, на мой взгляд, оба подхода достигают одного и того же.
@ManagedProperty и @NoneScoped поступает из спецификации JSF 2.0, а @Inject - из спецификации CDI.
Если вы просто работаете над сервлет-приложением, которое не использует каких-либо других функций JavaEE 6, перейдите к @ManagedProperty. Эта аннотация также имеет преимущество против @Inject: вы можете использовать с ним EL (язык выражений) (хотя есть обходные пути, чтобы получить это в CDI).
Оба аннотации/контейнеры, похоже, достигают "того же", но совершенно по-разному, и они работают с разными контейнерами. Beans, управляемый CDI, будет доступен JSF, но не наоборот. Если вы аннотируете свой Beans с помощью специальных аннотаций JSF, забудьте об использовании специальных квалификаторов, перехватчиков, методов создания и т.д. Я обычно предпочитаю подход с CDI, потому что в конце он более сложный, но выбор будет зависеть от вашего фактические потребности.
Оберните его, так как кажется, что вы просто используете JSF-функции, а затем придерживайтесь @ManagedProperty (CDI не может понять аннотации @NoneScoped, в CDI все Beans находятся под область @Default, если она не указана). Переход на CDI в вашем проекте может означать замену не только @ManagedProperty для @Inject, но и всех ваших @RequestScoped (и т.д.) Для CDI-специфичных.
Я бы предпочел CDI по сравнению с управляемым beans, когда это было возможно. CDI богаче проверкой зависимостей времени развертывания, а его поддержка прокси предотвращает утечку области. Это упрощает проверку правильности вашей модели. Производители обычно могут использоваться для предоставления кода клея, где это необходимо.