Implementation Details

This chapter mostly serves as a road-map for users who are curious about the actual inner workings of WildFly Swarm.

Uberjar Layout

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:2017.11.0-SNAPSHOT
org.wildfly.swarm:security-modules:2017.11.0-SNAPSHOT
org.wildfly.swarm:hystrix:2017.11.0-SNAPSHOT
org.wildfly.swarm:rxnetty:2017.11.0-SNAPSHOT
org.wildfly.swarm:rxjava:2017.11.0-SNAPSHOT
org.wildfly.swarm:ee-modules:2017.11.0-SNAPSHOT
org.wildfly.swarm:logstash-modules:2017.11.0-SNAPSHOT
org.wildfly.swarm:ribbon-secured-modules:2017.11.0-SNAPSHOT

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:2017.11.0-SNAPSHOT
gav:org.wildfly.swarm:io:2017.11.0-SNAPSHOT
gav:io.netty:netty-transport:4.0.27.Final
gav:io.netty:netty-buffer:4.0.26.Final
gav:org.wildfly.swarm:clustering:2017.11.0-SNAPSHOT
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

Bootstrap

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.

ClassLoaders

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.