Oh that's right, you could theoretically have both files in a single jar. So there will need to be some rules about that as well.
On 31 August 2014 02:30, Remko Popma <remko.po...@gmail.com> wrote: > 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 <boa...@gmail.com> 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 <remko.po...@gmail.com> 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 <boa...@gmail.com> wrote: >> >>> Of course. Something structurally equivalent would be my preference. >>> >>> >>> On 28 August 2014 00:15, Ralph Goers <ralph.go...@dslextreme.com> 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 <garydgreg...@gmail.com> >>>> wrote: >>>> >>>> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers < >>>> ralph.go...@dslextreme.com> 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 <boa...@gmail.com> 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 <boa...@gmail.com> 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 <ralph.go...@dslextreme.com> >>>>>> 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 <boa...@gmail.com> 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 <boa...@gmail.com> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <boa...@gmail.com> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>> 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 <boa...@gmail.com> >>> >> >> > > > -- > Matt Sicker <boa...@gmail.com> > > -- Matt Sicker <boa...@gmail.com>
