I'm building a JavaEE 8 application based on Wildfly
archetype ord.wildfly.archetype:wildfly-jakarta-ear-archetype:23.0.0.Final
and deplying it on Wildfly 23.0.2.Final
.
This creates 4 projects
test
|---test-ear
|---test-ejb
|---test-web
in which test-war
declares a dependency on test-ejb
as a provided module.
However, if I define a @Singleton @Startup
EJB in test-ejb
like that
@Singleton
@Startup
public class Bootstrap {
@PostConstruct
public void postContruct() {
System.out.println("********* BOOTSTRAP *********");
}
}
it is initialized twice: one when the test-ejb
is deployed, and the other when the test-web
is deployed.
I didn't expect that given the @Singleton
definition and the provided
scope of the dependency.
I'm not doing anything in the projects configuration, I just added the singleton class as described above (I didn't even declared any dependency on logger libs as well to keep my modifications to the minimum)
What am I doing wrong?
UPDATE: adding Manifest and descriptors
test-web
MANIFEST.MF
Manifest-Version: 1.0
Build-Jdk-Spec: 15
Created-By: Maven Integration for Eclipse
beans.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans version="2.0"
xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
bean-discovery-mode="annotated">
<!-- This descriptor configures Context and Dependeny Injection.
Actually, CDI 1.1 does not require this file. But the archetype contains it anyway to avoid deloyment errors for blank projects (WFLY-13306) -->
</beans>
test-ear
MANIFEST.MF
Manifest-Version: 1.0
Build-Jdk-Spec: 15
Created-By: Maven Integration for Eclipse
application.xml
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/application_8.xsd" version="8">
<description>This is the EAR POM file</description>
<display-name>test-ear</display-name>
<module>
<ejb>test-ejb.jar</ejb>
</module>
<module>
<web>
<web-uri>test-web.war</web-uri>
<context-root>/test-web</context-root>
</web>
</module>
<library-directory>lib</library-directory>
</application>
UPDATE: LOGS
Diving into the logs, it looks like the problem is actually a double deployment rather than a dependency issue.
During a deploy (via Eclipse) I see a first chunk that reads:
...
18:52:15,803 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment test.ear
18:52:15,852 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-7) HV000001: Hibernate Validator 6.0.22.Final
18:13:46,577 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0003: Processing weld deployment test-web.war
18:13:46,585 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment test-ejb.jar
...
18:13:47,754 INFO [stdout] (ServerService Thread Pool -- 87) ********* BOOTSTRAP *********
18:13:47,757 INFO [stdout] (ServerService Thread Pool -- 87) ********* POST CONSTRUCT com.test.test.Bootstrap@65495f *********
...
then, I see a second chunk:
...
18:13:48,243 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment test.ear
18:13:48,265 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0003: Processing weld deployment test-web.war
18:13:48,268 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment test-ejb.jar
...
18:13:48,507 INFO [stdout] (ServerService Thread Pool -- 87) ********* BOOTSTRAP *********
18:13:48,507 INFO [stdout] (ServerService Thread Pool -- 87) ********* POST CONSTRUCT com.test.test.Bootstrap@1606409c *********
...
Is it correct that the EJB and WAR module are processed twice?
UPDATE: Wildfly logs
Just tried increasing the log level of Wildfly itself. Going through the resulting file I don't see any exception. But I noticed this:
2021-06-22 18:44:59,357 DEBUG [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) Deployment scan of [/home/xxxx/wildfly-23.0.2.Final/standalone/deployments] found update action [{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "add",
"address" => [("deployment" => "togather-engine.ear")],
"content" => [{
"archive" => false,
"path" => "deployments/XXXX.ear",
"relative-to" => "jboss.server.base.dir"
}],
"persistent" => false,
"owner" => [
("subsystem" => "deployment-scanner"),
("scanner" => "default")
]
},
{
"operation" => "deploy",
"address" => [("deployment" => "XXXX.ear")],
"owner" => [
("subsystem" => "deployment-scanner"),
("scanner" => "default")
]
}
],
"operation-headers" => {"rollback-on-runtime-failure" => false}
}]
and after a bit
2021-06-22 18:45:11,886 DEBUG [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) Deployment scan of [/home/xxxxx/wildfly-23.0.2.Final/standalone/deployments] found update action [{
"operation" => "redeploy",
"address" => [("deployment" => "XXXX.ear")],
"owner" => [
("subsystem" => "deployment-scanner"),
("scanner" => "default")
]
}]
I verified the same behaviour on Wildfly 23 and 22.