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