I just mentioned it because that introduces the possibility of a jar having two plugin definition files: one in the old format and one in the new format.
Sent from my iPhone > On 2014/08/31, at 1:49, Matt Sicker <[email protected]> wrote: > > I'd assume we'd need to use a different file name for a new version of the > format (especially if it doesn't use DataOutputStream or the like). > > >> On 28 August 2014 02:16, Remko Popma <[email protected]> wrote: >> I agree with Ralph that we should at least be able to read the old format, >> even if we start to write (and read) a new format. >> >> Should we keep the name of this cache file the same? >> I guess we need to work out our policy on what to do if a jar contains both >> the plugins.dat in the old format and a plugin cache file in the new format. >> Or when the classpath has multiple plugin cache files spread out over >> multiple jars. >> >> It might be helpful for future evolution if the plugin cache file contains a >> format version number. >> >> >> >>> On Thu, Aug 28, 2014 at 2:23 PM, Matt Sicker <[email protected]> wrote: >>> Of course. Something structurally equivalent would be my preference. >>> >>> >>>> On 28 August 2014 00:15, Ralph Goers <[email protected]> wrote: >>>> 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 >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> > > > > -- > Matt Sicker <[email protected]>
