Most infinispan services are configured to start passively, for a couple reasons:
1. Infinispan requires its cache container to start when the associated JGroups channel is started.
2. Cache configurations should be installed when the cache container starts, so that calls to EmbeddedCacheManager.getCache(...) use the correct configuration.

There's not much we can do about #1, except maybe to allow non-clustered cache containers (i.e. those without a transport) to start on-demand, instead of passively. This is a little tricky currently, since the transport is a separate resource from the cache container, and is typically installed afterwards.
#2 isn't needed anymore, since applications can depend on a specific cache configuration via jndi resource references.

Therefore, cache configuration services (and the individual configuration components services) should start as on-demand. Additionally, many of these services reference a full ConfigurationBuilder object, which is pretty hefty, for the entire lifetime of the service (regardless of state). These can be optimized to create the requisite builders only when the corresponding service is started. This should help reduce WF's startup memory footprint, as cache configurations do not need to be installed on startup.