mike rodent
mike rodent

Reputation: 15682

Extract info from a Groovy DSL file?

I recently switched my logback configuration file from logback.xml to logback.groovy. Using a DSL with Groovy is more versatile than XML for this sort of thing.

I need to analyse this file programmatically, like I analysed the previous XML file (any of innumerable parsing tools). I realise that this will be imperfect, as a DSL config file sits on top of an object which it configures and must be executed, so its results are inevitably dynamic, whereas an XML file is static.

If you want to include one Groovy file in another file there are solutions. This one worked for me.

But I'm struggling to find what I need from the results.

If I put a function like this in the DSL file ...

def greet(){
  println "hello world"
}

... not only can I execute it (config.greet() as below), but I can also see it listed when I go

    GroovyShell shell = new GroovyShell()
    def config = shell.parse( logfileConfigPath.toFile() )
    println "config.class.properties ${config.class.properties}"

But if I put a line like this in the DSL file...

def MY_CONSTANT = "XXX"

... I have no idea how to find it and get its value (it is absent from the confusing and copious output from config.class.properties).

PS printing out config.properties just gives this:

[class:class logback, binding:groovy.lang.Binding@564fa2b]

... and yes, I did look at config.binding.properties: there was nothing.

further thought

My question is, more broadly, about what if any tools are available for analysis of Groovy DSL configuration files. Given that such a file is pretty meaningless without the underlying object it is configuring (an object implementing org.gradle.api.Project in the case of Gradle; I don't know what class it may be in the case of logback), you would have thought there would need to be instrumentation to kind of hitch up such an object and then observe the effects of the config file in a controlled, observable way. If Groovy DSL config files are to be as versatile as their XML counterparts surely you need something along those lines? NB I have a suspicion that org.gradle.tooling.model.GradleProject or org.gradle.tooling.model.ProjectModel might serve that purpose. Unfortunately, at the current time I am unable to get GradleConnector working, as detailed here.

I presume there is nothing of this kind for logback, and at the moment I have no knowledge of its DSL or configurable object, or the latter's class or interface...

Upvotes: 0

Views: 667

Answers (1)

The use of def creates a local variable in the execution of the script that is not available in the binding of the script; see this. Even dropping def will not expose MY_CONSTANT in the binding because parsing the script via GroovyShell.parse() does not interpret/execute the code.

To expose MY_CONSTANT in config's binding, change def MY_CONSTANT = "XXX" to MY_CONSTANT = "XXX" and execute the config script via config.run().

Upvotes: 1

Related Questions