This chapter mostly serves as a road-map for users who are curious about the actual inner workings of WildFly Swarm.
The layout of the generated myapp-swarm.jar
looks roughly like:
wildfly-swarm.properties
-
File containing the version of WildFly Swarm used in the construction.
META-INF/wildfly-swarm.properties
-
File containing all user-specified (or default) properties to be used when executing the uberjar. For example:
#Generated by WildFly Swarm #Tue Aug 25 11:38:12 BRT 2015 swarm.port.offset=3 swarm.logstash.hostname=localhost swarm.context.path=/ swarm.bind.address=127.0.0.1 java.net.preferIPv4Stack=true swarm.node.id=booker-pricing swarm.app.artifact=booker-pricing-1.0.0.Alpha01-SNAPSHOT.jar swarm.logstash.port=8000
META-INF/wildfly-swarm-bootstrap.conf
-
Lists all WildFly Swarm module dependencies in Maven GAV format. For example:
org.wildfly.swarm:logging-modules:{{book.versions.swarm}} org.wildfly.swarm:security-modules:{{book.versions.swarm}} org.wildfly.swarm:hystrix:{{book.versions.swarm}} org.wildfly.swarm:rxnetty:{{book.versions.swarm}} org.wildfly.swarm:rxjava:{{book.versions.swarm}} org.wildfly.swarm:ee-modules:{{book.versions.swarm}} org.wildfly.swarm:logstash-modules:{{book.versions.swarm}} org.wildfly.swarm:ribbon-secured-modules:{{book.versions.swarm}}
META-INF/wildfly-swarm-application.conf
-
Lists all application dependencies as JBoss-Module names or Maven GAVs. For example:
module:org.wildfly.swarm.keycloak module:org.wildfly.swarm.netflix.ribbon.secured module:org.wildfly.swarm.security module:org.wildfly.swarm.logstash module:org.wildfly.swarm.netflix.ribbon gav:org.wildfly.swarm:undertow:{{book.versions.swarm}} gav:org.wildfly.swarm:io:{{book.versions.swarm}} gav:io.netty:netty-transport:4.0.27.Final gav:io.netty:netty-buffer:4.0.26.Final gav:org.wildfly.swarm:clustering:{{book.versions.swarm}} gav:javax.json:javax.json-api:1.0 gav:io.reactivex:rxnetty:0.4.9
META-INF/MANIFEST.MF
-
Standard Java archive manifest which specifies the WildFly Swarm bootstrap
Main-Class
along with tracking the user-provided main class. For example:Main-Class: org.wildfly.swarm.bootstrap.Main Wildfly-Swarm-Main-Class: org.mycorp.myapp.Main
_bootstrap/
-
Directory containing the
.jar
or.war
of the application. m2repo/
-
Maven-style repository of all jars
modules/
-
JBoss-Modules tree of
module.xml
files which reference jars by Maven GAV
When the myapp-swarm.jar
is executed through java -jar
, the org.wildfly.swarm.bootstrap.Main
class is always executed initially. It initializes the JBoss-Modules module system and sets up the modules listed in META-INF/wildfly-swarm-bootstrap.conf
It then loads the user-provided main-class from the artifact in the _bootstrap/
directory and executes it.
Conceptually there are 3 classloader spaces in a WildFly Swarm uberjar.
The first is the system classloader, which is used initially when bootstrapping the core Main
.
Second, the user-provided main-class is executed in a relatively vanilla classloader to perform the Container
and fraction configuration.
Thirdly, the Container
configuration is passed to the back-end classloader which then converts the simple POJO configuration objects into the appropriate control structures used to initialize the WildFly container.
When a user-provided main-class is executed directly from an IDE, the first two conceptual classloaders are actually both satisfied by the system ClassLoader
.