Yes, we do. Anyone who has created plugins will already have a jar with a file in it. Requiring them to recompile to upgrade Log4j is a compatibility breakage.
Ralph On Aug 27, 2014, at 10:09 PM, Gary Gregory <[email protected]> wrote: > On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <[email protected]> > wrote: > You would have to support both the old and new format. > > I do not think we have to be that cute, do we? > > Gary > > > 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]> > > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
