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 Fri, 07 Jul 2017 19:46:52 GMT
On Jul 7, 2017 11:54, "Mikael Ståldal" <mikes@apache.org> wrote:

I agree that this is not the higest priority, and not a blocker for 2.9
release.


Agreed!

Gary




On 2017-07-05 23:31, Ralph Goers wrote:

> Feel free to take a look at the code. There a lot of other Jira issues
> that I think merit attention over this though, especially since I don’t
> consider it to be a problem.
>
> Ralph
>
> On Jul 5, 2017, at 12:18 PM, 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
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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