The current format is basically a map of maps. It's kind of hierarchical.
On 27 August 2014 23:24, Gary Gregory <garydgreg...@gmail.com> wrote: > If the data is not hierarchical in nature, we could eschew XML, which > would also make it better for "cat"-ing. > > Gary > > > On Wed, Aug 27, 2014 at 11: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>
