A) What happened to the work on integrating Log4j 1 configurations? I’d rather see that finished before moving on to something else. B) After adding script support to various components I’m leaning more in favor of providing script flexibility where it is needed rather than doing the whole thing as a script. Creating the actual appenders, filters, layouts, etc. programmatically feels much heavier than declaring them in XML or JSON. But being able to dynamically choose which to use or to set property values seems like something I might want to do from time to time. C) If I was going to add DSL configuration support I would base it on the ConfigurationBuilder instead of using the “real” builders. Because the scripts would just be creating configuration there would be much less risk that things might be initialized or shutdown improperly.
Ralph > On Dec 26, 2016, at 11:47 AM, Matt Sicker <boa...@gmail.com> wrote: > > I remember Ralph mentioning long ago about a desire to add a Groovy > configuration syntax similar in idea to the support in Logback > <http://logback.qos.ch/manual/groovy.html > <http://logback.qos.ch/manual/groovy.html>>. I definitely like this idea, and > I was wondering if there'd be interest in implementing this in a more general > DSL fashion that could support not only Groovy but perhaps Scala, Kotlin, > JavaScript, etc. The existing Java configuration builder classes should be > adaptable to a generic DSL with some additional glue code to support closures > and such in the relevant languages. > > Another idea I was thinking about recently was investigating how feasible it > would be to create an IntelliJ plugin that would support autocomplete for > writing configuration files based on your project's classpath's available > plugins (an XSD would make this unnecessary in the XML format, but I don't > think the XML config format is expressible in an XSD). It's quite possible > that the existing plugin metadata we generate is sufficient for such an IDE > plugin, but I haven't looked into this closely enough yet to say for sure. > Depending on the implementation of other configuration DSLs, this might not > actually be necessary as you could get autocomplete for free with certain > languages. > > I'm bringing these ideas up here first before adding them as tickets in JIRA > to see what you guys think. > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
