Improvement in building the server.xml

[zhurlik]

Hi, I would like to suggest adding one more thing to describe/define the server.xml in the liberty section inside gradle script. I am attaching a small test class to demonstrate how it can work DynamicServerConfigurationTest.txt

[cherylking]

Hello @zhurlik, thank you for the suggestion for enhancement and the example. We evaluated it as a team and are struggling with the benefit over just providing a server.xml file in the default location. What is the motivation for providing another way to specify server.xml content?

[zhurlik]

Hi, @cherylking! Thank you for your quick reaction. Sure I can tell you about several benefits:

1. more flexible way using groovy for writing the server.xml For example, variable substitution could be easily implemented instead of the bootstrap.properties (sure that's needed for openliberty server but here groovy can do it more elegantly)
2. we will have a single place to see all server settings

   liberty {
   server { // all settings such as: ports, datasource, ssl etc.
   // groovy
   }

3. I still didn't investigate the relations between <featureManager> and the dependencies within an application that will be run on the openliberty server, but from my point of view I would like to get a skinny war file. For example when I am enabling a feature, let's say JPA then most of jars should be excluded via providedCompile. This logic will be possible to implement in the gradle script and it will be more readable when you will see together features+dependencies

dependencies {
   // groovy
}

liberty {
    server {
        featureManager{
          // groovy
        }
    }
}