You would have to support both the old and new format. Ralph
On Aug 27, 2014, at 8:23 PM, Matt Sicker <[email protected]> wrote: > This idea came up in a recent bug report: > https://issues.apache.org/jira/browse/LOG4J2-798 > > I'm thinking that we could do something that either works well when you cat > together various plugin cache files, or if it were an XML file dump, then we > could have a tool to combine them together to address this other issue: > https://issues.apache.org/jira/browse/LOG4J2-673 > > > On 28 July 2014 15:34, Matt Sicker <[email protected]> wrote: > 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]> > > > > -- > Matt Sicker <[email protected]>
