2016-01-13 13 views
1

Я полностью в недоумении! У меня есть этот класс:CDI Producermethod игнорируется

package com.company.resources 
import com.company.transport.Repository; //an interface for an EJB 
import com.company.transport.Expression; //a simple DTO, returned by the Interface 

public class ResourceProducer 
{ 

    //@EJB(lookup="foo") Repository repo; 

    @Produces @Named("archive") 
    public String getArchiveString() { 
     return "archive"; 
    } 

    @Produces @Named("repository") 
    public Repository getRemoteRepository(){ 
     //return repo; 
     return new Repository(){ 
      @Override 
      public Expression getExpression(String s, Long aLong) { 
       return null; 
      } 
     }; 
    } 
} 

И, просто поместите строку один работает, другой игнорируется контейнером (Wildfly 9/Weld).

В начале я хотел ввести EJB, а getRemoteRepository не был аннотирован как @Named, так как я знаю только один поставщик для интерфейса Repository. Получение ошибки, я изменил их, чтобы быть таким же, чтобы ограничить возможности для ошибки, даже в Injection Очки:

package com.company.resources 
public Class ExpressionProxy { 
    @Inject @Named("archive") String target; 
    @Inject @Named("repository") Repositroy repo; 
} 

я получаю:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Repository with qualifiers @Default 
    at injection point [BackedAnnotatedField] @Inject com.company.resources.ExpressionProxy 

Я не получаю это исключение для струны!

Кроме того, если я аннотирования ResourceProducer с @ApplicationScoped - что делает его Bean - Я ожидаю получения Неоднозначный привязок - а мой продюсер теперь найден через саму @Produces Аннотация и присутствует в управляемом Bean.

Я также получить только Неоднозначные обязательные исключения для строки, никогда для Repository

я переехал оба класса в один .WAR и в тот же пакет - это просто не будет работать с Repository.

Я сделал CDI-инъекцию через интерфейсы раньше - в чем проблема?

EDIT: дать полное раскрытие:

Я разворачивать это в ухо, как библиотека:

app.ear/ 
    -jaxrs.war # contains rest interface, irrelevant for this bug 
    -lib/ 
     -beans.jar #contains the Producer and ExpressionProxy 
     -RepositoryInterface.jar # containts Repository and Expression 

я попробовал каждую перестановку 3 архивов, участвующих.

  • упомянутый
  • beans и interfaces в качестве библиотеки в .war
  • beans в качестве дополнительного развертывания
  • beans в качестве дополнительного развертывания и в ухе/Lib

бобы в/Библиотека очевидно, сканируются с помощью сварки, поскольку String не создает никаких проблем.

+0

Можете ли вы прояснить этот бит? «Кроме того, если я комментирую ResourceProducer с помощью' @ ApplicationScoped', что делает его Bean - я ожидаю получить неоднозначные привязки, так как мой Продюсер теперь найден с помощью самой аннотации '@ Produces' и присутствует в управляемом компоненте. me, добавив '@ ApplicationScoped', там должно * not * вызвать исключение для двусмысленного привязки. – jpkrohling

ответ

0

Цитируется из документации Weld 2.2.3

Способ производитель должен быть не абстрактный метод в управляемый компонент класса или сессионного компонента класса. Метод производителя может быть как статическим, так и нестационарным. Если компонент является сессионным компонентом, метод производителя должен быть либо бизнес-методом EJB, либо статическим методом класса bean.

Таким образом, вы могли бы аннотировать ваш ResourceProducer с помощью @ApplicationScoped.

Примечание: Использование любой современной IDE должно сказать вам, что вам не хватает необходимых зависимостей при компиляции. Это экономит ваше время для развертывания вашего приложения.