Nach der Migration einer JEE-Anwendung (von JBoss 7.1.1 auf WildFly 8.2.1) hat unsere Methode zum Abrufen von CDI Beans aufgehört zu arbeiten. Die Anwendung verfügt über mehrere Module (unabhängige JAR-Dateien), die in einer WAR-Datei gruppiert sind, die jetzt auf WildFly bereitgestellt wird.Bean wurde nach Migration zu WildFly nicht von seiner Schnittstelle gefunden.
Das Bean in dem Modul zu service injiziert ist, und es setzt die Schnittstelle IProcessor:
@Loggable
@Monitorable
@Singleton
@ConcurrencyManagement(CONTAINER)
@Lock(READ)
@LocalBean
@ApplicationScoped
public class Processor implements IProcessor {
[...]
in einem anderen Modul der Anwendung (common) ist der Rest der Logik: Die Schnittstelle IProcessor und die Klasse, in der wir danach suchen.
Dies ist, wie die BeanManager abgerufen wird:
public void keepBeanManager(@Observes AfterBeanDiscovery abd, BeanManager beanManager) {
bm = beanManager;
}
Und das ist, wie der Anruf erfolgt ist:
Set<Bean<?>> jobBeans = bm.getBeans(IProcessor.class);
habe ich versucht, alle eingesetzten Bohnen Ausdruck von Adam Bien ist mit sample, bei der gleiche Punkt wie die getBeans Methode aufgerufen wird, und ich kann die Processor in ihnen sehen. Wenn das vollständige Paket und der Klassenname Processor als temporärer Hack verwendet werden, aber die Schnittstelle IProcessor nicht funktioniert, ist jobBeans immer leer. Das Modul service ist für das Modul common nicht sichtbar, weshalb die Injektion über die Schnittstelle erfolgt.
Da es früher in JBoss und nicht in WildFly lief, nehme ich an, dass es mit der Art und Weise zusammenhängt, wie der AS mit den Beans umgeht, könnte etwas in der Konfiguration von WildFly nach der Migration fehlen?
Haben Sie versucht, ohne die @LocalBean? –
Hat jedes JAR eine 'beans.xml'? –
@JohnAment Ja, jede JAR hat eine beans.xml – dajoropo