You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2014/08/28 05:23:19 UTC
Re: Adding a new plugin cache file format (future idea)
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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Adding a new plugin cache file format (future idea)
Posted by Matt Sicker <bo...@gmail.com>.
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 <re...@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 <bo...@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 <re...@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 <bo...@gmail.com> wrote:
>>
>>> Of course. Something structurally equivalent would be my preference.
>>>
>>>
>>> On 28 August 2014 00:15, Ralph Goers <ra...@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 <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <
>>>> ralph.goers@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Adding a new plugin cache file format (future idea)
Posted by Remko Popma <re...@gmail.com>.
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 <bo...@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 <re...@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 <bo...@gmail.com> wrote:
>>> Of course. Something structurally equivalent would be my preference.
>>>
>>>
>>>> On 28 August 2014 00:15, Ralph Goers <ra...@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 <ga...@gmail.com> wrote:
>>>>>
>>>>>> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <ra...@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Adding a new plugin cache file format (future idea)
Posted by Matt Sicker <bo...@gmail.com>.
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 <re...@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 <bo...@gmail.com> wrote:
>
>> Of course. Something structurally equivalent would be my preference.
>>
>>
>> On 28 August 2014 00:15, Ralph Goers <ra...@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 <ga...@gmail.com>
>>> wrote:
>>>
>>> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <ralph.goers@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Adding a new plugin cache file format (future idea)
Posted by Remko Popma <re...@gmail.com>.
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 <bo...@gmail.com> wrote:
> Of course. Something structurally equivalent would be my preference.
>
>
> On 28 August 2014 00:15, Ralph Goers <ra...@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 <ga...@gmail.com>
>> wrote:
>>
>> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <ra...@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
>
Re: Adding a new plugin cache file format (future idea)
Posted by Matt Sicker <bo...@gmail.com>.
Of course. Something structurally equivalent would be my preference.
On 28 August 2014 00:15, Ralph Goers <ra...@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 <ga...@gmail.com> wrote:
>
> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <ra...@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
Re: Adding a new plugin cache file format (future idea)
Posted by Gary Gregory <ga...@gmail.com>.
OK, I can see that.
OTOH, we have put the Core APIs out of the public API WRT BC, so it would
be OK to apply the same reasoning to this cache file.
Gary
On Thu, Aug 28, 2014 at 1:15 AM, Ralph Goers <ra...@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 <ga...@gmail.com> wrote:
>
> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <ra...@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Adding a new plugin cache file format (future idea)
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> wrote:
> On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <ra...@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: Adding a new plugin cache file format (future idea)
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Aug 28, 2014 at 1:00 AM, Ralph Goers <ra...@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Adding a new plugin cache file format (future idea)
Posted by Ralph Goers <ra...@dslextreme.com>.
You would have to support both the old and new format.
Ralph
On Aug 27, 2014, at 8:23 PM, Matt Sicker <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Adding a new plugin cache file format (future idea)
Posted by Matt Sicker <bo...@gmail.com>.
The current format is basically a map of maps. It's kind of hierarchical.
On 27 August 2014 23:24, Gary Gregory <ga...@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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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 <bo...@gmail.com>
Re: Adding a new plugin cache file format (future idea)
Posted by Gary Gregory <ga...@gmail.com>.
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 <bo...@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 <bo...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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