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 configs). - It is easy to create a new configuration that is the same as existing configs, but with an additional subsystem. Does this sound reasonable? Stuart _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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. Stuart 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(a)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 >> configs). >> - It is easy to create a new configuration that is the same as existing >> configs, but with an additional subsystem. >> >> Does this sound reasonable? >> >> Stuart >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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. Regards, 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 > configs). > - It is easy to create a new configuration that is the same as existing > configs, but with an additional subsystem. > > Does this sound reasonable? > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev