logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Failing to initialize log4j2 configuration dynamically
Date Wed, 05 Jul 2017 19:30:13 GMT
I am all for it but cannot help on this particular issue.

Gary

On Jul 5, 2017 12:18, "Mikael Ståldal" <mikes@apache.org> wrote:

> From a JSON standpoint, it would make sense to look up the nodes by name
> and ignore the order. Should be fairly easy I guess?
>
>
> On 2017-07-05 01:26, Ralph Goers wrote:
>
>> Like all of our configurations, the JSON input is read as a tree of
>> nodes. In all of our configurations, first we grab all the attributes from
>> the root node - those represent the attributes on the Configuration node.
>> Then all the JSON/XML/YAML/Properties nodes are converted to configuration
>> Nodes. At that point AbstractConfiguration takes over and performs the
>> actual configuration - it is agnostic of the input format.  Currently
>> AbstractConfiguration in the doConfigure() method requires that the
>> Properties node be the very first node in the configuration (for the
>> reasons I stated before). You could change that to find the Properties node
>> as any child element of Configuration but that will affect every
>> Configuration implementation, not just JSON.
>>
>> Ralph
>>
>> On Jul 4, 2017, at 2:08 PM, Gary Gregory <garydgregory@gmail.com> wrote:
>>>
>>> On Jul 4, 2017 13:50, "Mikael Ståldal" <mikes@apache.org> wrote:
>>>
>>> This is a bit strange from a JSON standpoint though, since the order of
>>> properties in a JSON object is not supposed to be significant.
>>>
>>>
>>> Agreed. What is the best way forward though?
>>>
>>> Gary
>>>
>>>
>>>
>>>
>>> On 2017-07-04 19:54, Ralph Goers wrote:
>>>
>>> This is not a bug but is intentional. Log4j processes configuration files
>>>> from beginning to end. It does not scan the file twice as would be
>>>> necessary if no order was required. Properties MUST come first so that
>>>> they
>>>> can be used by the configuration that follows. Because of that we will
>>>> generate an error if the properties are encountered after some other
>>>> element is found.
>>>>
>>>> Ralph
>>>>
>>>> On Jul 4, 2017, at 1:35 AM, Roman Sosnin <ROMANSO@il.ibm.com> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Opened PR in Github:
>>>>> https://github.com/apache/logging-log4j2/pull/91
>>>>> Thanks.
>>>>>
>>>>> Regards,
>>>>> Roman Sosnin
>>>>> Backend Server Side Developer
>>>>> Trusteer Security
>>>>> IBM Israel Software Lab
>>>>>
>>>>>
>>>>>
>>>>> From:   Gary Gregory <garydgregory@gmail.com>
>>>>> To:     Log4J Users List <log4j-user@logging.apache.org>
>>>>> Date:   20/06/2017 06:01
>>>>> Subject:        Re: Failing to initialize log4j2 configuration
>>>>> dynamically
>>>>>
>>>>>
>>>>>
>>>>> My guess is that it's a bug. Can't be sure until we see a failing unit
>>>>> test. At least, that's the easiest way.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Wed, Jun 21, 2017 at 12:06 AM, Roman Sosnin <ROMANSO@il.ibm.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>
>>>>>> Yea I've opened a Jira ticket for this issue. I will create a failing
>>>>>>
>>>>>> unit
>>>>>
>>>>> test as soon as I can & then upload it.
>>>>>>
>>>>>> For now any thoughts? Bug ? API Misuse?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Regards,
>>>>>> Roman Sosnin
>>>>>> Backend Server Side Developer
>>>>>> Trusteer Security
>>>>>> IBM Israel Software Lab
>>>>>> Office: +972-(0)74-7922783
>>>>>>
>>>>>>
>>>>>>
>>>>>> From:   Gary Gregory <garydgregory@gmail.com>
>>>>>> To:     Log4J Users List <log4j-user@logging.apache.org>
>>>>>> Date:   18/06/2017 19:14
>>>>>> Subject:        Re: Failing to initialize log4j2 configuration
>>>>>>
>>>>>> dynamically
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> I think there is a Jira ticket already about this, if not, do create
>>>>>> one
>>>>>> please. Are you available to create a failing unit test? A patch
for a
>>>>>>
>>>>>> fix
>>>>>
>>>>> as well perhaps?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Jun 18, 2017 3:00 AM, "Roman Sosnin" <ROMANSO@il.ibm.com>
wrote:
>>>>>>
>>>>>> Failing to initialize log4j2 configuration dynamically - supplying
a
>>>>>>
>>>>>>>
>>>>>>> JSON
>>>>>>
>>>>>> configuration node while json nodes are in random order.
>>>>>>>
>>>>>>> Environment: Linux - CentOS 6
>>>>>>> Component/s: Configurators
>>>>>>> Affects Version/s: 2.8.1
>>>>>>>
>>>>>>> For example, this one works for me:
>>>>>>> "configuration":
>>>>>>> { "status":"...", "name":"...", "properties":"...",
>>>>>>> "appenders":"...",
>>>>>>> "loggers":"..." }
>>>>>>> But this one fails:
>>>>>>> "configuration":
>>>>>>> { "status":"...", "name":"...", "appenders":"...", "loggers":"...",
>>>>>>> "properties":"..." }
>>>>>>> PAY ATTENTION: "properties" node is the last node and not 3rd.
>>>>>>> Initializing the config programmatically this way:
>>>>>>> JsonNode logObject =
>>>>>>> ConfigManager.getInstance().getContainerDefinition().at(
>>>>>>> CONFIG_LOGGING_JAVA_NODE);
>>>>>>> InputStream stream = new
>>>>>>> ByteArrayInputStream(logObject.toString().getBytes());
>>>>>>> ConfigurationSource source = new ConfigurationSource(stream);
>>>>>>> Configuration ourConfig = new
>>>>>>> JsonConfiguration(LoggerContext.getContext(), source);
>>>>>>> Configurator.initialize(ourConfig);
>>>>>>> where logObject is the actual log4j2 JSON config node.
>>>>>>> Any thoughts? Bug? API Misuse?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Roman Sosnin
>>>>>>> Backend Server Side Developer
>>>>>>> Trusteer Security
>>>>>>> IBM Israel Software Lab
>>>>>>> Office: +972-(0)74-7922783
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message