2016-06-19 5 views
0

Из-за ограничений рамки, которую я должен использовать, мне нужно вводить в существующие экземпляры объектов (они не могут быть созданы как обычно с помощью самого CDI) , Мои точки инъекции отмечены либо @EJB, либо @Inject.CDI Injection в существующий экземпляр объекта - работал с CDI 1.0, но не с CDI 1.1

С JBoss EAP 6.4, Java EE 6 и CDI 1.0 это работало прекрасно со следующим кодом:

public class DispatcherUtils { 

    public static <T> void inject(T anObject) { 
     BeanManager beanManager = getBeanManager(); 
     Class<T> objClass = (Class<T>) anObject.getClass(); 
     AnnotatedType<T> annotatedType = beanManager.createAnnotatedType(objClass); 
     InjectionTarget<T> injectionTarget = beanManager.createInjectionTarget(annotatedType); 
     CreationalContext<T> context = new IgnorantCreationalContext<>(); 
     injectionTarget.inject(anObject, context); 
     injectionTarget.postConstruct(anObject); 
    } 

    private static BeanManager getBeanManager() { 
     try { 
      return (BeanManager) InitialContext.doLookup("java:comp/BeanManager"); 
     } catch (final NamingException e) { 
      e.printStackTrace(); 
     } 
     return null; 
    } 

} 

Если я пытаюсь сделать то же самое в JBoss EAP 7.0, Java EE 7 и CDI 1.1 только точки инъекции, помеченные @Inject, вводятся в целевые объекты, те, которые помечены @EJB, не вводятся (их значение остается равным нулю).

Я не понимаю, почему это так.

Есть ли способ впрыскивания в существующие объекты с JBoss EAP 7.0, Java EE 7 и CDI 1.1, а также для заполнения точек впрыска @EJB?


Update, 2016-06-19, 20:11

Я только что обнаружил, что вышеуказанная модель работает до тех пор, как объект, я хочу, чтобы ввести в имеет конструктор без аргументов.

Пример - это работает:

public class ExampleBean { 

    private Dispatcher dispatcher; 

    @Inject 
    private SomeCdiBean someCdiBean; 

    @EJB 
    private SomeEjbService someEjbService; 

    public ExampleBean() { 
    } 

    public ExampleBean(Dispatcher dispatcher) { 
     this.dispatcher = dispatcher; 
    } 

} 

а в этом не работает:

public class ExampleBean { 

    private Dispatcher dispatcher; 

    @Inject 
    private SomeCdiBean someCdiBean; 

    @EJB 
    private SomeEjbService someEjbService; 

    public ExampleBean(Dispatcher dispatcher) { 
     this.dispatcher = dispatcher; 
    } 

} 

Почему проверка CDI наличие конструктора по умолчанию в таком случае? (Примечание: фасоль не создан КДИ, поэтому конструктор не имеет никакого значения)

+0

Как выглядит ваш «IgnorantCreationContext»? DeltaSpike имеет ту же функцию, и отлично работает на Wildfly 10: https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/ api/provider/BeanProvider.java # L448, возможно, вы бы подумали об этом? –

+0

Это мой «IgnorantCreationContext» https://gist.github.com/t3chris/36d627528b5d059a272afd4ed8ccd148 Я также пробовал с Deltaspike, но видел тот же результат '@ Inject', но' @ EJB' остается с нулевым значением , – t3chris

+0

@JohnAment: Я обновил свой первоначальный вопрос. Вы видите какой-либо способ заставить CDI игнорировать отсутствие конструктора по умолчанию? – t3chris

ответ

0

Возможная проблема может быть, что ваш ExampleBeanбез нет-арг конструктор не не считается managed bean. И интегратор (Wildfly, EAP, glassfish, ...) может только обеспечить впрыск ресурсов EE (@EJB, являющийся введением EE ресурсов) в managed beans.

Weld doc Цитируя:

Интегратор может пожелать использовать InjectionServices, чтобы обеспечить дополнительное поле или метод инъекции чрезмерного и выше, при условии, что с помощью сварного шва. Интеграция в среду Java EE может использовать InjectionServices для обеспечения внедрения EE-ресурсов для управляемых компонентов.

Чтобы ExampleBeanmanaged bean и не использовать не-арг конструктор, необходимо объявить конструктор с аннотацией @Inject.

Хотя я просто беру на себя дикую догадку и не могу быть уверен, почему вы говорите, что это сработало с EAP 6 и CDI 1.0.

И еще одно примечание только для записи - по моим сведениям, EAP 7 содержит CDI 1.2 (а не 1.1).

+0

Что вы говорите относительно ExampleBean, что это не управляемый компонент, я полностью согласен. Однако до сих пор мы привыкли просто так, потому что это сработало нормально. Теперь я хотел бы найти решение, которое позволяет нам сообщить движку CDI, что это нормально для ввода в экземпляр, который не выглядит как управляемый компонент (как это было в EAP 6.x). Там не должно быть никаких проблем, так как мы создали этот компонент заранее. Что касается CDI 1.2, вы, конечно, правы, моя вина. – t3chris