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 Gary Gregory <ga...@gmail.com> on 2016/03/02 19:39:22 UTC
One Include to rule them all
Stemming from discussion in https://github.com/apache/logging-log4j2/pull/25
How about finally adding our own include mechanism:
<Include monitorIntervalSeconds="60">file://...</Include>
If Configuration has a monitorInterval, then Includes inherit the setting,
if you set an Include monitorInterval to 0 then, then it is not watched.
Thoughts?
Gary
--
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: One Include to rule them all
Posted by Matt Sicker <bo...@gmail.com>.
I'd probably go with the smallest positive value. The only scenario to
ignore all files would be if none specified a non-zero interval.
On 2 March 2016 at 14:00, Ralph Goers <ra...@dslextreme.com> wrote:
> Yes, I would only check the files all at the same time. Which value to
> use would most likely follow the rules for merging all duplicate attributes.
>
> Ralph
>
> On Mar 2, 2016, at 12:21 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> With a multi-configuration, would the file watcher thread sync up the
> times together? I wouldn't want them to alternate and have to reload the
> configuration more times than necessary because I updated two config files
> at the same time.
>
> On 2 March 2016 at 13:10, Gary Gregory <ga...@gmail.com> wrote:
>
>> Which ever way we do it, merge vs. include, the big picture item is that
>> Log4j knows about these files and therefore can watch them and reconfigure
>> itself. I'm OK with either approach. The multiple configuration is simpler
>> in the sense that it does not require new Configuration elements or
>> attributes. I assume that you just list them one after the other in some
>> sys prop. Otherwise, I would not want Log4j hunting all over my classpath
>> for config files and merging them all, that would not be good IMO.
>>
>> Gary
>>
>> On Wed, Mar 2, 2016 at 10:54 AM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> I never really wanted to do includes. I would prefer to support
>>> multiple configuration files that are merged - see LOG4J2-494. I view the
>>> XInclude for XML files as a special case.
>>>
>>> If I did want to support includes I would not want to allow a
>>> monitorInterval on the include element. The value on the configuration
>>> should be used. I have no idea what it would mean to have a
>>> monitorInterval of 0 on the main configuration and a non-zero value on an
>>> include. Likewise, having a main monitorInterval of 60 and an interval of
>>> 30 on an include also doesn’t seem right.
>>>
>>> Ralph
>>>
>>>
>>>
>>> On Mar 2, 2016, at 11:39 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> Stemming from discussion in
>>> https://github.com/apache/logging-log4j2/pull/25
>>>
>>> How about finally adding our own include mechanism:
>>>
>>> <Include monitorIntervalSeconds="60">file://...</Include>
>>>
>>> If Configuration has a monitorInterval, then Includes inherit the
>>> setting, if you set an Include monitorInterval to 0 then, then it is
>>> not watched.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> 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
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: One Include to rule them all
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes, I would only check the files all at the same time. Which value to use would most likely follow the rules for merging all duplicate attributes.
Ralph
> On Mar 2, 2016, at 12:21 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> With a multi-configuration, would the file watcher thread sync up the times together? I wouldn't want them to alternate and have to reload the configuration more times than necessary because I updated two config files at the same time.
>
> On 2 March 2016 at 13:10, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
> Which ever way we do it, merge vs. include, the big picture item is that Log4j knows about these files and therefore can watch them and reconfigure itself. I'm OK with either approach. The multiple configuration is simpler in the sense that it does not require new Configuration elements or attributes. I assume that you just list them one after the other in some sys prop. Otherwise, I would not want Log4j hunting all over my classpath for config files and merging them all, that would not be good IMO.
>
> Gary
>
> On Wed, Mar 2, 2016 at 10:54 AM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> I never really wanted to do includes. I would prefer to support multiple configuration files that are merged - see LOG4J2-494. I view the XInclude for XML files as a special case.
>
> If I did want to support includes I would not want to allow a monitorInterval on the include element. The value on the configuration should be used. I have no idea what it would mean to have a monitorInterval of 0 on the main configuration and a non-zero value on an include. Likewise, having a main monitorInterval of 60 and an interval of 30 on an include also doesn’t seem right.
>
> Ralph
>
>
>
>> On Mar 2, 2016, at 11:39 AM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>
>> Stemming from discussion in https://github.com/apache/logging-log4j2/pull/25 <https://github.com/apache/logging-log4j2/pull/25>
>>
>> How about finally adding our own include mechanism:
>>
>> <Include monitorIntervalSeconds="60">file://...</Include>
>>
>> If Configuration has a monitorInterval, then Includes inherit the setting, if you set an Include monitorInterval to 0 then, then it is not watched.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: One Include to rule them all
Posted by Matt Sicker <bo...@gmail.com>.
With a multi-configuration, would the file watcher thread sync up the times
together? I wouldn't want them to alternate and have to reload the
configuration more times than necessary because I updated two config files
at the same time.
On 2 March 2016 at 13:10, Gary Gregory <ga...@gmail.com> wrote:
> Which ever way we do it, merge vs. include, the big picture item is that
> Log4j knows about these files and therefore can watch them and reconfigure
> itself. I'm OK with either approach. The multiple configuration is simpler
> in the sense that it does not require new Configuration elements or
> attributes. I assume that you just list them one after the other in some
> sys prop. Otherwise, I would not want Log4j hunting all over my classpath
> for config files and merging them all, that would not be good IMO.
>
> Gary
>
> On Wed, Mar 2, 2016 at 10:54 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I never really wanted to do includes. I would prefer to support multiple
>> configuration files that are merged - see LOG4J2-494. I view the XInclude
>> for XML files as a special case.
>>
>> If I did want to support includes I would not want to allow a
>> monitorInterval on the include element. The value on the configuration
>> should be used. I have no idea what it would mean to have a
>> monitorInterval of 0 on the main configuration and a non-zero value on an
>> include. Likewise, having a main monitorInterval of 60 and an interval of
>> 30 on an include also doesn’t seem right.
>>
>> Ralph
>>
>>
>>
>> On Mar 2, 2016, at 11:39 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Stemming from discussion in
>> https://github.com/apache/logging-log4j2/pull/25
>>
>> How about finally adding our own include mechanism:
>>
>> <Include monitorIntervalSeconds="60">file://...</Include>
>>
>> If Configuration has a monitorInterval, then Includes inherit the
>> setting, if you set an Include monitorInterval to 0 then, then it is not
>> watched.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> 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
>
--
Matt Sicker <bo...@gmail.com>
Re: One Include to rule them all
Posted by Gary Gregory <ga...@gmail.com>.
Which ever way we do it, merge vs. include, the big picture item is that
Log4j knows about these files and therefore can watch them and reconfigure
itself. I'm OK with either approach. The multiple configuration is simpler
in the sense that it does not require new Configuration elements or
attributes. I assume that you just list them one after the other in some
sys prop. Otherwise, I would not want Log4j hunting all over my classpath
for config files and merging them all, that would not be good IMO.
Gary
On Wed, Mar 2, 2016 at 10:54 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
> I never really wanted to do includes. I would prefer to support multiple
> configuration files that are merged - see LOG4J2-494. I view the XInclude
> for XML files as a special case.
>
> If I did want to support includes I would not want to allow a
> monitorInterval on the include element. The value on the configuration
> should be used. I have no idea what it would mean to have a
> monitorInterval of 0 on the main configuration and a non-zero value on an
> include. Likewise, having a main monitorInterval of 60 and an interval of
> 30 on an include also doesn’t seem right.
>
> Ralph
>
>
>
> On Mar 2, 2016, at 11:39 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Stemming from discussion in
> https://github.com/apache/logging-log4j2/pull/25
>
> How about finally adding our own include mechanism:
>
> <Include monitorIntervalSeconds="60">file://...</Include>
>
> If Configuration has a monitorInterval, then Includes inherit the
> setting, if you set an Include monitorInterval to 0 then, then it is not
> watched.
>
> Thoughts?
>
> Gary
>
> --
> 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: One Include to rule them all
Posted by Ralph Goers <ra...@dslextreme.com>.
I never really wanted to do includes. I would prefer to support multiple configuration files that are merged - see LOG4J2-494. I view the XInclude for XML files as a special case.
If I did want to support includes I would not want to allow a monitorInterval on the include element. The value on the configuration should be used. I have no idea what it would mean to have a monitorInterval of 0 on the main configuration and a non-zero value on an include. Likewise, having a main monitorInterval of 60 and an interval of 30 on an include also doesn’t seem right.
Ralph
> On Mar 2, 2016, at 11:39 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Stemming from discussion in https://github.com/apache/logging-log4j2/pull/25 <https://github.com/apache/logging-log4j2/pull/25>
>
> How about finally adding our own include mechanism:
>
> <Include monitorIntervalSeconds="60">file://...</Include>
>
> If Configuration has a monitorInterval, then Includes inherit the setting, if you set an Include monitorInterval to 0 then, then it is not watched.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: One Include to rule them all
Posted by Paul Benedict <pb...@apache.org>.
You're right that XInclude only works with XML. Perhaps this is why Ralph
said it's a "special case". It's a pretty powerful standard feature; yet it
won't fit the bill if you want to watch files. Sorry, I know no such way of
knowing what files are included through XInclude because it's meant to be
transparent. Don't take my word for it but I have yet to find a way (or
need a way).
Cheers,
Paul
On Wed, Mar 2, 2016 at 1:06 PM, Gary Gregory <ga...@gmail.com> wrote:
> So, with XInclude, there is no way to ask for "What files are you really
> included when processing this document" unless you get in the guts of the
> private Xerces copy which is in Oracle Java 7 (but not in Java 8), which we
> do not want to do. Also XInclude does not work with JSON and YAML.
>
> G
>
> On Wed, Mar 2, 2016 at 10:52 AM, Paul Benedict <pb...@apache.org>
> wrote:
>
>> I agree with the initial assessment that XInclude is the way to go. If
>> someone wants to use XInclude, they should provide the right parser
>> implementation to make it available. I wouldn't bend over backward to do
>> your own inclusion mechanism; put it on the consumer to provide the
>> appropriate parser.
>>
>> Cheers,
>> Paul
>>
>> On Wed, Mar 2, 2016 at 12:39 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> Stemming from discussion in
>>> https://github.com/apache/logging-log4j2/pull/25
>>>
>>> How about finally adding our own include mechanism:
>>>
>>> <Include monitorIntervalSeconds="60">file://...</Include>
>>>
>>> If Configuration has a monitorInterval, then Includes inherit the
>>> setting, if you set an Include monitorInterval to 0 then, then it is
>>> not watched.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> 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: One Include to rule them all
Posted by Gary Gregory <ga...@gmail.com>.
So, with XInclude, there is no way to ask for "What files are you really
included when processing this document" unless you get in the guts of the
private Xerces copy which is in Oracle Java 7 (but not in Java 8), which we
do not want to do. Also XInclude does not work with JSON and YAML.
G
On Wed, Mar 2, 2016 at 10:52 AM, Paul Benedict <pb...@apache.org> wrote:
> I agree with the initial assessment that XInclude is the way to go. If
> someone wants to use XInclude, they should provide the right parser
> implementation to make it available. I wouldn't bend over backward to do
> your own inclusion mechanism; put it on the consumer to provide the
> appropriate parser.
>
> Cheers,
> Paul
>
> On Wed, Mar 2, 2016 at 12:39 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> Stemming from discussion in
>> https://github.com/apache/logging-log4j2/pull/25
>>
>> How about finally adding our own include mechanism:
>>
>> <Include monitorIntervalSeconds="60">file://...</Include>
>>
>> If Configuration has a monitorInterval, then Includes inherit the
>> setting, if you set an Include monitorInterval to 0 then, then it is not
>> watched.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> 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: One Include to rule them all
Posted by Paul Benedict <pb...@apache.org>.
PS: Are we talking the same thing? Document inclusion is NOT the same as
watching an external file. The former creates one seamless document; the
second one is aware that the referenced file is distinct.
Cheers,
Paul
On Wed, Mar 2, 2016 at 12:52 PM, Paul Benedict <pb...@apache.org> wrote:
> I agree with the initial assessment that XInclude is the way to go. If
> someone wants to use XInclude, they should provide the right parser
> implementation to make it available. I wouldn't bend over backward to do
> your own inclusion mechanism; put it on the consumer to provide the
> appropriate parser.
>
> Cheers,
> Paul
>
> On Wed, Mar 2, 2016 at 12:39 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> Stemming from discussion in
>> https://github.com/apache/logging-log4j2/pull/25
>>
>> How about finally adding our own include mechanism:
>>
>> <Include monitorIntervalSeconds="60">file://...</Include>
>>
>> If Configuration has a monitorInterval, then Includes inherit the
>> setting, if you set an Include monitorInterval to 0 then, then it is not
>> watched.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> 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: One Include to rule them all
Posted by Paul Benedict <pb...@apache.org>.
I agree with the initial assessment that XInclude is the way to go. If
someone wants to use XInclude, they should provide the right parser
implementation to make it available. I wouldn't bend over backward to do
your own inclusion mechanism; put it on the consumer to provide the
appropriate parser.
Cheers,
Paul
On Wed, Mar 2, 2016 at 12:39 PM, Gary Gregory <ga...@gmail.com>
wrote:
> Stemming from discussion in
> https://github.com/apache/logging-log4j2/pull/25
>
> How about finally adding our own include mechanism:
>
> <Include monitorIntervalSeconds="60">file://...</Include>
>
> If Configuration has a monitorInterval, then Includes inherit the
> setting, if you set an Include monitorInterval to 0 then, then it is not
> watched.
>
> Thoughts?
>
> Gary
>
> --
> 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
>