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