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