Good points. I guess I can just wait to see if anyone wants such a feature. It would certainly make shading easier, but I don't like to encourage that anyhow.
On 28 July 2014 15:22, Ralph Goers <[email protected]> wrote: > 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]> > > > -- Matt Sicker <[email protected]>
