logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Adding a new plugin cache file format (future idea)
Date Mon, 28 Jul 2014 20:22:46 GMT
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>


Mime
View raw message