What is a WildFly feature pack

WildFly is a runtime built on JBoss Modules; this is a light weight and efficient modular classloader which allows the different components of a modern server to be defined as independent modules.

Hibernate ORM and its components are defined as one such module; this implies you can even have multiple different versions of an Hibernate ORM module in the same runtime while having their classpaths isolated from each other: you can add the very latest Hibernate ORM releases to WildFly without having to remove the existing copy.

This gives you the flexibility to use the latest version for one of your application with the peace of mind that you won’t break other applications requiring a different version of Hibernate. We don’t generally recommend to abuse this system but it’s often useful to be able for example to upgrade and test one application at a time, rather than having to mandate a new version for multiple services and have to update them all in one shot.

A feature pack is a zip file containing some XML files which define the structure of the JBoss Module(s) and list the Java “jar” files which will be needed by identifying them via Maven coordinates.

This has some further benefits:

• A feature pack is very small as it’s just a zipped file with some lines of XML.

• In terms of disk space you can build a “thin” server which doesn’t actually include a copy of your Maven artifacts but just loads the classes on demand from your local Maven cache.

• You still have the option to build a “full” server so that it can be re-distributed without needing to copy a local Maven repository.

• When using the provisioning tool you benefit from a composable approach, so N different packs can be combined to form a custom server.

• Since the feature pack XML merely lists which artifacts are recommended (rather than including a binary copy) it is easy to override the exact versions; this is ideal to apply micro, urgent fixes.

• A feature pack can declare transitive dependencies on other feature packs, so you will automatically be provided all non-optional dependencies of Hibernate ORM.

It is also interesting to highlight what it is not: differently than most build systems, the focus of JBoss Modules is not on how a project is built but how it should be run.

An important aspect is that runtime dependencies of a JBoss Module are not transitive: so for example if the latest Hibernate ORM requires Byte Buddy version 5 (as an example) while any other module that your application needs depends on Byte Buddy version 6 this will not be a problem.

Upgrading your applications could not be easier, as you won’t have to ensure that all your dependencies are aligned to use the same versions.