I equate “human editable” with “error prone”. I’d wait until someone actually requests this with a real live use case before I’d want it implemented. I’m not sure what the benefit is of “disabling” a plugin. It is automatically “disabled” if it isn’t referenced in the configuration.
Ralph On Jul 28, 2014, at 11:39 AM, Matt Sicker <[email protected]> wrote: > So our current format works quite well for automated tool usage. If you don't > already know, it's basically a serialized HashMap containing class names and > the attributes from the @Plugin annotation associated with each class. > Normally, this file is generated through the Java compiler via an annotation > processor. However, languages like Scala, Clojure, Groovy, and whatever > others that exist that don't create intermediate Java code don't support > annotation processing. Thus, the resurrection of the runtime package scan > functionality. > > What I'd like to propose would be some sort of human-editable plugin file > format for those who may prefer to create their own. It would be nice for > being able to customize your Log4j distribution by enabling and disabling > plugins selectively. > > As a Java guy, I'd propose an XML format because that's what everyone else > does. Plus, there's the XML APIs already, so no custom file format processors > or anything are necessary. > > Note that the serialized file would still be preferred as the way to go since > it's already there and supported. However, offering an alternative would be > neat. Plus, the annotation processor could be extended to generate the XML > (or whatever) file. > > ============ > > Alternatively, a neat idea could be to use the ServiceLoader class from JDK > 1.6+. The various plugin types (Appender, Filter, Layout, PatternConverter, > etc.) could all be services, and we can load all the provided > implementations. We could also simply extend this idea by filling the service > provider file with a list of packages to scan instead of forcing the > configuration file to specify where they are. This could be a simpler > approach for internal plugins. > > -- > Matt Sicker <[email protected]>
