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 >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> > > -- Matt Sicker <[email protected]>
