Bean не найден по его интерфейсу после перехода на WildFly

Question

После переноса приложения JEE (от JBoss 7.1.1 до WildFly 8.2.1) наш метод получения CDI Beans прекратил работать. Приложение имеет несколько модулей (независимых JAR-файлов), сгруппированных в один файл WAR, развернутый сейчас на WildFly.

Бин, который будет введен в модуле service и реализует интерфейс IProcessor:

@Loggable 
@Monitorable 
@Singleton 
@ConcurrencyManagement(CONTAINER) 
@Lock(READ) 
@LocalBean 
@ApplicationScoped 
public class Processor implements IProcessor { 
[...] 

В другом модуле приложения (common) есть остальная часть логики: интерфейс IProcessor и класс, где мы его ищем.

Это как BeanManager извлекается:

public void keepBeanManager(@Observes AfterBeanDiscovery abd, BeanManager beanManager) { 
    bm = beanManager; 
} 

И это, как это делается вызов:

Set<Bean<?>> jobBeans = bm.getBeans(IProcessor.class); 

Я пробовал печатать все развернутые бобы с использованием Adam Bien-х sample, в та же самая точка, что и метод getBeans, и я вижу в них Processor. Кроме того, если предоставление полного пакета и имя класса Processor работает как временный взлом, но с использованием интерфейса IProcessor никогда не работает, jobBeans всегда пуст.

Модуль service не виден модулю common, и именно поэтому инъекция осуществляется с использованием интерфейса.

Как и раньше, в JBoss, а не в WildFly, я предполагаю, что это связано с тем, как AS обрабатывает Beans, может ли это быть чем-то отсутствующим в конфигурации WildFly после миграции?

Answer 1

Как указано Ксавьером Дури в комментариях, Бин не был найден, потому что он был аннотирован как @LocalBean. Исправлена ​​ошибка, связанная с аннотацией @LocalBean.

Из JEE definition of LocalBean:

Обозначает, что сессионный компонент предоставляет вид не-интерфейса

В Processor реализует интерфейс IProcessor, аннотации @LocalBean не следует использовать.

Что странно до сих пор для меня, почему это работает на JBoss ...