logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Adding a new plugin cache file format (future idea)
Date Mon, 28 Jul 2014 18:39:42 GMT
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 <boards@gmail.com>

View raw message