8:57 a.m.
For Keycloak we’ve been trying to create a trimmed down distribution of Keycloak server,
basing it on servlet-feature-pack rather than full-feature-pack, since we don’t need many
of the subsystems. We’ve encountered some issues though that made us step back and stick
to using full-feature-pack as a basis for Keycloak server distribution. If we find a way
to address these issues in the future we’ll reconsider, but for now we don’t see much
sense in basing our Keycloak distribution on servlet-feature-pack.
There are two big isues for us:
1) Big module dependency trees
Our goal was to reduce the distribution size by reducing the number of subsystems, and
modules shipped. We guessed that since we don’t use EJB, JMS, WS - but basically just
JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn’t
get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually
any additional subsystem - in our case we want to use datasources, which are provided by
org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That’s a
lot just to get datasources support.
What’s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs
pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency
tree as adding Datasources support - that’s how intertwined the dependencies currently
are.
Using servlet-feature-pack for distributions that require some additional subsystems from
full-feature-set is thus not very effective to significantly reduce custom distribution’s
disk footprint.
There is a tool I wrote as part of my analysis that I used to analyze the size of
dependency trees: https://github.com/mstruk/keycloak-moduletool
2) Staying in-sync with changes in full-feature-pack
Creating a custom feature pack that is a subset of full-feature-pack requires copying
module.xml files from wildfly/feature-pack source tree into custom feature pack source
tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be
precise). As Wildfly development moves on, any changes to module.xml files have to be
synced into the custom feature pack. That has the potential to be a huge maintenance
burden, and a source of errors. One way to address this would be extended syntax somewhere
in feature pack definition project to say something like:
<module id=”org.jboss.as.connector” from=”full-feature-pack”
include-dependencies=”true” skip-optional=”true”/>
And that would replace copying over module directories, and module.xml files. And
guarantee that things remain in-sync.
For our use-case this would also be addressed by wildfly providing a feature-pack
definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long
as it contains datasources support, and jaxrs support ...
Another thing is provisioning of feature packs, which I address in another email.
- marko