logging-log4j-dev mailing list archives

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

On 28 July 2014 15:22, Ralph Goers <ralph.goers@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 <boards@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 <boards@gmail.com>

Matt Sicker <boards@gmail.com>

View raw message