I was thinking of it being based on ConfigurationBuilder as well. It seems like it wouldn't be too complicated to support that way, though the autocomplete functionality I mentioned wouldn't come for free from such an implementation.
Programmatic configuration would be mainly for dynamic configuration, not for writing inline plugins or scripts, though if such a feature worked well enough, that'd be pretty neat. This is more of a todo list item than immediate work. I'm planning on working on the Cassandra appender plugin this week. Other than that, my high priority things I'd like to look at are trying to get our site to work with multiple git repositories (bare minimum log4j-scala integration) and some JDK9 work. On 26 December 2016 at 15:06, Apache <ralph.go...@dslextreme.com> wrote: > 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>. 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> > > > -- Matt Sicker <boa...@gmail.com>
