[wildfly-dev] Creating config files for provisioned servers
brian.stansberry at redhat.com
Wed Sep 17 11:52:25 EDT 2014
Alexey is working on this as a persistence alternative.
Darran, I've come around to wanting to do things as you say, but haven't
had cycles to resurrect my server-embedded in CLI thing.
This is somewhat orthogonal to Stuart's question though, which AIUI is
more about what configs a feature-pack should be updating. How it
updates them is of course related though.
On 9/17/14, 10:42 AM, James R. Perkins wrote:
> If we ever wanted to move away from XML configuration files using DMR,
> or JSON, could be a good first step.
> On 09/17/2014 07:52 AM, Darran Lofthouse wrote:
>> This is where I have been saying before why not build all the configs
>> using management ops / the CLI?
>> - Much easier to define config that tweaks the config that came before.
>> - Execute using the CLI and you even get some logic support.
>> - Would be compatible if in the future we release distributions that
>> don't use XML config persistence.
>> Darran Lofthouse.
>> On 16/09/14 22:55, Stuart Douglas 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
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev