Java CDI Ungültige DependsOn-Abhängigkeit

Question

Ich versuche, einige Inhalte in der Datenbank beim Start der Anwendung zu aktualisieren. Um dies zu tun, habe ich eine Klasse A geschaffen, die dies tun wird.

@Singleton 
@Startup 
@DependsOn({ "B", "C" }) 
public class A{ 
    @Inject B b; 
    @Inject C c; 
    ... 
} 

B ist eine Klasse, die einige Konfigurationswerte aus der Datenbank liest. B:

@Singleton 
@Startup 
public class B { 
    @PersistenceContext 
    EntityManager em; 
    ... 
} 

C ist eine Baumstruktur, die die Daten von Klassen D und E einen korrekt formatierte Baum zu konstruieren, verwendet.
C:

@Singleton 
@Startup 
@DependsOn({ "D", "E" }) 
public class QuestionHandler { 
    @Inject 
    D d; 
    @Inject 
    E e; 
    ... 
} 

D und E sind Blatt Singletons in dem Sinne, dass sie nicht auf anderen Singletons abhängen; Sie bieten Daten (die von Dateien auf den db gelesen wird):
D:

@Singleton 
@Startup 
public class D { ... } 

E:

@Singleton 
@Startup 
public class D { ... } 

Basierend auf dem DependsOn annotation documentation ich davon aus, dass CDI die Abhängigkeitsgraphen schaffen für die Singletons und werden sie in der angegebenen Reihenfolge initialisieren (B, D und E werden initialisiert, bevor C wird und bevor schließlich A initialisiert wird). Wenn ich jedoch versuche, die Anwendung zu implementieren, erhalte ich eine Ausnahme:
Ausnahme während der Lebenszyklusverarbeitung java.lang.RuntimeException: Ungültige DependsOn Abhängigkeit 'C' für EJB ContentUpdater.

Voll Stack-Trace:

java.lang.RuntimeException: Invalid DependsOn dependency 'C' for EJB A 
at org.glassfish.ejb.deployment.util.EjbBundleValidator.checkDependsOn(EjbBundleValidator.java:602) 
at org.glassfish.ejb.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:300) 
at org.glassfish.ejb.deployment.descriptor.EjbDescriptor.visit(EjbDescriptor.java:2823) 
at org.glassfish.ejb.deployment.descriptor.EjbDescriptor.visit(EjbDescriptor.java:2811) 
at org.glassfish.ejb.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:115) 
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:625) 
at org.glassfish.ejb.deployment.descriptor.EjbBundleDescriptorImpl.visit(EjbBundleDescriptorImpl.java:757) 
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:121) 
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:625) 
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:190) 
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:203) 
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:227) 
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96) 
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:881) 
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:821) 
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377) 
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219) 
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535) 
at java.security.AccessController.doPrivileged(Native Method) 
at javax.security.auth.Subject.doAs(Subject.java:360) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557) 
at java.security.AccessController.doPrivileged(Native Method) 
at javax.security.auth.Subject.doAs(Subject.java:360) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846) 
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722) 
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534) 
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224) 
at org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189) 
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459) 
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167) 
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201) 
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175) 
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) 
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) 
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) 
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) 
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) 
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) 
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) 
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) 
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) 
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117) 
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56) 
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137) 
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) 
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) 
at java.lang.Thread.run(Thread.java:745) 

Weiß jemand, warum diese Ausnahme der oben beschriebenen Struktur gegeben auftritt?

Wenn ich Klasse C in der @ DependsOn-Annotation in Klasse A weglasse, bekomme ich eine weitere Ausnahme, also ist das leider keine Lösung. Die Anwendung ist auf GlassFish 4.1

Answer 1

implementiert Ich schlage vor, Sie überdenken Sie Ihr Design und nur eine einzige "StartUpController" erstellen, die Init-Methoden auf allen anderen ejbs in der Reihenfolge auslöst, die Sie benötigen.

@Singleton 
public class A { 
    public void init() {} 
} 

@Singleton 
public class B { 
    public void init() {} 
} 

@Singleton 
public class C { 
    public void init() {} 
} 



@Startup 
@Singleton 
public class StartUpController { 

    @Inject 
    private A a; 

    @Inject 
    private B b; 

    @Inject 
    private C c; 

    @PostConstruct 
    protected void setup() { 
     a.init(); 
     b.init(); 
     c.init(); 
    } 

} 

@DependsOn ist nicht wirklich eine „Abhängigkeitssteuerung“ das ist nur eine Kontrolle der Initialisierungsreihenfolge und es macht nur Sinn, zusammen mit @PostConstruct Methode. (Ich sehe keine Initialisierungsmethoden in Ihrem Beispiel), daher ist @DependsOn nicht notwendig. Sie können ejb's in eine Kette ohne diese Annotation sehen this und this Beispiel.

Ich kann nicht genau beantworten, warum Sie Code nicht funktioniert vielleicht ist es nur ein Tippfehler. Zum Beispiel haben Sie keine C.class in Code, der oben veröffentlicht wurde, sondern stattdessen QuestionHandler.class, und wieder sehe ich keine @PostConstruct-Methoden in Ihrem Code. Der andere Grund dafür ist die Konfiguration von "glashfish". Ich schlage vor, dass Sie versuchen, den Code auf dem Wildfly-Server zu programmieren.