Re: Failing to initialize log4j2 configuration dynamically

2017-07-07 Thread Gary Gregory
On Jul 7, 2017 11:54, "Mikael Ståldal" <mi...@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 <mi...@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 <garydgreg...@gmail.com>
>>>> wrote:
>>>>
>>>> On Jul 4, 2017 13:50, "Mikael Ståldal" <mi...@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 <roma...@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 <garydgreg...@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 <roma...@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
>>>>>>>
>>>&g

Re: Failing to initialize log4j2 configuration dynamically

2017-07-07 Thread Mikael Ståldal
I agree that this is not the higest priority, and not a blocker for 2.9 
release.



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 <mi...@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 <garydgreg...@gmail.com> wrote:

On Jul 4, 2017 13:50, "Mikael Ståldal" <mi...@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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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" <roma...@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











Re: Failing to initialize log4j2 configuration dynamically

2017-07-05 Thread Ralph Goers
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 <mi...@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 <garydgreg...@gmail.com> wrote:
>>> 
>>> On Jul 4, 2017 13:50, "Mikael Ståldal" <mi...@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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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
>&g

Re: Failing to initialize log4j2 configuration dynamically

2017-07-05 Thread Gary Gregory
I am all for it but cannot help on this particular issue.

Gary

On Jul 5, 2017 12:18, "Mikael Ståldal" <mi...@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 <garydgreg...@gmail.com> wrote:
>>>
>>> On Jul 4, 2017 13:50, "Mikael Ståldal" <mi...@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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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
>>>>>
>>>>>
>>>>>>
>>>

Re: Failing to initialize log4j2 configuration dynamically

2017-07-05 Thread Mikael Ståldal
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 <garydgreg...@gmail.com> wrote:

On Jul 4, 2017 13:50, "Mikael Ståldal" <mi...@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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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" <roma...@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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org




-
To unsubscribe, e-mail: log4j-use

Re: Failing to initialize log4j2 configuration dynamically

2017-07-04 Thread Ralph Goers
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 <garydgreg...@gmail.com> wrote:
> 
> On Jul 4, 2017 13:50, "Mikael Ståldal" <mi...@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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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" <roma...@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":"..

Re: Failing to initialize log4j2 configuration dynamically

2017-07-04 Thread Gary Gregory
On Jul 4, 2017 13:50, "Mikael Ståldal" <mi...@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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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" <roma...@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-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org


Re: Failing to initialize log4j2 configuration dynamically

2017-07-04 Thread Mikael Ståldal
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.



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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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" <roma...@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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org




-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org



Re: Failing to initialize log4j2 configuration dynamically

2017-07-04 Thread Ralph Goers
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 <roma...@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 <garydgreg...@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 <roma...@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 <garydgreg...@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" <roma...@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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org



Re: Failing to initialize log4j2 configuration dynamically

2017-07-04 Thread Roman Sosnin
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 <garydgreg...@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 <roma...@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 <garydgreg...@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" <roma...@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
> >
> >
>
>
>
>
>






Re: Failing to initialize log4j2 configuration dynamically

2017-06-19 Thread Gary Gregory
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 <roma...@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 <garydgreg...@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" <roma...@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
> >
> >
>
>
>
>
>


Re: Failing to initialize log4j2 configuration dynamically

2017-06-19 Thread Roman Sosnin
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 <garydgreg...@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" <roma...@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
>
>






Re: Failing to initialize log4j2 configuration dynamically

2017-06-18 Thread Gary Gregory
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"  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
>
>