Re: Failing to initialize log4j2 configuration dynamically
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
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
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
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
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
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
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
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
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
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
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
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
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 > >