2015-04-22 5 views
4

я могу привнести свой собственный POJO в управляемый объект, как это:Может ли CDI вводить стандартную библиотеку POJO в EJB?

import javax.ejb.Stateless; 
import javax.inject.Inject; 
@Stateless 
public class SomeEjb { 
    @Inject 
    private SomePojo somePojo; 
} 

И я это POJO:

// No annotations 
public class SomePojo { 
} 

Это прекрасно работает. Если я вложу EJB в резервную копию JSF, я вижу, что значение somePojo является ненулевым значением, как и ожидалось.

Однако, если я пытаюсь впрыснуть java.util.Date в SomeEjb, я получаю следующее исключение по развертыванию:

Severe: Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [Date] with qualifiers [@Default] at injection point [[field] @Inject private SomeEjb.date] 
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Date] with qualifiers [@Default] at injection point [[field] @Inject private SomeEjb.date] 
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311) 

SomeEjb сейчас:

// No annotations 
public class SomeEjb { 
    @Inject 
    private Date date;  
} 

Дата имеет общественности, конструктор без аргументов , и я подумал, что для всех CDI необходимо «удовлетворить зависимость». Я уверен, что такое поведение «специфицировано», но, очевидно, в моем понимании CDI есть большая дыра.

Может кто-нибудь объяснить, почему это не работает? В чем разница между SomePojo и java.util.Date с точки зрения CDI?

Контекст:

  • Java EE 6
  • GlassFish 3.1.2.2
  • У меня нет прецедентов для этого. Я знаю, что могу просто указать new Date().

ответ

3

Я могу воспроизвести это с помощью EAP 6.3.

Проблема, скорее всего, возникает из-за использования Java EE 6. java.util.Date находится в rt.jar, и этот JAR не содержит файл beans.xml, который бы включил CDI. Вы можете вводить только объекты из JAR, содержащие beans.xml.

Общим обходным путем является использование producer method для ввода такого объекта. Вы должны сами создать этого производителя, но вы сможете вводить объекты из произвольных классов, независимо от того, к каким JAR они принадлежат.

Насколько я знаю, поведение изменилось в Java EE 7, где beans.xml не является обязательным в некоторых случаях: https://blogs.oracle.com/theaquarium/entry/default_cdi_enablement_in_java

Надежда, что помогает.

+0

Я попробую это в Glassfish 4 через день или два и отчитаюсь. Спасибо. – DavidS

+2

EE7 не собирается изменять поведение в этом конкретном случае. С CDI 1.1 он будет автоматически обнаруживать бобы с помощью аннотации, определяющей bean-компонент (см. Раздел 12.4 «Изучение бинов спецификации»). Дата не имеет аннотации, определяющей bean-компонент (например, @RequestScoped) – jbergmark

+0

@jbergmark, я нашел ссылку на то, что вы описываете в [Бин-архив] (https://docs.jboss.org/cdi/spec/1.1 /cdi-spec.html#bean_archive) в разделе spec: «Неявный архив bean-файлов - это любой другой архив, содержащий один или несколько классов bean с компонентом, определяющим аннотацию ...» Это на самом деле также упоминается в сообщении в блоге roehrijn ссылка: «По умолчанию, если вы ничего не указываете и нет beans.xml, предполагается, что режим обнаружения бина« аннотированный », а не« все ».» Благодаря! – DavidS

Смежные вопросы