[wildfly-dev] Creating config files for provisioned servers
stuart.w.douglas at gmail.com
Wed Sep 17 05:51:25 EDT 2014
This would still be done via supplements, in a similar way to how it is
done at the moment. I think when you define a new file such as
standalone-ha.xml you will also be able to supply supplement names to
modify the config.
Kabir Khan wrote:
> What about the next iteration where, say you have the EE feature pack and you add the clustering feature.
> Say, the clustering feature will add jgroups and infinispan subsystems, which is in line with what you say.
> However, with clustering enabled, IIRC that enables some extra things in e.g. the EJB subsystem.
> On 16 Sep 2014, at 22:55, Stuart Douglas<sdouglas at redhat.com> wrote:
>> Hi All,
>> so I have been giving a bit of thought to how our configuration files
>> are generated, and how it can work with feature packs. At the moment
>> feature packs just package files with a subsystem list inside, and later
>> feature packs configs override configs from their dependents.
>> I think we should move to an approach where feature packs build on the
>> config provided by other feature packs. So the web feature pack config
>> will basically express 'add these additional subsystems to
>> standalone.xml'. Additional config files can also be created based of
>> existing config, so for example standalone-full.xml would be represented
>> as 'like standalone.xml, but with these additional subsystems'.
>> Domain mode would work in a similar manner, but with profiles instead of
>> config files (so everything I am saying here about standalone.xml will
>> also apply to domain mode).
>> There are quite a few advantages to this approach:
>> - As most (all?) configs will use standalone.xml as a base, it makes it
>> simple to keep multiple config files in place
>> - It is easy for a feature pack to add a subsystem to all configurations
>> (e.g. installing the KeyCloak feature pack could add KeyCloak to all
>> - It is easy to create a new configuration that is the same as existing
>> configs, but with an additional subsystem.
>> Does this sound reasonable?
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
More information about the wildfly-dev