Re: [DOC] Make use of "common" logging website pages (security, downloads etc. pp)

[Apache]

+1

Ralph

> On Apr 25, 2024, at 5:00 AM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> By accident, I stumbled across this issue today:
> https://github.com/apache/logging-log4cxx/issues/370
> 
> We think we should use the standard websites across all our repositories as 
> suggested.
> This includes pages like "security", "downloads", "team" etc pp.
> 
> I am speaking of experience by rolling out the ASF privacy policy. While not 
> all projects use the foundation-wide, it has proven beneficial since there is 
> only one page to maintain.
> 
> Can we agree on this move? I think it's really important and lifts some 
> maintenance burden on the sub-components. 
> 
> Btw, I also think it highlights the fact that we are indeed only ONE project 
> :-)
> 
> If there are other pages than the ones mentioned, please bring them up so we 
> can unify them too.
> 
> Regards,
> Christian
> 
> 
> 
> --
> The Apache Software Foundation
> V.P., Data Privacy

Re: End-of-life date for `log4j-1.2-api`

[Apache]

My opinion is to drop it from 3.0.0. 2.x is going to live a long time still. By 
the time it dies Log4J 1.x will have been dead well over 15 years, maybe even 
20. That would give users plenty of time to be aware that they need to plan to 
upgrade.

Ralph

> On Apr 8, 2024, at 3:35 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> As you are probably aware, `log4j-1.2-api` is the second largest
> artifact we maintain. Yes, it is slightly larger than `log4j-api` and
> twice the size of JTL.
> 
> This library is mainly used:
> 
> 1. By some older frameworks/libraries that want to "help" users in
> their logging configuration. The amount of code that depends on
> `log4j-1.2-api` is usually measured in a dozen LoCs.
> 2. By some very old libraries that directly use Log4j 1.x for logging.
> I know a thing or two about Java archeology, but I couldn't give you a
> single example of such a library. The old legacy libraries I know
> mostly use JCL as a logging interface.
> 
> Therefore I am wondering what should we do with this library in the
> upcoming 3.0.0 release:
> 
> * should we drop it? The baseline of 3.0.0 is Java 17. Are there
> really applications that use Java 17 and at the same time use
> libraries that directly log to Log4j 1.x?
> * should we drop most of the code and move the two Log4j 1.x
> configuration factories to a new module?
> * should we just set an end-of-life date for the artifact and include
> it as it in Log4j 3.0.0?
> 
> Piotr
> 
> [1] https://github.com/apache/logging-log4j2/issues/2395

Re: [log4j] Remove `` in `main`

[Apache]

I’ve delayed answering because I can’t make up my mind. I am still thinking 
about this.

Ralph

> On Feb 12, 2024, at 12:58 PM, Piotr P. Karwasz  
> wrote:
> 
> Hi Volkan,
> 
>> On Mon, 12 Feb 2024 at 20:30, Volkan Yazıcı  wrote:
>> `StatusLogger` can be configured in following ways:
>> 
>>   1. Passing system properties to the Java process (e.g.,
>>   `-Dlog4j2.StatusLogger.level=INFO`)
>>   2. Providing properties in a `log4j2.StatusLogger.properties` file in
>>   the classpath
>>   3. Using Log4j configuration (i.e., `>   dest="out">`) in a `log4j2.xml` in the classpath. This is facilitated by
>>   `StatusConfiguration`.
>>   4. Programmatically (i.e., `StatusLogger.getLogger().setLevel(...)`)
> 
> You missed some of the possibilities:
> 
> 5. Setting `log4j2.debug` effectively switches the status logger from
> ERROR to TRACE. Before Volkan's PR #2249 this was the only way to
> debug problems that occur before a configuration is found and loaded:
> `log4j2.StatusLogger.level` was a NO-OP,
> 6. The property `log4j2.defaultStatusLevel` sets the default value of
> the "status" property of a configuration.
> 
> I support the idea of removing the "status" property from the
> configuration. We could reintroduce it later, but only after we figure
> out how to set the logging level separately from components of
> different configurations.
> 
> Piotr

Re: Usage examples of flow messages

[Apache]

Yes, add the missing method.

We use these methods A LOT. I suspect we are not alone.

Ralph

> On Feb 13, 2024, at 3:17 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> Our Logger interface contains 11 traceEntry/traceExit methods and 4
> deprecated entry/exit methods. As far as I have seen, only the
> deprecated ones are documented in [1].
> 
> I understand the purpose of some of them:
> 
> * entry(Object...) and its vararg-free version entry() can be used to
> log the parameters of a method call,
> * why is there not traceEntry(Object...) non-deprecated method?
> * exit(R), exit(), traceExit(R) and traceExit() log the return value
> of a method call.
> 
> For those that want to be creative, you can add a custom format
> specifier, so we have
> 
> * traceEntry(String, Object...) for input parameters,
> * traceExit(String, R) for the return value,
> * there is no traceExit(String) variant for methods returning void.
> 
> If someone wants the exit message to cite parameters again, you can
> use `traceExit(EntryMessage, R)` or `traceExit(EntryMessage)`.
> 
> However these seem pretty much useless to me:
> 
> * traceEntry(Supplier...), traceEntry(String, Supplier...) seem like
> overkill, since you usually log parameters that are already evaluated,
> * traceEntry(Message) and traceExit(Message, R) seem also overkill to
> me: if the user is not satisfied with providing a format specifier, he
> can call trace(Message) or trace(Supplier) with the message of his
> choice.
> 
> Should we add the missing `traceEntry(Object...)` and `traceExit()`
> methods and deprecate those above?
> 
> In general I don't see users today using those methods directly in
> their code. If they use them, they probably use AspectJ or a similar
> framework to decorate the messages. In such a case they probably use 2
> methods of the 15 above.
> 
> Piotr
> 
> [1] https://logging.apache.org/log4j/2.x/manual/messages.html

Re: [Log4j] If and how to document potential OOME

[Apache]

That is kind of my point. Anyone who logs an object that behaves this way is 
asking for trouble. It really sounds like an esoteric edge case to me. I don’t 
view this as a Log4J problem as the error wouldn’t even have Log4J in the stack 
trace.

Ralph

> On Jan 25, 2024, at 9:52 PM, Gary Gregory  wrote:
> 
> I have no control over this. I think this is a general problem with third
> party objects and toString(). There is no toString(fromHereToThere) or
> toStringReader() so I can't see a general way to deal with it. Even if I
> created a wrapper for the Object and called toString(), truncated and
> cached the result and have the wrapper return the shorter string in its
> toString(), I still would have toString()'d the original...
> 
> Gary
> 
>> On Thu, Jan 25, 2024, 11:33 PM Ralph Goers 
>> wrote:
>> 
>> OK. The only good way to handle that is to parse the YAML/JSON file while
>> streaming it and extract just the fields you want to include in the logs.
>> 
>> Ralph
>> 
>>> On Jan 25, 2024, at 6:40 PM, Gary Gregory 
>> wrote:
>>> 
>>> Well, it's worse than that because the object is an object created by
>>> parsing a YAML (or JSON) file, then the toString() of that object
>>> renders a String in some other format.
>>> 
>>> Gary
>>> 
>>> On Thu, Jan 25, 2024 at 7:45 PM Ralph Goers 
>> wrote:
 
 Volkan & Matt,
 
 Neither of those is going to help. The issue is that when the toString
>> method is called it reads a whole file in and stores it as a String. This
>> could cause the OOM error. Truncating it in a layout simply limits how much
>> of the String is printed. Even Gary’s proposal of calling substring() is
>> still going to operate on the whole String. He would really need a method
>> that accepts the max number of characters to read from the file.
 
 Ralph
 
> On Jan 25, 2024, at 2:49 PM, Volkan Yazıcı  wrote:
> 
> *[Just responding to Matt. I don't have an answer for Gary.]*
> 
> `JsonTemplateLayout` has `maxStringLength`, and related with it,
> `truncatedStringSuffix`.
> 
> On Thu, Jan 25, 2024 at 9:45 PM Matt Sicker  wrote:
> 
>> You can use the %maxLength{…}{N} pattern converter with PatternLayout
>> at
>> least. Unfortunately, I don’t think any other layouts support a
>> similar
>> option.
>> 
>>> On Jan 25, 2024, at 10:55, Gary D. Gregory 
>> wrote:
>>> 
>>> Hi All,
>>> 
>>> I'd like to ask how to if we can devise advice around an issue I ran
>> into this week.
>>> 
>>> One of our test suites processes about 40K files of test fixtures.
>> These
>> inputs are parsed, processed, and asserted. This randomly fails on a
>> call
>> to Logger#debug(), randomly in that it happens usually once per build,
>> somewhere in a logging call. But it usually fails with a call that
>> looks
>> like this:
>>> 
>>> logger.debug("This is fun" + myFunObject);
>>> 
>>> To simplify things, let's say that it turns out that after an
>> underlying
>> third party jar file version upgrade the call to
>> myFunObject#toString() no
>> longer returns Object#toString() but rather (again to simplify) the
>> contents of the file that was parsed to create myFunObject. This
>> toString()
>> can be megabytes. The solution is obvious:
>>> 
>>> logger.debug("This is fun", myFunObject::toString)
>>> 
>>> And our CI builds no longer randomly fail since our default logging
>> does
>> not log at the debug level.
>>> 
>>> A better solution could be:
>>> 
>>> logger.debug("This is fun", () -> myFunObject.toString().substring(0,
>> 100))
>>> 
>>> where I still want _some_ information better than making my own
>> toString() with System#identityHashCode(Object) or somesuch. Sure,
>> .toString() is still called but it does not make it down into
>> logging. In
>> my case the OOME happened in myFunObject::toString so the substring()
>> example would not have worked.
>>> 
>>> My question is: Should we document some general advice on this
>> pattern
>> and what should the advice be? Would it make sense to have some
>> features
>> where we truncate/reject Strings above a threshold. And yes, calling
>> myFunObject.toString() can still still get me in trouble.
>>> 
>>> Gary
>>> 
>> 
>> 
 
>> 
>> 

Re: Nullability annotations

[Apache]

If this is a runtime dependency then I am against using it in Log4J api and 
core.

Ralph

> On Jan 2, 2024, at 3:17 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> Matt made an interesting proposal to use JSpecify nullability
> annotations in Log4j:
> 
> https://github.com/apache/logging-parent/issues/88
> 
> I am a big fan of nullability annotations but in my professional
> experience they are worthless, unless the whole team agrees to use
> them and how to introduce them.
> 
> IMHO we should:
> 
> * create a branch that will differ from `main` only for the present
> of nullability annotations,
> * depend directly (scope `provided`) on JSpecify, although this might
> cause issue reports like this one [1],
> * only merge the changes of one module at a time (starting with `log4j-api`),
> * start by marking all fields and return types as `@Nullable` and all
> parameters as `@NonNull`,
> * only merge the change if a tool (NullAway/Checker Framework)
> guarantees that the code is NPE-free.
> * target 3.1.x as the first release with nullability annotations.
> 
> What do you think?
> 
> Piotr
> 
> [1] https://github.com/apache/logging-log4j2/issues/2144

Re: Change semantics of `Throwable` parameters

[Apache]


I agree with everything Remko said plus these extra comments.

Throwing is a convenience method to standardize the output when an application 
will be throwing an exception. That, of course, means it isn’t a required 
method. I doubt it is used very much. Of course, catching is its companion but 
I would bet it is used even less.

We use the entry/exit stuff everywhere. I have not seen a replacement for it 
that provides the same functionality so I would not want it removed.

I agree that AbstractLogger should have as few methods as possible that need to 
be overridden by the implementation.

Ralph

> On Nov 23, 2023, at 4:31 AM, Piotr P. Karwasz  wrote:
> Hi Matt,
> 
> On Tue, 21 Nov 2023 at 23:22, Matt Sicker  wrote:
>> 
>> This sounds like it might be a good basis for figuring out a parallel v3 API 
>> for a “hard to mis-use” style API. However, once you go that route, you 
>> start to wonder how useful templated log messages are when you can capture a 
>> lambda instead. Parameterized log messages might work better as structured 
>> log messages, something that is awkward to use in the API at the moment.
> 
> If we'll create a separate `v3.Logger` interface I would clean it up
> from many methods, e.g.:
> 
> * getLevel() and getName(): how are these useful for the user? An `if
> (logger.getLevel() == Level.INFO)` should be replaced by `isEnabled`,
> * getMessageFactory() and getFlowMessageFactory() (the latter is my
> fault): again these are not useful to the user. If I need a message
> factory, it will be a different message factory,
> * printf(): a better approach is to use StringFormatterMessageFactory
> for the logger,
> * catching(Throwable): can be replaced with `error(Object)` and the
> semantics described in this thread,
> * throwing: does anybody use it? Maybe it could stay,
> * entry/exit, traceEntry/traceExit: I can not imagine using these on
> each method (or important method). I'd rather use AspectJ pointcuts
> instead (or a @LogTrace annotation),
> * methods that use `MessageSupplier` like `info(MessageSupplier)`:
> couldn't these be integrated into the logic of `info(Supplier)`?
> * the `is*Enabled` methods are prone to misuse: a snippet like:
> 
> if (logger.isDebugEnabled()) {
>  logger.debug(MARKER, "Hello world!");
> }
> 
> will not print any message if the level of the logger is less specific
> than DEBUG, even if the user asks for **all** MARKER messages to be
> printed.
> 
> IMHO opinion `v3.AbstractLogger` should only have 2 abstract methods:
> * logMessage(Level level, Marker marker, String fqcn,
> StackTraceElement location, Message message, Throwable throwable)
> * isEnabled(Level level, Marker marker, String fqcn,
> StackTraceElement location, Message message, Throwable throwable)
> 
> Piotr

Re: [log4j] Unstable tests on Windows

[Apache]

In my experience they never get fixed. To be honest, when I was doing the 
releases I would have these failures investigated to determine if it was a 
trait problem vs a problem in the code being released. If it was the latter I 
would cancel the vote. The only time tests should be disabled is if we know it 
is a problem in the test but can’t figure out how to fix it.

I also don’t ever recall Gary ever having more than one or two tests fail in a 
run.

Ralph

> On Nov 20, 2023, at 5:00 AM, Volkan Yazıcı  wrote:
> 
> I am not asking to disable Windows tests. I am asking to disable tests
> and only those tests that have a failure rate on Windows higher than,
> say, 30%. To be precise, I think there are 2-3 of them dealing with
> network sockets and rolling file appenders. I am not talking about
> dozens or such.
> 
> After disabling them, we can create a ticket referencing them. So that
> interested parties can fix them.
> 
>> On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz
>>  wrote:
>> 
>> Hi Volkan,
>> 
>>> On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı  wrote:
>>> 
>>> As Gary (the only Windows user among the active Log4j maintainers,
>>> AFAIK) has noticed several times, Log4j tests on Windows are pretty
>>> unstable. It not only fails on Gary's laptop, but Piotr and I need to
>>> give Windows tests in CI a kick on a regular basis. Approximately one
>>> out of three CI runs fails on Windows. Piotr already improved the
>>> situation extensively, though there are still several leftovers that
>>> need attention.
>>> 
>>> Unless somebody steps up to improve the unstable Windows tests, I
>>> would like to disable those only for the WIndows platform.
>> 
>> Please don't. Windows has an annoying file locking policy that
>> prevents users from deleting files with open file descriptors, but
>> that is one of the few ways to detect resource leakage we have.
>> 
>> Tests running on *NIXes will ignore problems with open file
>> descriptors and delete the log files, but on a production system those
>> leaks will accumulate and cause application crashes. We had such a
>> leak, when we used `URLConnection#getLastModified` on a `jar:...` URL.
>> This call caused file descriptor exhaustion on both Windows and
>> *NIXes, but only the Windows test was able to detect it.
>> 
>> Piotr,
>> who never thought would ever defend Microsoft Windows.
>> 
>> PS: Gary reports the failures, but always runs the build again until
>> it succeeds, even on Friday 13th, when he had to wait until Saturday
>> 14th for the test run to succeed.

Re: Features for 3.x was: Why is JNDI still necessary?

[Apache]

I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding 
anything. Personally I would prefer the monitoring to be in a separate repo but 
I am ok with adding it to the main build. IAM all for moving async out but 
unless it can be done quickly I’d rather do it in a future 3.x release. The 
same is generally true for your other bullets as well.

The point of alphas and betas is to find regressions. We need to fix them.

Ralph

> On Nov 2, 2023, at 1:17 AM, Piotr P. Karwasz  wrote:
> 
> Hi Ralph,
> 
>> On Thu, 2 Nov 2023 at 08:39, Piotr P. Karwasz  
>> wrote:
>> Hi Ralph,
>>> On Thu, 2 Nov 2023 at 05:53, Ralph Goers  wrote:
>>> JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to 
>>> use “versioned” jars so it can work in Java 8 and Java 11+.  3.x only 
>>> supports Java 11 and is really where we want to focus our attention. I wish 
>>> everyone would agree with this so we could get 3.0.0 GA out as quickly as 
>>> possible but people still want to (seemingly endlessly) tinker with 3.x. 
>>> Once 3.x I would like to announce that 2.x’s EOL is directly tied to the 
>>> longevity of Java 8. Once Java 8 falls below 10% usage it will be EOL’d.  
>>> So I would rather everyone focus their energy on 3.x and not make any more 
>>> changes to 2.x other than bug-fixes.
> 
> I agree that 3.x should have a fixed number of features. We should
> probably agree on them and close the list.
> 
> There are things that I would like to add to 3.x, that you won't allow
> me to do in a minor release:
> * drop JMX support in 3.0.x: I have a basic understanding on how
> Micrometer works. In 3.1.x I could restore the monitoring capabilities
> of Log4j Core with a `log4j-core-jmx` module and possibly a
> `log4j-core-micrometer` module (or `micrometer-log4j-core` if the
> Micrometer project accepts such a contribution). This could probably
> be done by just extending the public `log4j-core` API,
> * move the code that depends on LMAX disruptor to a separate module
> (`log4j-async-logger`, but I am open to suggestions for a better
> name),
> * move the code that depends on Conversant disruptor to a separate
> module (`log4j-async-queue-disruptor` for lack of a better name),
> * move the code that depends on JCTools to a separate module
> (`log4j-async-queue-jctools`); the same applies to JTL,
> * move the code that depends on Commons Compress to a separate module
> (`log4j-file-compress`),
> * move the code that depends on JAnsi to a separate module
> (`log4j-console-jansi`),
> * remove the Jackson-based configuration factories (to be restored in
> 3.1.x) or move them to a different module,
> * remove the `log4j-jndi` dependency from `log4j-jdbc` by creating
> `log4j-jdbc-jndi`.
> * drop `log4j-slf4j-impl`, since as far as I know the 1.7.x branch is
> not supported any more by Ceki; I know this contains some support for
> structured events from `slf4j-ext` 1.7.25 that is not present in
> `log4j-slfj42-impl`, but I suppose this is no longer needed.
> 
> There are some changes we are waiting for
> (https://github.com/apache/logging-log4j2/milestone/2):
> * LoggerContext-scoped properties, plugins, etc. I am not sure we can
> introduce this in a minor release. I recently extended JCL to use the
> Log4j API and SLF4J and noticed that Logback does not allow multiple
> logger contexts. We do, but those are useless if Log4j Core in the
> system classloader can't pick up plugins from other classloaders. A
> little example: in Tomcat the system classloader basically contains
> only the logging framework and `log4j-core` can not pick up
> `log4j-web` in the classloader with all the Servlet API classes,
> * Recycler API: I doubt we can introduce a uniform way to cache
> objects without breaking changes. Volkan will pick this up shortly, so
> be patient,
> * regressions, regressions and once again regressions. One is even
> reported (https://github.com/apache/logging-log4j2/issues/1439) and
> has been sitting there for some time.
> 
> Piotr

Re: Why is JNDI still necessary?

[Apache]


If you want separate logging config files in an EJB environment using JNDI is 
pretty much required. The same would be true for any properties needed in the 
configuration. 

In any case, despite Piotr saying this is a majority vote, it is not. I will 
veto any attempt to remove JNDI components so one really needs to view this 
vote in the light that any component receiving a -1 vote cannot be removed as 
it will simply get a -1 when the PR/commit is attempted from whomever gave the 
-1 vote. In other words, this is NOT a procedural vote but a code modification 
vote that is taking place before the code is modified.

Ralph

> On Nov 1, 2023, at 3:13 AM, Christian Grobmeier  wrote:
> 
> On Wed, Nov 1, 2023, at 00:01, Ralph Goers wrote:
>> There is a difference between a JEE application that only uses servlets 
>> vs one that uses EJBs. At a former employer we often used JBoss to run 
>> servlets even though we had no EJBs. In an environment with EJBs I am 
>> not sure how you can distinguish the various components from each other 
>> without JNDI.
> 
> I understand that in the EJB world you would need JNDI, but I fail to 
> understand how your EJBs would use Log4j JNDI features? It appears to me that 
> while EE world needs it, the Logging world does not necessary need it
> 
>> 
>> Ralph
>> 
>>> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı  wrote:
>>> Piotr, I think it is important to differentiate what is a requirement and
>>> what is just another way of achieving something. My employer has several
>>> Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have a
>>> single JNDI usage I know of.
>>> I would like to hear "the functional need" that can't be done in a JEE
>>> application without JNDI. My emphasis is important, since "using JNDI" is
>>> not a functional need.
>>> On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz 
>>> wrote:
 Hi Christian,
 On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier 
 wrote:
> I am surprised we still have JNDI in the code at all, but this made me
 curious:
> why do JEE users need JNDI features for logging? Why can't they just use
 the normal log mechanism?
 JNDI is basically a bean container/factory that allows Java EE
 applications to retrieve database connection pools, message queues or
 mail sessions (and remote code as a bonus).
 For the JMS appender, JNDI is essential.
 For the JDBC appender there is an alternative: DBCP2 can provide a
 database connection pool via a special connection string.
 The SMTP appender does not use JNDI as far as I remember.
 Of course there is an alternative to JNDI also in the Java EE world
 (CDI), but it doesn't work with simple servlet containers like Tomcat.
 Piotr

Re: [log4j] Annotation processing alternatives

[Apache]

We really don’t have much choice. With JPMS you really need to use 
ServiceLoader to locate things like plugins across modules. Using a s file like 
spring.factories doesn’t really help anyway. You wouldn’t want to force users 
to hand create the entries in that file and so would use annotations and a 
processor to populate it, which is exactly what we are doing.

Ralph

> On Oct 23, 2023, at 10:12 AM, Gary Gregory  wrote:
> 
> Staying from the built-in Service Loader is a recipe for even more
> custom code and complications. I say we stick with the built-in
> Service Loader.
> 
> Gary
> 
>> On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz
>>  wrote:
>> 
>> Hi Matt,
>> 
>>> On Sun, 22 Oct 2023 at 22:49, Matt Sicker  wrote:
>>> So now we come to your question about a factories file. That’s an 
>>> interesting idea, though it’s extremely similar to what we’re doing here 
>>> with ServiceLoader (though the split between META-INF/services/ files and 
>>> module-info.java provides/uses entries is confusing). Moving away from 
>>> ServiceLoader to a custom mechanism might be more flexible, though I’m not 
>>> very knowledgeable about how Java modules work with them.
>> 
>> I think that `ServiceLoader` is the only standard feature that is
>> supported by both OSGi and JPMS. If we move away from it, we'll need
>> some custom code to support it (or `opens`, etc). I wouldn't go that
>> way.
>> 
>> Piotr

Re: [log4j] Project URLs per major version

[Apache]

I am ok with 1 and 2, but not 3. Doing that means older releases web sites are 
no longer available. Just because the latest includes release notes for all 
versions doesn’t mean it fully documents what was in prior releases. However, I 
am not surprised you are suggesting this as I posted in an earlier email that 
CI of the web site would be difficult due to this.

Ralph

> On Oct 22, 2023, at 2:03 PM, Piotr P. Karwasz  wrote:
> 
> Hi Volkan,
> 
>> On Sun, 22 Oct 2023 at 22:20, Volkan Yazıcı  wrote:
>>   3. *Don't create a new folder for every release, but override the `2.x`
>>   folder.*
>>  - This is okay, since we keep backward compatibility in minor+patch
>>  releases and explicitly provide version for features that are added 
>> later
>>  on (e.g., "starting from 2.17.0 Log4j provides X...")
>>  - We can set up CI jobs to periodically populate `1.x`, `2.x`, `3.x`,
>>  `4.x`, etc. websites and avoid the need to generate the website once and
>>  for all.
>>  - We will stop polluting the folder structure.
> 
> +1 on keeping just `1.x`, `2.x`, etc.
> 
> We just need to keep in mind that not all public methods have a
> correct `@since` Javadoc tag. We would need to fix that.
> 
> Piotr

Re: Staging sites and repo convention

[Apache]

+1

Fix the staging site. Defer talk about anything else until that is done.

Ralph

> On Oct 22, 2023, at 5:05 PM, Christian Grobmeier  wrote:
> 
> 
> 
>> On Sun, Oct 22, 2023, at 21:54, Volkan Yazıcı wrote:
>> It has been a long thread and I want to capture the result: *there are no
>> objections to Piotr's proposal, right?* If not, please say so.
> 
> I am not objecting, but I would like to point out that logging.s.a.o is in 
> bad shape today, and I don't know why (in detail). I'd love to have this 
> working again before we move on to a different system. 
> If you know how to fix the system in a way that works with the original 
> proposal in one go, I am okay with it, too. However, I am afraid we are 
> touching too many wheels at once and navigating in a bad state.
> 
> 
> 
>> 
>> To avoid misunderstanding, I want to repeat certain points one more time:
>> 
>>   1. All existing logging.apache.org URLs will remain as is – no changes
>>   there.
>>   2. Instead of using logging.*staged.*apache.org*/foo*, we will use
>>   logging*-foo.staged.*apache.org for staging websites.
>>   3. Log4j Scala, Kotlin, Tools, and Transformation website content will
>>   be moved from `logging-log4j-site` repository to `logging-log4j-scala`,
>>   `logging-log4j-kotlin`,  `logging-log4j-tools`, and
>>   `logging-log4j-transformation` repositories, respectively.
>> 
>> 
>> On Thu, Oct 19, 2023 at 10:03 AM Piotr P. Karwasz 
>> wrote:
>> 
>>> Hi,
>>> 
>>> Since now we have a fast release process It might happen (and it
>>> already did) that the voting periods for releases will not be
>>> disjoint.
>>> 
>>> That is why I would like to introduce a convention on the procedure to
>>> stage websites and Nexus repositories.
>>> 
>>> For websites I would propose:
>>> 
>>> 1. Every Git code repository uses a different staging domain name.
>>> E.g. `logging-log4j2` would set:
>>> 
>>> staging:
>>>  profile: log4j2
>>> 
>>> which will result in a https://logging-log4j2.staged.apache.org URI.
>>> For the `logging-log4j-site` website repo this will also entail that
>>> it will have multiple staging branches.
>>> 2. The `asf-staging` should not be protected. Before staging a website
>>> the Release Manager would perform:
>>> 
>>> git reset --hard origin/asf-site
>>> git push -f
>>> 
>>> hence ensuring that moving changes from the staging branch to
>>> `asf-site` will be usually a fast-forward and a simple cherry-pick
>>> `origin/asf-site..asf-staging` at worst.
>>> 
>>> For the staging Nexus repo I would propose using a comment to close
>>> the repo in the format:
>>> 
>>> `` version `` RC1
>>> 
>>> For example Volkan used "`logging-parent` version `10.2.0` RC`" on the
>>> 1204 repo and we can easily guess what that repo contains. ;-)
>>> 
>>> Piotr
>>> 
>>> PS: Maybe we could drop the `*-site` Git repositories except
>>> `logging-site` and move their content to an `asf-site/asf-staging`
>>> branch of the corresponding code repo.
>>> 

Re: Log4j JMX GUI (was: [ANNOUNCE] Apache Log4j 2.21.0 released)

[Apache]

Yes

Ralph

> On Oct 17, 2023, at 4:31 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
>> On Tue, 17 Oct 2023 at 13:13, Piotr P. Karwasz  
>> wrote:
>>> On Tue, 17 Oct 2023 at 12:37, Gary Gregory  wrote:
>>> 
>>> I got hit at work with the loss of log4j-jmx-gui. Is log4j-jmx-gui 2.20.0
>>> compatible with log4j 2.21.0?
>> 
>> Yes, it is, but there should be a `log4j-jmx-gui` version 2.21.0 out there:
>> 
>> https://github.com/apache/logging-log4j-jmx-gui/releases/tag/rel%2F2.21.0
>> 
>> I am not sure why I can't find it on Maven Central.
> 
> Due to a typo in the `pom.xml`, `log4j-jmx-gui` was published in the
> `org.apache.logging` group.
> Should we release it again with the correct Maven group?
> 
> Piotr

Re: Log4j Audit

[Apache]

Sure

Ralph

> On Oct 10, 2023, at 2:05 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> Since Log4j Audit will not be archived, could someone update its
> dependencies? Dependabot has lots of security alerts about it:
> 
> https://github.com/apache/logging-log4j-audit/security/dependabot
> 
> Piotr

Re: Migrating the landing page

[Apache]

You have to be kidding me. I now need to use Docker to build the web site? And 
that is somehow simpler?

Ralph

> On Sep 22, 2023, at 2:03 PM, Christian Grobmeier  wrote:
> 
> 
> 
>> On Fri, Sep 22, 2023, at 22:08, Ralph Goers wrote:
>> Personally, I hate all these tools. I picked JBake simply because I 
>> could figure out how to run it with a simple Maven command.
>> 
>> I really don’t see how you can make it any simpler by changing the 
>> tooling. If you look at the instructions they are all git commands 
>> except for “mvn install”.
>> 
>> The current web site supports markdown and asciidoc.
>> 
>> I am not in favor of changing the tooling for the sake of changing the 
>> tooling.  I am in favor of changing the tooling if there is some major 
>> tangible benefit. I have always wanted to use tooling that would let us 
>> edit the pages in a GUI editor similar to like Wix or Squarespace do. I 
>> despise having to write things in Markdown or Asiciidoc and then run a 
>> tool so I can preview what it is going to look like.
>> 
>> In other words, I want the ease of editing and maintaining the web site 
>> to drive the tooling decision, not the other way around.
> 
> Currently, there are 10 steps listed for deploying the website.
> I do "git commit && push"
> 
> Currently, we have to install JBake
> In my scenario, I use Docker.
> 
> As an example, for the privacy website to check:
> docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build 
> --mount type=volume,dst=/root/build/node_modules -it 
> apache/privacy_apache_org serve --watch --incremental
> 
> There are significant benefits in this, such as speed of deployment, support 
> of infra, etc pp. 
> I don't see any reason to stick with JBake.
> 
> I understand you don't like static site generators, but in this case, a less 
> frequently updated website, I see benefits: easy blogging support and ASF 
> support. Additionally, Docker support.
> 
> There is also GUI support for Jekyll and Hugo, but I don't like it. There is 
> none for JBake to my knowledge.
> 
> I an not changing the tooling because I like Jekyll better, but because it is 
> a standard, I have autodeploy tools ready and it generally is better 
> understood than JBake.
> 
> Kind regards,
> Christian
> 
> 
>> 
>> Ralph
>> 
>>>> On Sep 22, 2023, at 11:47 AM, Christian Grobmeier  
>>>> wrote:
>>> 
>>> Hello,
>>> 
>>> the current landing page:
>>> https://logging.apache.org/
>>> 
>>> is done with JBake. We have rather complicated instructions on how to 
>>> re-generate the landing page:
>>> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites
>>> 
>>> The Infra team recommends Pelican or Jekyll to create these kinds of pages. 
>>> I have in-depth knowledge of Jekyll and would like to propose migrating the 
>>> current landing page to Jekyll.
>>> 
>>> The benefits:
>>> 
>>> - autodeploy of our changes
>>> - great support of blogging (I'd like to create one)
>>> - easy handling and supported by Infra
>>> - writing content in Markdown
>>> 
>>> I am aware that we have a discussion open on how to do documentation in the 
>>> future. I would still like to migrate the page asap and  - if deemed 
>>> necessary - touch it again later.
>>> 
>>> So far, I will leave all design/content intact until migrated, and come 
>>> back with additional changes (as the blog) after migration to be discussed 
>>> separately.
>>> 
>>> If there are no objections, I will start with this move sometime next week.
>>> 
>>> Thanks!
>>> Christian
>>> 
>>> --
>>> The Apache Software Foundation
>>> V.P., Data Privacy

Re: Deprecating modules in 2.x

[Apache]

Spring cloud config client is NOT part of Spring Boot 3. It adds a watcher for 
the config file. I never created a PR to add it to Sping Cloud Config.

Ralph

> On Sep 9, 2023, at 11:24 AM, Piotr P. Karwasz  wrote:
> 
> Hi Gary,
> 
>> On Sat, 9 Sept 2023 at 18:07, Gary Gregory  wrote:
>> 
>> Please do not drop appserver, mongodb4, jdbc-dbcp2.
> 
> What part of `appserver` are you using: Tomcat or Jetty 9.x? Should we
> keep Jetty 9.x support in 3.x (Jetty 10.x uses SLF4J and is not
> Jakartified).
> 
> I like the way this is going, so let's agree on a list of modules that
> could be dropped, vote on it and announce it on `log4j-user` to get
> user's opinion.
> 
> The current list of nominees:
> 
> 1  log4j-spring-boot (contained in Spring Boot 3.x)
> 2  log4j-spring-cloud-config-client (contained in Spring Boot 3.x?)
> 3  log4j-taglib
> 4  log4j-couchdb
> 5  log4j-kubernetes
> 6  log4j-jpa
> 7  log4j-mongodb3
> 8  log4j-docker
> 9  log4j-cassandra
> 
> From 3.x might I nominate:
> 
> 1  log4j-layout-jackson
> 2  log4j-csv
> 3  log4j-jeromq
> 4  log4j-layout-jackson-json
> 5  log4j-layout-jackson-xml
> 6  log4j-layout-jackson-yaml
> 
> Piotr

Re: Deprecating modules in 2.x

[Apache]

I agree with everything Gary says on this one. Furthermore, I still believe 
some of these should move to their own repo. 

Ralph

> On Sep 9, 2023, at 6:51 AM, Gary Gregory  wrote:
> 
> Hi All.
> 
>> * raise the Java requirements in 3.x to Java 17.
> +1 fine w/ me. FWIW, my day job is migrating from Java 11 to 17 ATM.
> 
>> * deprecate some modules in 2.x and drop them in 3.0.x, restore them if a 
>> user requests it in 3.1.x.
> This feels arbitrary. First, we say 100k downloads, but then we say:
> - "a big company with an internal Maven repo counts 1"
>  Count my day job in this category and our _large_ repo with _many_
> products and _many_ maintained versions.
> - except "+ some modules under the line that are deemed important" by
> what criteria? What's the point of setting an arbitrary "bar" if we
> are going to make _further_ arbitrary exceptions?
> It's just simpler to have no bar since all decisions will be
> arbitrary; for example not having mongodb4 will be a problem for me
> looking ahead and probably for the user who just reported an issue in
> that code.
> Each module should be evaluated and kept if anyone says "-1, please keep it".
> 
> Gary
> 
>> On Sat, Sep 9, 2023 at 3:15 AM Piotr P. Karwasz  
>> wrote:
>> 
>> Hi all,
>> 
>> In a Slack discussion Volkan proposed (among other things) to:
>> 
>> * raise the Java requirements in 3.x to Java 17. It is the same
>> requirement as Spring Boot 3.x has, so I don't see a reason to lower
>> the bar. Besides Java 21 will be an LTS.
>> * deprecate some modules in 2.x and drop them in 3.0.x, restore them
>> if a user requests it in 3.1.x.
>> 
>> While the number of downloads is not the only criterium (a big company
>> with an internal Maven repo counts 1, a student's project that tries
>> multiple version counts more), these are the stats for last month:
>> 
>> 1  log4j-bom 35178445
>> 2  log4j-api 30598923
>> 3  log4j-core15567816
>> 4  log4j-to-slf4j14036879
>> 5  log4j-slf4j-impl   8675173
>> 6  log4j-1.2-api  3454601
>> 7  log4j-jul  2120049
>> 8  log4j-web  1964937
>> 9  log4j-layout-template-json 1760437
>> 10  log4j-slf4j2-impl  1013605
>> 11  log4j-jcl   566636
>> 12  log4j-appserver 245029
>> 13  log4j-iostreams 209990
>> 14  log4j-spring-boot87578
>> 15  log4j-spring-cloud-config-client 38332
>> 16  log4j-jakarta-web37351
>> 17  log4j-jpl20295
>> 18  log4j-flume-ng   14055
>> 19  log4j-taglib 13989
>> 20  log4j-couchdb12781
>> 21  log4j-mongodb44623
>> 22  log4j-kubernetes  2618
>> 23  log4j-jpa 1252
>> 24  log4j-mongodb31143
>> 25  log4j-docker  1122
>> 26  log4j-cassandra898
>> 27  log4j-jakarta-smtp 741
>> 28  log4j-jdbc-dbcp2   708
>> 29  log4j-to-jul   297
>> 
>> I propose to have a bar at 100k, so we keep everything up to
>> `log4j-iostreams` + some modules under the line that are deemed
>> important.
>> 
>> I would keep `log4j-to-jul`, mainly because it is a third
>> implementation of the Log4j API and I used it at work, when I didn't
>> get the permission to use Log4j Core. NB: the `2.x` version of
>> `log4j-to-jul` will still work with the `3.x` version of `log4j-api`,
>> but it might require a modularized version to be fully compatible.
>> 
>> The stats of `log4j-appserver` are unexpected. I guess the Jetty 9.x
>> support drives it (Jetty 9.x reached EOL) more than the Tomcat
>> support. So we could even deprecate this one and create a
>> `log4j-tomcat` module or drop it entirely (I will pick up the Tomcat
>> part in my `eu.copernik` modules).
>> 
>> Piotr
>> 
>> PS: The downloads of the 3.x modules split from `log4j-core` are not
>> that great either. In the third column I renormalize them so that
>> `log4j-core` has 15M downloads:
>>log4j-core 78627  15567816
>> 1  log4j-jdbc55 10890
>> 2  log4j-layout-jackson  55 10890
>> 3  log4j-jndi44  8712
>> 4  log4j-script  44  8712
>> 5  log4j-kafka   40  7920
>> 6  log4j-jms 39  7722
>> 7  log4j-csv 38  7524
>> 8  log4j-jeromq  37  7326
>> 9  log4j-smtp37  7326
>> 10  log4j-layout-jackson-json 33  6534
>> 11  log4j-layout-jackson-xml  30  5940
>> 12  log4j-layout-jackson-yaml 24  4752

Re: [VOTE] Release Apache Logging Parent 1.10.0

[Apache]

I haven’t looked yet but as I recall Volkan is merging the source and binary 
artifacts into a single zip. So I would expect the zip in the zip is the source.

Ralph

> On Sep 5, 2023, at 4:30 AM, Gary Gregory  wrote:
> 
> Something is wrong with the source zip file at
> https://dist.apache.org/repos/dist/dev/logging/logging-parent/: It's a
> zip that contains a zip. Why? It should be a direct reflection of what
> is in the repository IMO.
> 
> Also, the links in the vote email should point to
> https://dist.apache.org/repos/dist/dev/logging/logging-parent/ not
> https://dist.apache.org/repos/dist/dev/logging such reviewed don't
> have to dig through folders.
> 
> Gary
> 
>> On Mon, Sep 4, 2023 at 3:33 PM Volkan Yazıcı  wrote:
>> 
>> This is a vote to release the Apache Logging Parent 1.10.0.
>> 
>> Source repository: https://github.com/apache/logging-parent
>> Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c
>> Distribution: https://dist.apache.org/repos/dist/dev/logging
>> Nexus: 
>> https://repository.apache.org/content/repositories/orgapachelogging-1113
>> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>> 
>> Please download, test, and cast your votes on this mailing list.
>> 
>> [ ] +1, release the artifacts
>> [ ] -1, don't release, because...
>> 
>> This vote is open for 72 hours and will pass unless getting a
>> net negative vote count. All votes are welcome and we encourage
>> everyone to test the release, but only the Logging Services PMC
>> votes are officially counted. At least 3 +1 votes and more
>> positive than negative votes are required.
>> 
>> # Release Notes
>> 
>> This minor release contains various improvements that we expect to
>> relieve the load on `pom.xml` and GitHub Actions workflows of
>> Maven-based projects we parent. This is of particular importance while
>> managing and cutting releases from multiple repositories.
>> See `README.adoc` for the complete list of features and their usage.
>> 
>> See [this `logging-log4j-tools` GitHub Actions workflow
>> run](https://github.com/apache/logging-log4j-tools/actions/runs/6070379396)
>> demonstrating a successful release cut using a SNAPSHOT version of
>> this `logging-parent` release. All preparations (release notes,
>> distribution ZIP, vote & announcement emails, etc.) are staged to both
>> Nexus and SVN and waiting the release manager to proceed. As a matter
>> of fact, this very release of `logging-parent` is cut by the very same
>> reusables too.
>> 
>> ## Changes
>> 
>> ### Added
>> 
>> * Added `changelog-export` profile to easily export changelogs to Markdown 
>> files
>> * Added `changelog-release` profile to easily move
>> `src/changelog/.?.x.x` contents to their associated release directory
>> * Added `deploy` profile to ease the Maven `deploy` goal
>> * Added `distribution` profile to easily create a distribution file
>> containing Git-tracked sources, release notes, binary attachments,
>> `NOTICE.txt`, etc.
>> * Documented release instructions (i.e., `RELEASING.md`)
>> * Added `release` profile to share common release-specific Maven 
>> configuration
>> * Added reusable GitHub Actions workflows to share CI boilerplate for
>> other repositories
>> * Switched to using `log4j-changelog-maven-plugin` for managing
>> changelog and release notes

Re: [Log4j] GitHub Discussions

[Apache]

+1

Ralph

> On Aug 24, 2023, at 4:01 AM, Christian Grobmeier  wrote:
> 
> +1
> 
> 
>> On Thu, Aug 24, 2023, at 09:26, Volkan Yazıcı wrote:
>> Piotr shared a very good observation (in a private Slack post
>> <https://the-asf.slack.com/archives/C4TQW0M5L/p1692821047719209>) that
>> users ask questions in GitHub Issues, we point them to the mailing list,
>> and they disappear. See this ticket
>> <https://github.com/apache/logging-log4j2/issues/1722> for an example.
>> Consequently, Matt proposed using GitHub Discussions. Robert added Pulser
>> already has it enabled <https://github.com/apache/pulsar/discussions>. I
>> think many users are more keen on forums, GitHub, StackOverflow, etc. We
>> should position ourselves where our users expect us to be. In that
>> regard, *GitHub
>> Discussions sounds like a great idea and I propose experimenting with it*:
>> 
>>   - Enable GitHub Actions
>>   - Update our support page accordingly
>>   - Update README
>> 
>> One would think this should be a matter of a `.asf.yaml` one-liner, but 
>> it
>> is not
>> <https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=Git+-+.asf.yaml+features#Git.asf.yamlfeatures-GitHubDiscussions>
>> :
>> 
>> *"GitHub Discussions is currently a beta feature and does not have an API
>> endpoint. Until this is addressed, please open an Infra Jira ticket with a
>> link to a consensus discussion thread for your project."*
>> 
>> 
>> Hence, *I need your approval in the form of a reply to this post*.

Re: JDK 20 is now GA, JDK 21 Early-Access builds, and 2 important heads-up!

[Apache]

We need to look into this now that scoped variables are present.

Ralph

> On Mar 28, 2023, at 5:46 AM, David Delabassee  
> wrote:
> 
> Welcome to the latest OpenJDK Quality Outreach update!
> 
> Last week was busy as we released both Java 20 and JavaFX 20. To celebrate 
> the launch, we hosted a live event focused on Java 20, i.e. Level Up Java 
> Day. All the sessions recordings will be made available shortly on the 
> YouTube Java channel.
> 
> Some recent events shown us that it is useful to conduct tests using the 
> latest early-access OpenJDK builds. This will benefit the OpenJDK codebase 
> but also your own codebase. Sometime, a failure could be due to an actual 
> regression introduced in OpenJDK. In that case, we obviously want to hear 
> about it while we can still address it. But sometime, a failure could also be 
> due to a subtle behaviour change… that works as expected. Regardless of if 
> it's a bug or a test that is now broken due to a behaviour change, we want to 
> hear from you. In the latter case, it might also mean that we should probably 
> communicate more about those changes even if they might seem subtle. On that 
> note, please make sure to check all the 2 Heads-Up below: "Support for 
> Unicode CLDR Version 42" and "New network interface names on Windows".
> 
> So please, let us know if you observe anything using the latest early-access 
> builds of JDK 21.
> 
> 
> ## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42
> 
> The JDK's locale data is based on the Unicode Consortium's Unicode Common 
> Locale Data Repository (CLDR). As mentioned in the December 2022 Quality 
> Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42 [3], which 
> was released in October 2022. This version includes a "more sophisticated 
> handling of spaces" [4] that replaces regular spaces with non-breaking spaces 
> (NBSP / `\u00A0`) or narrow non-breaking spaces (NNBSP / `\u202F`):
> - in time formats between `a` and time
> - in unit formats between {0} and unit
> - in Cyrillic date formats before year marker such as `г`
> 
> Other noticeable changes include:
> * " at " is no longer used for standard date/time format ’ [5]
> * fix first day of week info for China (CN) [6]
> * Japanese: Support numbers up to 京 [7]
> 
> As a consequence, production and test code that produces or parses 
> locale-dependent strings like formatted dates and times may change behavior 
> in potentially breaking ways (e.g. when a handcrafted datetime string with a 
> regular space is parsed, but the parser now expects an NBSP or NNBSP). Issues 
> can be hard to analyze because expected and actual strings look very similar 
> or even identical in various text representations. To detect and fix these 
> issues, make sure to use a text editor that displays different kinds of 
> spaces differently.
> 
> If the required fixes can't be implemented when upgrading to JDK 20, consider 
> using the JVM argument `-Djava.locale.providers=COMPAT` to use legacy locale 
> data. Note that this limits some locale-related functionality and treat it as 
> a temporary workaround, not a proper solution. Moreover, the `COMPAT` option 
> will be eventually removed in the future.
> 
> It is also important to keep in mind that this kind of locale data evolves 
> regularly so programs parsing/composing the locale data by themselves should 
> be routinely checked with each JDK release.
> 
> [1] 
> https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html
> [2] https://bugs.openjdk.org/browse/JDK-8284840
> [3] https://cldr.unicode.org/index/downloads/cldr-42
> [4] https://unicode-org.atlassian.net/browse/CLDR-14032
> [5] https://unicode-org.atlassian.net/browse/CLDR-14831
> [6] https://unicode-org.atlassian.net/browse/CLDR-11510
> [7] https://unicode-org.atlassian.net/browse/CLDR-15966
> 
> 
> ## Heads-Up - JDK 21 - New network interface names on Windows
> 
> Network Names that the JDK assigns to network interfaces on Windows are 
> changing in JDK 21 [8].
> 
> The JDK historically synthesized names for network interfaces on Windows. 
> This has changed to use the names assigned by the Windows operating system. 
> For example, the JDK may have historically assigned a name such as “eth0” for 
> an ethernet interface and “lo” for the loopback. The equivalent names that 
> Windows assigns may be names such as “ethernet_32768” and “loopback_0".
> 
> This change may impact code that does a lookup of network interfaces with the 
> `NetworkInterace.getByName(String name)` method. It also may also be 
> surprising to code that enumerates all network interfaces with the 
> `NetworkInterfaces.networkInterfaces()` or 
> `NetworkInterface.getNetworkInterfaces()` methods as the names of the network 
> interfaces will look different to previous releases. Depending on 
> configuration, it is possible that enumerating all network interfaces will 
> enumerate network interfaces that weren’t previously enumerated because they 

Re: [Log4j] Moving `log4j-jmx-gui` to its own repo

[Apache]

I would be comfortable with this if it is moved to its own repo and released 
first, then removed from the Log4J repo. I am not comfortable with “we can do 
it someday if we want to” unless we are dropping support for it.

Ralph

> On Mar 20, 2023, at 3:36 AM, Volkan Yazıcı  wrote:
> 
> [TLDR: Piotr and I propose moving `log4j-jmx-gui` to its own repository to
> ease Java 9+ migration for `2.x`, objections?]
> 
> In the `2.x` branch, AFAIK, `log4j-jmx-gui` is the only module that has a
> Java 8 requirement, i.e., `jconsole.jar`. Piotr and I have been trying to
> come up with ways to make `2.x` use a Java 9+ compiler (be it 11 or 17),
> though every solution we have come up with has certain limitations due to
> this `jconsole.jar` requirement. I want to propose moving `log4j-jmx-gui`
> to its own repository.
> 
> For one, we _can_ simply remove it from `2.x` for the time being and
> postpone the new repository bootstrapping until there is a need to make a
> change to `log4j-jmx-gui`. (Please note that I mention this for its
> implementation convenience, not as a requirement.)
> 
> Second, we _might_ break some users' workflow. Once the module is moved to
> its own repository, it will have a separate release lifecycle, hence, we
> should ideally remove it from `log4j-bom`. Users who run `log4j-jmx-gui`
> through the dependency provided by `log4j-bom` will have a problem. Imagine
> we release `log4j-bom` 2.21.0 that doesn't ship a `log4j-jmx-gui`
> dependency. Piotr and I think that probably almost all `log4j-jmx-gui`
> users provide an explicit version, hence our inclination for this breaking
> change.
> 
> Objections?

Re: Maven site failure

[Apache]

False is the default so I left it alone. It also means it is specified in less 
places.

Ralph

> On Dec 30, 2022, at 5:26 AM, Gary Gregory  wrote:
> 
> Should that setting be flipped such that a Maven module ask to be Javadoc'd?
> 
> Gary
> 
>> On Fri, Dec 30, 2022, 07:23 Volkan Yazıcı  wrote:
>> 
>> Agreed.
>> 
>> Ralph, I see that you have only added `true` to
>> `log4j-layout-template-json-test` module, why don't we add it to all
>> `*-test` and `*-its` modules? That is, `log4j-api-test`, `log4j-core-its`,
>> `log4j-core-test`, etc.
>> 
>> On Fri, Dec 30, 2022 at 1:45 AM Ralph Goers 
>> wrote:
>> 
>>> 
>>> 
 On Dec 29, 2022, at 5:44 PM, Ralph Goers 
>>> wrote:
 
 I am trying to build the web site and it is failing in the javadoc
>>> plugin in log4j-layout-template-json-test because there are public or
>>> protected classes to document. Either the javadoc plugin needs to be
>>> disabled for the module or some classes need to be made public.
>>> 
>>> Personally, I don’t think any of the test modules need javadoc generated.
>>> 
>>> Ralph
>> 

Re: Broken build

[Apache]

Consistent

Ralph

> On Nov 16, 2022, at 5:23 PM, Matt Sicker  wrote:
> 
> Is this a consistent failure or random?
> 
>> On Nov 16, 2022, at 3:42 PM, Ralph Goers  wrote:
>> 
>> I haven’t run a build in a while and looking at the recent commits I am not 
>> sure what is causing this, but some change since 2.19.0 is now causing the 
>> following build failures in log4j-core.
>> 
>> Ralph
>> 
>> [ERROR] Failures: 
>> [ERROR]   LoggerTest.basicFlow:90 expected: <2> but was: <4>
>> [ERROR]   LoggerTest.builder:77 Incorrect message 1
>> Expected: " DEBUG 
>> org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello"
>>but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)"
>> [ERROR]   LoggerTest.debug:209 expected: <1> but was: <0>
>> [ERROR]   LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but was: 
>> <2>
>> [ERROR]   LoggerTest.flowTracingMessage:104 Incorrect Entry
>> Expected: a string starting with "ENTER[ FLOW ] TRACE Enter"
>>but: was "THROWING[ EXCEPTION ] ERROR Throwing 
>> java.lang.IllegalArgumentException: Test Exception
>> at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at 
>> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>> at 
>> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>> at 
>> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
>> at 
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
>> at 
>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
>> at 
>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>> at 
>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
>> at 
>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
>> at 
>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
>> at 
>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
>> at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
>> at 
>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
>> at 
>> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
>> at 
>> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
>> at java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189)
>> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>> at 
>> 

Re: [logging-log4j2] branch master updated: [LOG4J2-3459] - Add LoggingSystemProvider SPI

[Apache]

Are you using your old email address? I keep having to moderate them through.

Yes they should be in an appropriately named package under the internal package.

Ralph

> On Oct 31, 2022, at 7:36 PM, Matt Sicker  wrote:
> 
> We could consolidate the Log4j-private classes into the internal package and 
> export it to other Log4j modules. That makes sense.
> 
> And LoggingSystem probably doesn’t need a Lazy instance of itself, right.
> 
> —
> Matt Sicker
> 
>> On Oct 31, 2022, at 20:58, Apache  wrote:
>> 
>> 
>> 
>> See below
>> 
>>>> On Oct 31, 2022, at 6:49 PM, Matt Sicker  wrote:
>>> 
>>> The util3 package is a collection of all the private classes we have. We 
>>> discussed the general idea on a recent conference call. These are pseudo 
>>> private classes. They’re meant for internal use only and are guarded by the 
>>> module info. JUnit does the same thing
>> 
>> If they are private then they should be under a package named internal. It 
>> won’t be obvious to devs not using JPMS that they are private.
>> 
>>> The point of Lazy is ensuring thread safe publication of initialized 
>>> variables that may be initialized by multiple threads. There are two main 
>>> variants: one that guarantees the supplier function is executed only once 
>>> and one that may run the supplier more than once but has a single return 
>>> value.
>> 
>> But why is it necessary? When getInstance is called that operation should 
>> only be performed once. GetInstance is already lazy so why do we need lazy 
>> initialization of the stuff in it?
>> 
>> Ralph
>> 
>>> 
>>> —
>>> Matt Sicker
>>> 
>>>>> On Oct 31, 2022, at 17:53, Ralph Goers  wrote:
>>>> 
>>>> Also, in LoggingSystem.java
>>>> 
>>>> private static final String[] COMPATIBLE_API_VERSIONS = {"2.6.0"};
>>>> 
>>>> absolutely needs to be changed to version “3.0.0”.
>>>> 
>>>> Ralph
>>>> 
>>>>>> On Oct 31, 2022, at 3:49 PM, Ralph Goers  
>>>>>> wrote:
>>>>> 
>>>>> Matt,
>>>>> 
>>>>> I absolutely would have preferred that you had created a PR for this and 
>>>>> asked for a review before committing it as I have a few concerns:
>>>>> 
>>>>> 1. It is a massive commit. It is going to take time to digest exactly 
>>>>> what you have done.
>>>>> 2. You have created a util3 package in API with no discussion of this on 
>>>>> the dev list. I assume that it contains artifacts that were cleaned up 
>>>>> from util and are now no longer compatible? Or does it only contain 
>>>>> classes that are exportable to other Log4j artifacts (I do see that in 
>>>>> module-info.java). If these classes are meant to be private then I would 
>>>>> have preferred that it be moved to internal/util. 
>>>>> 3. I no longer understand the point of Lazy<>. LogManager now performs no 
>>>>> static initialization that I can see. Instead, it calls 
>>>>> LoggingSystem.getInstance(). What is the point of making initialization 
>>>>> of INSTANCE lazy? You accomplished what you wanted to by moving the 
>>>>> static initialization to another class.
>>>>> 4-10. I have no idea as it will take me a week to muddle through the rest 
>>>>> of all these changes to figure out what happened.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>>> On Oct 30, 2022, at 6:24 PM, mattsic...@apache.org wrote:
>>>>>> 
>>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>>> 
>>>>>> mattsicker pushed a commit to branch master
>>>>>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>>>>>> 
>>>>>> 
>>>>>> The following commit(s) were added to refs/heads/master by this push:
>>>>>> new aab23d5c05 [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>>>> aab23d5c05 is described below
>>>>>> 
>>>>>> commit aab23d5c05bff2915c290dff3e73a0ae03caf43a
>>>>>> Author: Matt Sicker 
>>>>>> AuthorDate: Sun Oct 30 20:24:17 2022 -0500
>>>>>> 
>>>>>> [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>>>> 
>>>

Re: [logging-log4j2] branch master updated: [LOG4J2-3459] - Add LoggingSystemProvider SPI

[Apache]

See below

> On Oct 31, 2022, at 6:49 PM, Matt Sicker  wrote:
> 
> The util3 package is a collection of all the private classes we have. We 
> discussed the general idea on a recent conference call. These are pseudo 
> private classes. They’re meant for internal use only and are guarded by the 
> module info. JUnit does the same thing

If they are private then they should be under a package named internal. It 
won’t be obvious to devs not using JPMS that they are private.

> The point of Lazy is ensuring thread safe publication of initialized 
> variables that may be initialized by multiple threads. There are two main 
> variants: one that guarantees the supplier function is executed only once and 
> one that may run the supplier more than once but has a single return value.

But why is it necessary? When getInstance is called that operation should only 
be performed once. GetInstance is already lazy so why do we need lazy 
initialization of the stuff in it?

Ralph

> 
> —
> Matt Sicker
> 
>> On Oct 31, 2022, at 17:53, Ralph Goers  wrote:
>> 
>> Also, in LoggingSystem.java
>> 
>> private static final String[] COMPATIBLE_API_VERSIONS = {"2.6.0"};
>> 
>> absolutely needs to be changed to version “3.0.0”.
>> 
>> Ralph
>> 
>>>> On Oct 31, 2022, at 3:49 PM, Ralph Goers  
>>>> wrote:
>>> 
>>> Matt,
>>> 
>>> I absolutely would have preferred that you had created a PR for this and 
>>> asked for a review before committing it as I have a few concerns:
>>> 
>>> 1. It is a massive commit. It is going to take time to digest exactly what 
>>> you have done.
>>> 2. You have created a util3 package in API with no discussion of this on 
>>> the dev list. I assume that it contains artifacts that were cleaned up from 
>>> util and are now no longer compatible? Or does it only contain classes that 
>>> are exportable to other Log4j artifacts (I do see that in 
>>> module-info.java). If these classes are meant to be private then I would 
>>> have preferred that it be moved to internal/util. 
>>> 3. I no longer understand the point of Lazy<>. LogManager now performs no 
>>> static initialization that I can see. Instead, it calls 
>>> LoggingSystem.getInstance(). What is the point of making initialization of 
>>> INSTANCE lazy? You accomplished what you wanted to by moving the static 
>>> initialization to another class.
>>> 4-10. I have no idea as it will take me a week to muddle through the rest 
>>> of all these changes to figure out what happened.
>>> 
>>> Ralph
>>> 
>>>>> On Oct 30, 2022, at 6:24 PM, mattsic...@apache.org wrote:
>>>> 
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>> 
>>>> mattsicker pushed a commit to branch master
>>>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>>>> 
>>>> 
>>>> The following commit(s) were added to refs/heads/master by this push:
>>>>  new aab23d5c05 [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>> aab23d5c05 is described below
>>>> 
>>>> commit aab23d5c05bff2915c290dff3e73a0ae03caf43a
>>>> Author: Matt Sicker 
>>>> AuthorDate: Sun Oct 30 20:24:17 2022 -0500
>>>> 
>>>> [LOG4J2-3459] - Add LoggingSystemProvider SPI
>>>> 
>>>> This helps clean up a lot of static state in Log4j API along with enabling 
>>>> further extensibility by exposing LoggingSystemProvider::getInstance which 
>>>> can be implemented using Injector in Log4j Core. The general utility class 
>>>> for working with this provider is available as an internal (util3) class 
>>>> in LoggingSystem. Test fixture helper classes have also been updated to 
>>>> use LoggingSystem directly.
>>>> 
>>>> Signed-off-by: Matt Sicker 
>>>> ---
>>>> .../junit/LogManagerLoggerContextFactoryRule.java  |  11 +-
>>>> .../test/junit/LoggerContextFactoryExtension.java  |  12 +-
>>>> .../{TestProvider.java => TestSystemProvider.java} |  23 +-
>>>> .../log4j/spi/DefaultThreadContextMapTest.java |  10 +-
>>>> apache.logging.log4j.spi.LoggingSystemProvider |  17 ++
>>>> .../services/org.apache.logging.log4j.spi.Provider |   1 -
>>>> log4j-api/src/main/java/module-info.java   |   5 +-
>>>> .../java/org/apache/logging/log4j/LogManager.java  |  76 +--
>>>> .../org/apache/l

Re: Consuming our own BOM

[Apache]

It is implemented on master.

Ralph

> On May 30, 2022, at 2:27 AM, Volkan Yazıcı  wrote:
> 
> Mind somebody sharing the last state? Is it implemented, if so how and on
> which branch(es)? Is it reverted? If so, totally or partially?
> 
>> On Sun, May 29, 2022 at 9:53 AM Ralph Goers 
>> wrote:
>> 
>> That is OK. I have reverted your commit and am testing the build for a
>> second time doing it the correct way.
>> 
>> Ralph
>> 
 On May 28, 2022, at 9:14 PM, Matt Sicker  wrote:
>>> 
>>> It worked, but I had to specify where the parent pom was in the
>> submodules. Are you saying I could get the same effect by importing the bom
>> in the parent pom? If so, that certainly seems easier.
>>> 
>>> —
>>> Matt Sicker
>>> 
 On May 28, 2022, at 18:15, Ralph Goers 
>> wrote:
 
 Why is this necessary? I would think having the parent import the
>> bom/pom.xml should be enough.
 
 Ralph
 
> On May 27, 2022, at 6:18 PM, Matt Sicker  wrote:
> 
> To avoid rearranging all the directories, I'm moving the parent pom to
> its own directory, moving the bom pom to the root, and updating the
> rest of the poms to know where the old parent pom now is.
> 
>> On Thu, May 19, 2022 at 3:08 PM Matt Sicker  wrote:
>> 
>> Agreed. I added the BOM POM later on and didn’t know of any
>> established patterns for modules as BOMs weren’t used extensively quite yet
>> at the time (and it was a Maven specific feature then, too; Spring ported
>> the concept to Gradle later on, and now Gradle has a native concept of the
>> same thing).
>> 
>> —
>> Matt Sicker
>> 
>>> On May 19, 2022, at 10:33, Ralph Goers 
>> wrote:
>> 
>> Yes, that would make sense. I am sure this happened simply because
>> the bom pom.xml was introduced way after the first releases.
>> 
>> Ralph
>> 
>>> On May 18, 2022, at 11:38 PM, Volkan Yazıcı  wrote:
>> 
>> 
>> Even though we provide a BOM module (`log4j-bom`), we don't consume it
>> 
>> ourselves. Hence occasionally we end up publishing artifacts not
>> included
>> 
>> in the BOM. Consuming our own BOM decreases the chances of missing out
>> 
>> artifacts in BOM, though doesn't totally eliminate the chances of that
>> 
>> happening.
>> 
>> 
>> When I read how Maven advises to structure the BOM module
>> 
>> <
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>>> ,
>> 
>> I understand what needs to be in the case of Log4j is the following:
>> 
>> 
>> /pom.xml (`log4j-bom` module)
>> 
>> /log4j-parent/pom.xml (`log4j` module importing `log4j-bom`)
>> 
>> /log4j-parent/log4j-core/pom.xml (`log4j-core` module parented by
>> `log4j`)
>> 
>> 
>> Though what we have in reality is the following:
>> 
>> 
>> /log4j-bom/pom.xml (`log4j-bom` module)
>> 
>> /pom.xml (`log4j` module parented by `logging-parent`)
>> 
>> /log4j-core/pom.xml (`log4j-core` module parented by `log4j`)
>> 
>> 
>> Ideally we should follow the Maven-advised approach and consume from
>> our
>> 
>> BOM parented by `logging-parent`.
>> 
>> 
>> What do you think? Is my interpretation of the Maven-advised approach
>> 
>> correct?
>> 
>> 
 
>> 
>> 

Re: Considering porting DI to 2.x

[Apache]

Lol. Ok An app running in Java 11. That changes nothing. We can certainly make 
some incompatible changes but as we have previously discussed some of the 
things you removed will have to be reverted.

Making Log4J 3 not backward compatible would be a disaster.

Ralph

> On Apr 18, 2022, at 5:07 PM, Gary Gregory  wrote:
> 
> "an app
> will certainly be able to replace their 2.x jars with 3.x jars and continue
> to work"
> 
> Certainly not since 3.x requires Java 11.
> 
> Gary
> 
>> On Mon, Apr 18, 2022, 18:19 Ralph Goers  wrote:
>> 
>> I have no idea what you are referring to.
>> 
>> You are talking about having log4j 2 and log4j 3 jars present in the
>> application
>> at the same time? You can no more do that than you can have a
>> log4j-core.2.17.1
>> jar and a log4j-core-2.17.2 jar on the classpath at the same time. But an
>> app
>> will certainly be able to replace their 2.x jars with 3.x jars and
>> continue to work.
>> 
>> Why would you think you need both versions to be present at the same time?
>> 
>> Ralph
>> 
>>> On Apr 19, 2022, at 12:05 AM, Gary Gregory 
>> wrote:
>>> 
>>> How can they coexist when they use the same package names? This is why I
>>> want to use a different package name root for 3.x, like org.apache.log4j3
>>> or something like that.
>>> 
>>> On Mon, Apr 18, 2022, 17:07 Ralph Goers 
>> wrote:
>>> 
 Gary, that really doesn’t say anything. 2.x and 3.x are already designed
 to be able to coexist.
 
 Ralph
 
> On Apr 18, 2022, at 10:50 PM, Gary Gregory 
 wrote:
> 
> For my 2c, the better internals are not going to motivate the majority
>> of
> users to update to 3.0, features are. It might be different for plugin
> authors, but how many of those are there? My guess is a minuscule
 amount. I
> agree that 2.x should live for a long long time, and should be able to
> coexist with 1.x and 3.x.
> 
> Gary
> 
> Gary
> 
> On Mon, Apr 18, 2022, 14:56 Piotr P. Karwasz 
> wrote:
> 
>> Hi Volcan,
>> 
>> On Sun, 17 Apr 2022 at 22:42, Volkan Yazıcı  wrote:
>> 
>>> 1. I was working on LOG4J2-3082 (support external serializers, e.g.,
>>> Jackson, in JTL) and there I needed `@RequiredClass`. Ralph already
>>> implemented this in `master`, I just need to copy it to
 `release-2.x`,
>>> after all it is just a `@ConstraintValidator`, right? Right... But
>> it
>>> simply won't work. Because JTL, as `PatternLayout`, uses
>>> `PluginManager` to
>>> load plugins and that doesn't support `@ConstraintValidator` et
>> al.?!
>>> I've
>>> discussed this with Matt and we came to the conclusion that porting
>> the
>>> new
>>> plugin infra from 3.x to 2.x is easier compared to fixing the
>> problem
>> in
>>> 2.x.
>>> 
>> 
>> Maybe this can be solved in other ways. For example we could have a:
>> 1. `SerializerFactory` with multiple implementations each one in a
 separate
>> module,
>> 2. You use the `ServiceLoaderUtil` to find an implementation or you
>> use
 the
>> internal one if there are none.
>> 
>> I think that the dependency injector is a feature that should stay in
 3.0
>> to motivate people to move from 2.x.
>> 
>> Piotr
>> 
 
 
>> 
>> 
>> 

Re: [ANNOUNCEMENT] Apache Commons Release Plugin Version 1.8.0

[Apache]

Wrong list

Ralph

> On Apr 2, 2022, at 5:08 AM, Gary Gregory  wrote:
> 
>  We just released our release tool, Apache Commons Release Plugin Version
> 1.8.0:
> An Apache Maven Mojo for Apache Commons Release tasks.
> 
> Historical list of changes:
> https://commons.apache.org/proper/commons-release-plugin//changes-report.html
> 
> For complete information on Apache Commons Release Plugin, including
> instructions on how to submit bug reports, patches, or suggestions for
> improvement, see the Apache Apache Commons Release Plugin website:
> 
> https://commons.apache.org/proper/commons-release-plugin/
> 
> Download page:
> https://commons.apache.org/proper/commons-release-plugin//download_text.cgi
> 
> Have fun!
> 
> Gary Gregory,
> -Apache Commons Team

Re: Should lookups be split out or otherwise disabled by default?

[Apache]

The answer is - it depends. Although we might consider using the properties 
proposal I made in master many of the lookups should default to being enabled 
or enabled under a condition. For example, the spring lookup only works when 
spring boot is present. It would be stupid for it not to be enabled when it is 
a spring boot app.

Ralph

> On Jan 13, 2022, at 8:19 PM, Matt Sicker  wrote:
> 
> For the extra paranoid users and users who already use some other method of 
> generating config files (e.g., using the ConfigurationBuilder DSL which 
> already supports arbitrary Java code), it seems like a useful feature to make 
> lookups an opt-in feature. What do you all think? Any splitting from core 
> would need to be done for 3.x, though we can add @RequiredProperty 
> annotations to StrLookup plugins in 2.x to make a similar change.
> --
> Matt Sicker
> 

Re: [logging-log4j2] branch release-2.x updated: [LOG4J2-3256] Reduce ignored package scope of KafkaAppender #640.

[Apache]

Please don’t forget to apply this to the master branch.

Ralph

> On Dec 26, 2021, at 6:31 AM, ggreg...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> ggregory pushed a commit to branch release-2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> 
> 
> The following commit(s) were added to refs/heads/release-2.x by this push:
> new aba0358  [LOG4J2-3256] Reduce ignored package scope of KafkaAppender 
> #640.
> aba0358 is described below
> 
> commit aba0358db59b0657dba370271768351cf97b4b5c
> Author: Gary Gregory 
> AuthorDate: Sun Dec 26 08:30:53 2021 -0500
> 
>[LOG4J2-3256] Reduce ignored package scope of KafkaAppender #640.
> 
>Modified GitHub patch #640 from Lee
>Dongjin/dongjinleekr/dong...@apache.org.
> ---
> src/changes/changes.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 4c96396..7f2b6ee 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -55,7 +55,7 @@
>   
> Lookups with no prefix only read values from the configuration 
> properties as expected.
>   
> -  
> +  
> Reduce ignored package scope of KafkaAppender.
>   
> 
> 

Re: [logging-log4j2] branch release-2.x updated: LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of formatted message data

[Apache]

Please don’t forget to apply this to the master branch

Ralph

> On Dec 25, 2021, at 12:20 PM, cko...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> ckozak pushed a commit to branch release-2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> 
> 
> The following commit(s) were added to refs/heads/release-2.x by this push:
> new 487588b  LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of 
> formatted message data
> 487588b is described below
> 
> commit 487588b7c34bc0b540e769d98c42d018fa1bc1b8
> Author: Carter Kozak 
> AuthorDate: Sat Dec 25 11:48:20 2021 -0500
> 
>LOG4J2-3289: Fix log4j-to-slf4j re-interpolation of formatted message data
> ---
> .../java/org/apache/logging/slf4j/SLF4JLogger.java | 28 ++
> .../java/org/apache/logging/slf4j/LoggerTest.java  | 33 ++
> src/changes/changes.xml|  3 ++
> 3 files changed, 52 insertions(+), 12 deletions(-)
> 
> diff --git 
> a/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java 
> b/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java
> index 5ea8b7b..be1a15a 100644
> --- a/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java
> +++ b/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java
> @@ -86,10 +86,13 @@ public class SLF4JLogger extends AbstractLogger {
> return locationAwareLogger != null ? locationAwareLogger : logger;
> }
> 
> -private org.slf4j.Marker getMarker(final Marker marker) {
> -if (marker == null) {
> -return null;
> -}
> +private static org.slf4j.Marker getMarker(final Marker marker) {
> +// No marker is provided in the common case, small methods
> +// are optimized more effectively.
> +return marker == null ? null : convertMarker(marker);
> +}
> +
> +private static org.slf4j.Marker convertMarker(final Marker marker) {
> final org.slf4j.Marker slf4jMarker = 
> MarkerFactory.getMarker(marker.getName());
> final Marker[] parents = marker.getParents();
> if (parents != null) {
> @@ -222,31 +225,32 @@ public class SLF4JLogger extends AbstractLogger {
> 
> @Override
> public void logMessage(final String fqcn, final Level level, final Marker 
> marker, final Message message, final Throwable t) {
> +org.slf4j.Marker slf4jMarker = getMarker(marker);
> +String formattedMessage = message.getFormattedMessage();
> if (locationAwareLogger != null) {
> if (message instanceof LoggerNameAwareMessage) {
> ((LoggerNameAwareMessage) message).setLoggerName(getName());
> }
> -locationAwareLogger.log(getMarker(marker), fqcn, 
> convertLevel(level), message.getFormattedMessage(),
> -message.getParameters(), t);
> +locationAwareLogger.log(slf4jMarker, fqcn, convertLevel(level), 
> formattedMessage, null, t);
> } else {
> switch (level.getStandardLevel()) {
> case DEBUG :
> -logger.debug(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.debug(slf4jMarker, formattedMessage, t);
> break;
> case TRACE :
> -logger.trace(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.trace(slf4jMarker, formattedMessage, t);
> break;
> case INFO :
> -logger.info(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.info(slf4jMarker, formattedMessage, t);
> break;
> case WARN :
> -logger.warn(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.warn(slf4jMarker, formattedMessage, t);
> break;
> case ERROR :
> -logger.error(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.error(slf4jMarker, formattedMessage, t);
> break;
> default :
> -    logger.error(getMarker(marker), 
> message.getFormattedMessage(), message.getParameters(), t);
> +logger.error(slf4jMarker, formattedMessage, t);
>     break;
> }
> }
> diff --git 
> a/log4j-to-slf4j/src/test/java/org/apache/logging/slf4j/LoggerTest

Re: Setting default branch to release-2.x on GitHub

[Apache]

Infra has a mailing list and a slack channel.

Ralph

> On Dec 26, 2021, at 6:00 AM, Carter Kozak  wrote:
> 
> I filed an infra ticket for this, but it hasn’t been picked up yet: 
> https://issues.apache.org/jira/browse/INFRA-22641
> Might be worth emailing someone? Otherwise they may be busy with the holidays.
> 
> -ck
> 
>> On Dec 26, 2021, at 06:16, Volkan Yazıcı  wrote:
>> 
>> Many people get confused by the default branch of the repository on GitHub.
>> I want to make it point to `release-2.x` rather than `master`. Objections?

Re: RELEASE-NOTES.md

[Apache]

I should have added that you should not delete it.

Ralph

> On Dec 24, 2021, at 7:00 AM, Apache  wrote:
> 
> The release notes file is generated for every release.
> 
> Ralph
> 
>> On Dec 24, 2021, at 6:20 AM, Volkan Yazıcı  wrote:
>> 
>> Is this file still relevant? If not, may I simply delete it? If it is, mind
>> somebody explaining what to do with it? How shall we use it in the presence
>> of `changes.xml`?
>> 
>> -- Forwarded message -
>> From: Kristjan Esperanto 
>> Date: Sun, Dec 19, 2021 at 12:08 PM
>> Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
>> To: apache/logging-log4j2 
>> Cc: Subscribed 
>> 
>> 
>> It's a minor detail, but I didn't find any reference to the release history
>> in the repository.
>> --
>> You can view, comment on, or merge this pull request online at:
>> 
>> https://github.com/apache/logging-log4j2/pull/642
>> Commit Summary
>> 
>>  - 89ff650
>>  
>> <https://github.com/apache/logging-log4j2/pull/642/commits/89ff6508f735e3e422abbf5b221a5ff0980c22c9>
>>  Add Link to Release History
>> 
>> File Changes
>> 
>> (1 file <https://github.com/apache/logging-log4j2/pull/642/files>)
>> 
>>  - *M* RELEASE-NOTES.md
>>  
>> <https://github.com/apache/logging-log4j2/pull/642/files#diff-7d8a453165f16d910a0937bf01782607cafc77fd7f42b443aff0cd02725848d7>
>>  (4)
>> 
>> Patch Links:
>> 
>>  - https://github.com/apache/logging-log4j2/pull/642.patch
>>  - https://github.com/apache/logging-log4j2/pull/642.diff
>> 
>> —
>> Reply to this email directly, view it on GitHub
>> <https://github.com/apache/logging-log4j2/pull/642>, or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AAARTSKH4JEGNONQTMPORJ3URW4KPANCNFSM5KLYIE2Q>
>> .
>> You are receiving this because you are subscribed to this thread.Message
>> ID: 

Re: RELEASE-NOTES.md

[Apache]

The release notes file is generated for every release.

Ralph

> On Dec 24, 2021, at 6:20 AM, Volkan Yazıcı  wrote:
> 
> Is this file still relevant? If not, may I simply delete it? If it is, mind
> somebody explaining what to do with it? How shall we use it in the presence
> of `changes.xml`?
> 
> -- Forwarded message -
> From: Kristjan Esperanto 
> Date: Sun, Dec 19, 2021 at 12:08 PM
> Subject: [apache/logging-log4j2] Add Link to Release History (PR #642)
> To: apache/logging-log4j2 
> Cc: Subscribed 
> 
> 
> It's a minor detail, but I didn't find any reference to the release history
> in the repository.
> --
> You can view, comment on, or merge this pull request online at:
> 
>  https://github.com/apache/logging-log4j2/pull/642
> Commit Summary
> 
>   - 89ff650
>   
> <https://github.com/apache/logging-log4j2/pull/642/commits/89ff6508f735e3e422abbf5b221a5ff0980c22c9>
>   Add Link to Release History
> 
> File Changes
> 
> (1 file <https://github.com/apache/logging-log4j2/pull/642/files>)
> 
>   - *M* RELEASE-NOTES.md
>   
> <https://github.com/apache/logging-log4j2/pull/642/files#diff-7d8a453165f16d910a0937bf01782607cafc77fd7f42b443aff0cd02725848d7>
>   (4)
> 
> Patch Links:
> 
>   - https://github.com/apache/logging-log4j2/pull/642.patch
>   - https://github.com/apache/logging-log4j2/pull/642.diff
> 
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/642>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAARTSKH4JEGNONQTMPORJ3URW4KPANCNFSM5KLYIE2Q>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: 

Re: Log4J 1.x progress, pull request(s), plans

[Apache]

Fwiw, this sounds like a god plan to me.

Ralph

> On Dec 23, 2021, at 6:51 AM, Leo Simons  wrote:
> 
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
> 
> What I did for the PRs I made is to
> 
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done for 64 bit,
> * have the maven build not auto-attempt to build it,
> * make its single unit test not even attempt to run except on windows,
> * add a matrix build that includes running on windows so that the
> windows-only test gets run frequently
> * did a little test on a windows machine with one of the DLLs
> 
> Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
> 
> I think it’s good enough like that.
> 
> Additional todo could be
> * add better INSTALL instructions for how to rebuild the dlls with ant
> * add another CI / GitHub action build that rebuilds the DLLs
> 
> I think it is best to produce the DLLs on windows and the official release
> on linux, and to not attempt to have build orchestration to glue those
> together. It’s an exceptionally messy thing to rebuild from source without
> manual step, while the manual step is easy.
> 
> Cheers,
> 
> Leo
> 
> 
>> On Thu, 23 Dec 2021 at 14:34, Gary Gregory  wrote:
>> 
>> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 
>> wrote:
>> 
>>> 
>>> On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
>>>> One of the difficulties was likely related to building the Windows DLLs
>>>> for
>>>> using the Windows Event Log Appender (
>>>> 
>>> 
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
>>> ).
>>>> I remember that being challenging. I can't recall if we signed the DLLs
>>>> like we might do for Apache Commons Daemons Windows binaries. Another
>>>> hurdle.
>>> 
>>> Correct, the DLL is even in the codebase.
>>> 
>>> 
>> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>>> 
>>> If we would remove that Appender, it would be much easier to build, when
>> I
>>> remember correctly.
>>> Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>>> 
>> 
>> Sadly, no. We cannot break binary compatibility, that would create a bigger
>> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
>> me.
>> 
>> I feel like the projects I've worked on like Apache Commons and
>> HttpComponents have benefitted *massively* from providing binary
>> compatibility. Giving users drop-in replacements is a huge help.
>> 
>> Recall that Apache officially *only releases source code*, and that source
>> code must be buildable, no matter how complex the instructions. Any
>> binaries are only provided as a convenience, that includes jar files and
>> DLLs.
>> 
>> Gary
>> 
>> 
>>>> 
>>>> FWIW, my opinion has been to NOT resurrect 1.x and put our energies
>> into
>>>> improving the 1.2 bridge and configuration file support we already have
>>> in
>>>> 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>>>> 
>>>> No matter what, it needs to be a decision made carefully and not in
>>> haste.
>>>> 
>>> 
>>> +1
>>> 
>>>> Gary
>>>> 
>>>> On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
>>> grobme...@apache.org>
>>>> wrote:
>>>> 
>>>>> Hello
>>>>> 
>>>>> I have been the person cutting the 1.2.17 release and what I remember
>>> was
>>>>> it was a super hard build. I had to install some VMs because there
>> were
>>>>> weird dependencies to this build. Building it fully will not be easy,
>>> but I
>>>>> can also look into some mails whatever I found from that time.
>>>>> Here is some build info.:
>>>>> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>>>>> Some unit tests only run with a Windows VM
>>>>> 
>>>>> It would be easier to remove some components, but BC is broken then.
>>>>> 
>>>>> We told people in August 2015 this is EOL. I am honestly surprised
>> that
>>> we
>>>>> discuss a new release after 7 years. To my understanding the
>> JMSAppender
>>>>> issue is not as cri

Re: New Log4j 1 repo

[Apache]

I have VMWare on my Mac with both Ubuntu and Windows 10. So I should be able to 
run a build.

Ralph

> On Dec 23, 2021, at 5:59 AM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> 
> On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote:
>>> using maven toolchain feature
>> 
>> Are toolchains really needed, especially, 1.6 and 1.7?
>> I believe Java "target=1.4" + Java 1.8 would be good enough.
>> If there are javadoc "warnings or errors", we could just suppress it.
>> At the end of the day, making the build 100 times harder by requesting Java
>> 1.6
>> looks like an overkill.
>> 
>> I think there's no way to install Java 1.6 on modern macOS.
> 
> Correct. I would suggest Docker, if there is a way to install it there.
> 
> Here is some more installation instructions:
> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> 
> For a complete build for a release, one needs to run tests using some DLLs 
> which made it very hard back then.
> 
> Christian
> 
> 
>> 
>> Vladimir
> 

Re: New Log4j 1 repo

[Apache]

I was already asked to create a branch off of 1.2.17. It will become the main 
branch so trunk can be left alone.

Ralph

> On Dec 23, 2021, at 6:41 AM, Gary Gregory  wrote:
> 
> If we use this repo, is everyone OK renaming "trunk" to "master" in order
> to match the branch name of our other repos?
> 
> Gary
> 
>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers 
>> wrote:
>> 
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>> 
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>> 
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>> 
>> Ralph
>> 
>> 
>> 

Re: New Log4j 1 repo

[Apache]

Thanks Leo. I was using Java 8 with maven 3 in a Linux VM. I don’t think maven 
3 runs on Java 6.

Ralph

> On Dec 23, 2021, at 5:11 AM, Leo Simons  wrote:
> 
> On Thu, 23 Dec 2021 at 12:39, Ralph Goers 
> wrote:
> 
>> It is still the middle of the night for me so I won’t do anything for
>> several hours.
> 
> 
> Whoa, best get some rest! :)
> 
> I will create the branch but I am curious about the rest. When I ran the
>> build last night it ran through a bunch of unit tests without any problems.
> 
> 
> The 1.2.17 build as-is has only a short whitelist of tests being run from
> maven. There are many more tests only set up to run with ant, without maven
> invoking ant.
> 
> I changed the maven build to run all tests. Then set up a matrix build.
> Some of the other tests worked out of the box, not all. So then fixed the
> tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled
> a couple really flaky ones.
> 
> It then failed due to javadoc errors.
> 
> 
> Probably you used JDK9+ where some warnings become errors. I fixed that too
> in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6
> or 7).
> 
> I just told the plugin not to fail and then it started executing the site
>> plugin. I tried updating the version but that just caused it to have an
>> error in the site.xml.
> 
> 
> Yup, fixing the site was a lot of work!
> 
> My question is, you said that the build has test failures. Did I not see
>> them because of the changes after 1.2.17 or is something else going on?
> 
> 
> I think the summary answer here is “lots is going on”!
> 1.2.17 partially migrated the build from ant to maven 2, back in 2012.
> Frankly it wasn’t in so clean a state at time of release.
> That makes sense since all the plug-in stability in maven really only came
> after maven 3. Back then it was pretty normal to work around plugin
> regressions every point release…you can see TODO comments in the 1.2.17 pom
> about it…
> ….you may have forgotten the extent of such pain :-). Cleaning it all up
> was a bunch of explorative surgery!
> 
> Cheers,
> 
> Leo

Re: New Log4j 1 repo

[Apache]

From what I can tell that repo could only be “owned” by a TLP named 
log4j.apache.org. It doesn’t show up on the list of gitbox repos owned by any 
ASF projects. I believe it is a read-only mirror tied to the sun repo. I asked 
infra about it in slack and they weren’t quite sure what it is. So rather than 
hunt that down and make everyone wait I created the new repo. All logging 
services Git repos start with logging-.

Of course you are free to screw around and try to make something happen with 
the old repo rather than just getting started.

Ralph

> On Dec 23, 2021, at 4:56 AM, Vladimir Sitnikov  
> wrote:
> 
> Leo>Instead of or in addition to some of those fixes
> 
> I would suggest the following (in case you wonder, I might volunteer to do
> ALL of that, so don't assume I just sit and tell others how things should
> be done):
> 1. Use the existing repo https://github.com/apache/log4j instead of a newly
> created one.
> The existing repo is well-known in the community (108 watch, 537 forks, 849
> stars), and it is very strange to drop all that.
> 2. Add GitHub CI so the code at least compiles. I think we should not fix
> everything like javadoc/site/whatever if it takes too much time.
> Having any CI would be way better than nothing.
> 3. Consider existing known CVE fixes (e.g. somewhere there was a mention of
> RedHat fixes for log4j 1.x CVEs).
> It might be easier to apply the fixes before the code is split.
> 4. Consider splitting the code into modules. In practice, there's already a
> branch that does exactly that:
> https://github.com/apache/log4j/tree/log4j12modules/modules
> 5. Release 1.2.18.
> 6. Treat CVEs. For instance, implement hardening in log4j-net or whatever.
> 7. Release 1.2.19
> 8 see what happens, maybe new PR would appear.
> 
> Vladimir

Re: New Log4j 1 repo

[Apache]

https://github.com/apache/log4j was read-only. The new repo is not.

Ralph

> On Dec 22, 2021, at 11:34 PM, Ralph Goers  wrote:
> 
> I have cloned the read-only log4j repo to 
> https://github.com/apache/logging-log4j1.
> 
> I have followed the build instructions and had to modify the javadoc plugin 
> to not fail on errors. Now it fails in the site plugin.
> 
> If someone else wants to take this on I would suggest the first PR should 
> just to the pom.xml file to get the build working as is.
> 
> Ralph
> 
> 

Re: changes.xml

[Apache]

I tried that. Somehow the whole description got removed. Even if that worked 
the release notes would look terrible.

Ralph.

> On Dec 8, 2021, at 5:23 AM, Gary Gregory  wrote:
> 
> If you refer to
> https://logging.staged.apache.org/log4j/2.x/changes-report.html#a2.15.0 I'm
> not sure what we can do unless there is special sauce to use in
> changes.xml. Are we supposed to use HTML in a changes.xml entry? That would
> be simple enough.
> 
> Gary
> 
>> On Tue, Dec 7, 2021 at 5:05 PM Ralph Goers 
>> wrote:
>> 
>> Gary,
>> 
>> Please review the manual changes for 2.15.0 on the staging web site. The
>> last item is yours from
>> upgrading a bunch of dependency versions.
>> 
>> I spent a bunch of time yesterday trying to figure out how to make that
>> pretty and finally gave up.
>> It requires knowing now the changes plugin passes data to Doxia and what
>> Doxia is going to do to
>> render it. If you look at
>> https://github.com/apache/maven-changes-plugin/blob/master/src/main/java/org/apache/maven/plugins/changes/ChangesReportGenerator.java
>> in the constructAction methodyou will see that it calls sink.text() for
>> the description. I can only guess
>> it is using Doxia’s XHTML Sink which just appends the data to a
>> StringBuffer.
>> 
>> Interestingly, it doesn’t look to bad when the announcement goal is run,
>> but that is only because the
>> target is a Markdown file so it sort of looks ok, although Markdown seems
>> to treat it as one large code block.
>> 
>> Bottom line - Unless you can figure out how to get these to properly
>> format entries like this will
>> continue to be a mess in the future. I know we have had at least one like
>> it in the past.
>> 
>> Ralph
>> 

Re: How to inject a dependency into a custom filter.

[Apache]

After thinking about this more I can’t quite figure out what the user would be 
specifying in the configuration. A Java lambda expression? I.e what is the rule 
syntax? Or are they expected to just configure predefined rules with perhaps 
some variables. But if that is the case how is this really any different than 
just creating new filters? The only real difference I see is that the Supplier 
presumably returns a Boolean instead of a filter result.

Ralph

> On Oct 21, 2021, at 4:51 PM, Ralph Goers  wrote:
> 
> This sounds interesting. I might give it a whirl but  firstI am trying to 
> finish up some work on 
> Apache Flume so it can get a new release and I need to do some other work 
> here as we 
> are overdue for a release.
> 
> Ralph
> 
>> On Oct 21, 2021, at 11:28 AM, Adwait Kumar Singh 
>>  wrote:
>> 
>> The problem I am stuck on is the best way to get the user to provide the
>> ruleSupplier via configuration.
>> 
>>> On Thu, Oct 21, 2021 at 11:55 PM Adwait Kumar Singh <
>>> theadvaitkumarsi...@gmail.com> wrote:
>>> 
>>> Yes I mean filtering on those loggers.
>>> 
>>> I don't expect the Supplier to be dynamically changed, only the rules they
>>> are fetching. Something roughly like this
>>> 
>>> public class RuleBaseFilter extends AbstractFilter {
>>> 
>>>   //This will be initialized only once
>>>   Supplier> rulesSupplier;
>>> 
>>> 
>>> @Override
>>>  public Result filter(final Logger logger, final Level level, final
>>> Marker marker, final Message msg,
>>>  final Throwable t) {
>>>   List rules = rulesSupplier.get();
>>>   //evaluate rules and filter
>>> }
>>> 
>>> }
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Oct 21, 2021 at 11:19 PM Ralph Goers 
>>> wrote:
>>> 
>>>> Sorry, you have lost me a little bit.
>>>> 
>>>> When you say dynamically turn on/off loggers I am assuming you really
>>>> mean
>>>> enable/disable filtering on those Loggers?
>>>> 
>>>> Are you thinking that the rules can be added or removed dynamically? Or
>>>> just the
>>>> parameters to the rules? I ask because you can’t really add a Supplier
>>>> dynamically
>>>> if it is part of the configuration. Log4j will process the configuration
>>>> only when it is
>>>> changed. However, the data they rely on can come from anywhere - more or
>>>> less
>>>> how we use Lookups to evaluate conditions on every log event.
>>>> 
>>>> Ralph
>>>> 
>>>>> On Oct 21, 2021, at 8:44 AM, Adwait Kumar Singh <
>>>> theadvaitkumarsi...@gmail.com> wrote:
>>>>> 
>>>>> This is still in the proof of concept phase, but what I am trying to do
>>>> is
>>>>> create a filter which allows developers to dynamically turn on/off
>>>> loggers
>>>>> based on some parameters without restarting their system. The parameters
>>>>> can be varied, like:
>>>>> 1. Turn on WARN log levels of a particular class.
>>>>> 2. Turn on TRACE logging only on a particular host.
>>>>> 3. Turn on DEBUG logs only for requests by a particular client for a
>>>> short
>>>>> duration,
>>>>> ... and any combination of such parameters.
>>>>> 
>>>>> The way I was thinking of doing this was creating a filter which takes
>>>> in a
>>>>> Supplier and then evaluates a log event against that rule.
>>>>> 
>>>>> On Thu, Oct 21, 2021 at 7:37 PM Apache 
>>>> wrote:
>>>>> 
>>>>>> It sounds to me like you want to create a new type of plugin similar to
>>>>>> PatternConerters. I am curious as to what your filter does. Is it
>>>> something
>>>>>> that would be useful to others so that we would be interested in
>>>> including
>>>>>> it?
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Oct 21, 2021, at 6:07 AM, Adwait Kumar Singh <
>>>>>> theadvaitkumarsi...@gmail.com> wrote:
>>>>>>> 
>>>>>>> I am creating a filter which requires the user to give a
>>>> Supplier
>>>>>> to
>>>>>>> fetch some custom rules. I am wondering how to go about getting this
>>>>>>> Supplier from the configuration xml.
>>>>>>> 
>>>>>>> One way I have thought of is using some sort of Registry and then just
>>>>>>> asking the user to provide a key to lookup into the Registry to fetch
>>>> the
>>>>>>> Supplier. The user then registers his Supplier to this Registry in
>>>> Java
>>>>>>> code.
>>>>>>> What are your thoughts on this and do you guys know of a better way
>>>> to do
>>>>>>> this?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Adwait.
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
> 

Re: How to inject a dependency into a custom filter.

[Apache]

It sounds to me like you want to create a new type of plugin similar to 
PatternConerters. I am curious as to what your filter does. Is it something 
that would be useful to others so that we would be interested in including it?

Ralph

> On Oct 21, 2021, at 6:07 AM, Adwait Kumar Singh 
>  wrote:
> 
> I am creating a filter which requires the user to give a Supplier to
> fetch some custom rules. I am wondering how to go about getting this
> Supplier from the configuration xml.
> 
> One way I have thought of is using some sort of Registry and then just
> asking the user to provide a key to lookup into the Registry to fetch the
> Supplier. The user then registers his Supplier to this Registry in Java
> code.
> What are your thoughts on this and do you guys know of a better way to do
> this?
> 
> Thanks,
> Adwait.

Re: Setting up gh-pages (Was: Continuous performance test bed using GitHub Actions)

[Apache]

Volkan,

I am not in front of my computer at the moment, but I am 100% sure you are 
incorrect. Every logging project has its own GitHub repo for its own web site. 
The thought of having log4cxx and Log4Net use a repo with Log4J in the name 
doesn’t make any sense.

Publishing a web site involves committing the changes to the asf-staging 
branch, reviewing those changes, and then merging the staging branch to the 
live branch. 

I just don’t see what advantages using GitHub pages provides over this as your 
points below seem like they are already covered.

Ralph

> On Oct 19, 2021, at 1:14 AM, Volkan Yazıcı  wrote:
> 
> In its current state, all Logging Services projects (log4j, log4jcxx,
> log4net, etc.) dump their websites to a single repository:
> https://github.com/apache/logging-log4j-site If I need to publish
> continuous benchmark results of logging-log4j2 repository, I need to push
> my changes to two other branches of another repository. What I was asking
> for is if we can publish a website to a logging-log4j2 repository branch
> such that it will be displayed under a logging.apache.org subdomain. This
> approach would provide the following advantages:
> 
>   - Every repository will contain its own website. (I guess, we can all
>   agree this is a good thing to have.)
>   - CI (in particular, benchmark) scripts won't need to hack their way
>   around multi-repo setups.
>   - No disruption to the current logging.apache.org flow.
> 
> 
>> On Mon, Oct 18, 2021 at 9:16 PM Ralph Goers 
>> wrote:
>> 
>> I feel like I am going in circles.
>> 
>> Testing of what? I still don’t understand what the use case is for GitHub
>> Pages. What problem is it solving?
>> 
>> Ralph
>> 
>>>> On Oct 18, 2021, at 12:05 PM, Matt Sicker  wrote:
>>> 
>>> I’d imagine it’s for testing purposes initially. We should integrate it
>> into the main domain when it’s ready for release. This should all be
>> controllable via the .asf.yaml file.
>>> 
>>> Matt Sicker
>>> 
>>>> On Oct 18, 2021, at 12:32, Ralph Goers 
>> wrote:
>>>> 
>>>> Why?
>>>> 
>>>> Ralph
>>>> 
>>>>> On Oct 18, 2021, at 8:40 AM, Volkan Yazıcı  wrote:
>>>>> 
>>>>> For the moment, I just want the `gh-pages` branch of the logging-log4j2
>>>>> GitHub project to be accessible at "a" URL – just like any other
>> non-ASF
>>>>> GitHub project.
>>>>> 
>>>>>> On Mon, Oct 18, 2021 at 5:38 PM Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>>>> wrote:
>>>>>> 
>>>>>> OK. That page didn’t exist when I migrated the site from the CMS. That
>>>>>> still leaves
>>>>>> the second question. What are you proposing? I don’t really see the
>> point
>>>>>> of moving
>>>>>> the existing site to GitHub Pages.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Oct 18, 2021, at 8:31 AM, Volkan Yazıcı  wrote:
>>>>>>> 
>>>>>>> GitHub Pages look pretty doable to me:
>>>>>>> https://cwiki.apache.org/confluence/display/INFRA/GitHub+Pages
>>>>>>> 
>>>>>>> On Fri, Oct 15, 2021 at 6:35 PM Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I don’t really understand this. When I was migrating the web site
>> from
>>>>>> the
>>>>>>>> ASF CMS to GitHub
>>>>>>>> it was made clear that web site hosting using GitHub Pages wasn’t
>>>>>>>> supported. I am not sure
>>>>>>>> what the proposal here is.
>>>>>>>> 
>>>>>>>> Ralph
>>>>>>>> 
>>>>>>>>> On Oct 15, 2021, at 8:27 AM, Matt Sicker  wrote:
>>>>>>>>> 
>>>>>>>>> I’m not exactly sure how we can get a beta subdomain, though the
>>>>>> staging
>>>>>>>> one is built in. And while it would be great to automate as much as
>>>>>>>> possible about the release process in GHA, the code signing aspect
>> is
>>>>>> still
>>>>>>>> not possible (though we might be able to integrate with another
>> service
>>>>>> at
>>>>>>>> Apache for that

Re: Setting up gh-pages (Was: Continuous performance test bed using GitHub Actions)

[Apache]

What new plug-in?

Ralph

> On Oct 18, 2021, at 12:32 PM, Matt Sicker  wrote:
> 
> Testing the website publishing from the new plugin. It’s probably easier to 
> keep it under the ASF pages thing than it is to combine it with GH pages. 
> Since it’s storing generated markup in a git repo, it doesn’t matter much 
> which system it’s using besides whatever integration we already have set up.
> 
> Matt Sicker
> 
>> On Oct 18, 2021, at 14:16, Ralph Goers  wrote:
>> 
>> I feel like I am going in circles.
>> 
>> Testing of what? I still don’t understand what the use case is for GitHub 
>> Pages. What problem is it solving?
>> 
>> Ralph
>> 
>>>> On Oct 18, 2021, at 12:05 PM, Matt Sicker  wrote:
>>> 
>>> I’d imagine it’s for testing purposes initially. We should integrate it 
>>> into the main domain when it’s ready for release. This should all be 
>>> controllable via the .asf.yaml file.
>>> 
>>> Matt Sicker
>>> 
>>>>> On Oct 18, 2021, at 12:32, Ralph Goers  wrote:
>>>> 
>>>> Why?
>>>> 
>>>> Ralph
>>>> 
>>>>> On Oct 18, 2021, at 8:40 AM, Volkan Yazıcı  wrote:
>>>>> 
>>>>> For the moment, I just want the `gh-pages` branch of the logging-log4j2
>>>>> GitHub project to be accessible at "a" URL – just like any other non-ASF
>>>>> GitHub project.
>>>>> 
>>>>>> On Mon, Oct 18, 2021 at 5:38 PM Ralph Goers 
>>>>>> wrote:
>>>>>> 
>>>>>> OK. That page didn’t exist when I migrated the site from the CMS. That
>>>>>> still leaves
>>>>>> the second question. What are you proposing? I don’t really see the point
>>>>>> of moving
>>>>>> the existing site to GitHub Pages.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Oct 18, 2021, at 8:31 AM, Volkan Yazıcı  wrote:
>>>>>>> 
>>>>>>> GitHub Pages look pretty doable to me:
>>>>>>> https://cwiki.apache.org/confluence/display/INFRA/GitHub+Pages
>>>>>>> 
>>>>>>> On Fri, Oct 15, 2021 at 6:35 PM Ralph Goers 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I don’t really understand this. When I was migrating the web site from
>>>>>> the
>>>>>>>> ASF CMS to GitHub
>>>>>>>> it was made clear that web site hosting using GitHub Pages wasn’t
>>>>>>>> supported. I am not sure
>>>>>>>> what the proposal here is.
>>>>>>>> 
>>>>>>>> Ralph
>>>>>>>> 
>>>>>>>>> On Oct 15, 2021, at 8:27 AM, Matt Sicker  wrote:
>>>>>>>>> 
>>>>>>>>> I’m not exactly sure how we can get a beta subdomain, though the
>>>>>> staging
>>>>>>>> one is built in. And while it would be great to automate as much as
>>>>>>>> possible about the release process in GHA, the code signing aspect is
>>>>>> still
>>>>>>>> not possible (though we might be able to integrate with another service
>>>>>> at
>>>>>>>> Apache for that, but it doesn’t cover the GPG signature). There’s also
>>>>>> some
>>>>>>>> ASF rule I think about releases needing to be done by a human, but that
>>>>>>>> might be more about reproducible builds.
>>>>>>>>> 
>>>>>>>>> Matt Sicker
>>>>>>>>> 
>>>>>>>>>> On Oct 15, 2021, at 05:57, Volkan Yazıcı  wrote:
>>>>>>>>>> 
>>>>>>>>>> I long had the ambition to move the entire site & manual to 
>>>>>>>>>> gh-pages.
>>>>>>>>>> In an ideal world, I would even move the release process to GitHub
>>>>>>>> Actions
>>>>>>>>>> too.
>>>>>>>>>> But these are, for now, pretty ambitious goals.
>>>>>>>>>> What I would really appreciate is to access gh-pages content via, 
>>>>>>>>>> say,
>>>>>>>>>> https://beta.logging.apache.org/log4j URL.
>>>>>>>>>> Matt, mind helping me with setting this up please?
>>>>>>>>>> 
>>>>>>>>>>> On Wed, Oct 13, 2021 at 7:12 PM Matt Sicker 
>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> That's really cool! Do note that we can publish to the ASF-specific
>>>>>>>>>>> branches, too, for hosting a site.
>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Oct 13, 2021 at 10:37 AM Volkan Yazıcı 
>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Do this:
>>>>>>>>>>>> 
>>>>>>>>>>>> git fetch -p
>>>>>>>>>>>> git checkout -B gh-pages origin/gh-pages
>>>>>>>>>>>> python -m http.server
>>>>>>>>>>>> open http://localhost:8000/benchmark/results/index.html
>>>>>>>>>>>> 
>>>>>>>>>>>> *The magic:*
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>> https://github.com/apache/logging-log4j2/blob/release-2.x/.github/workflows/benchmark.yml
>>>>>>>>>>>> 
>>>>>>>>>>>> *Disadvantages:* Runner specs are on the flux, though mostly pretty
>>>>>>>>>>> stable.
>>>>>>>>>>>> 
>>>>>>>>>>>> *Future work:*
>>>>>>>>>>>> 
>>>>>>>>>>>> - Enable GitHub pages for the project?
>>>>>>>>>>>> - Incorporate more from log4j-perf to here.
>>>>>>>>>>>> - Put the workflow onto a cron schedule.
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 

Re: maven-shaded-log4j-transformer

[Apache]

Question: Do we want it as a sub-module or as a new git repo with its own 
release?

Ralph

> On Oct 15, 2021, at 6:50 AM, Eduard Gizatullin  wrote:
> 
> Hello dear log4j team
> 
> Volkan Yazıcı asked me to make  maven-shaded-log4j-transformer
> <https://github.com/edwgiz/maven-shaded-log4j-transformer> a part of
> log4j2  and I tend to accomplish the proposal.
> 
> Can you please confirm that
> new sub-module name  log4j-maven-shade-plugin is ok
> 
> Any preliminary advice will be appreciated
> 
> 
> --
> Best regards,
> Ed
> 
> 
>> On Fri, Oct 15, 2021 at 1:39 PM Volkan Yazıcı  wrote:
>> 
>> Thanks for the prompt (and positive!) reply Eduard!
>> I think it is best to first lay out the details of the plan in a post to the
>> dev mailing list <https://logging.apache.org/log4j/2.x/mail-lists.html>.
>> For instance, the module name, transformer name, documentation changes,
>> etc.
>> This will give others an opportunity to share their feedback and remarks.
>> Then simply create a JIRA <https://issues.apache.org/jira/projects/LOG4J2>
>> ticket and submit a GitHub <https://github.com/apache/logging-log4j2> PR.
>> 
>> `master` branch targets Log4j 3, which is not released yet.
>> It uses a different plugin loading mechanism than the one used in Log4j 2.
>> Log4j 3 doesn't suffer from this "override of plugins after shading"
>> problem.
>> Hence, the PR needs to target the `release-2.x` branch.
>> 
>> Also note that since this is a non-trivial contribution, you need to sign the
>> ICLA document <https://www.apache.org/licenses/icla.pdf> and email it to
>> the ASF .
>> Once you have done this, it is good to mention this in the dev mailing
>> list.
>> 
>> On Fri, Oct 15, 2021 at 12:26 PM Eduard Gizatullin 
>> wrote:
>> 
>>> Hello Volkan,
>>> 
>>> Thank you for letting me know, I'm all for it.
>>> 
>>> Couldn't you please confirm that target branch is master
>>> and log4j-maven-plugins is ok as new name of submodule
>>> 
>>> Any other advices will be appreciated,
>>> 
>>> --
>>> Best regards,
>>> Ed
>>> 
>>> 
>>>> On Fri, Oct 15, 2021 at 10:10 AM Volkan Yazıcı  wrote:
>>> 
>>>> Hello,
>>>> 
>>>> My name is Volkan Yazici and I am a PMC committee member of the ASF
>>>> Logging Services, which develops Log4j too.
>>>> maven-shaded-log4j-transformer
>>>> <https://github.com/edwgiz/maven-shaded-log4j-transformer> plugin
>>>> addresses an important shortcoming of the Log4j 2.x plugin design surfacing
>>>> when users want to shade it. We have recently had a chat about it in
>>>> the mailing list
>>>> <https://lists.apache.org/thread.html/rcfa4fc8678642a51e3a69dd2b14848fe4e1e5b71de7c99a7b55ff182%40%3Cdev.logging.apache.org%3E>,
>>>> and the maintainers (incl. me) are inclined to ship it as a part of the
>>>> Log4j project. Would you like to contribute it yourself in the form of a
>>>> GitHub PR? Note that this route is subject to update-push-review cycles,
>>>> yet they are pretty rewarding for both parties, IMHO. What do you think?
>>>> 
>>>> Kind regards.
>>>> 
>>> 

Re: broken Log4j2Plugins.dat in the shaded benchmarks.jar of log4j-perf

[Apache]

We could include it in Log4J. Does master work out of the box?

Ralph

> On Oct 13, 2021, at 12:23 AM, Volkan Yazıcı  wrote:
> 
> 
> I have done something really nasty in the release-2.x branch to fix 
> benchmarks.jar generated by log4j-perf. Since a picture is worth a thousand 
> words, I am sharing two:
> 
> 
> 
> (In case images get truncated, see commit 4049240c.)
> 
> In a nutshell, Log4j2Plugins.dat of the shaded benchmarks.jar doesn't contain 
> log4j-layout-template-json plugins due to overrides taking place during 
> shading. This problem rendered the JsonTemplateLayout benchmarks broken after 
> JTLs migration to plugins. Using a 3rd party Maven plugin circumventing a 
> Log4j bug in the Log4j project itself felt pretty unpleasant to me. Is there 
> any other way I could have solved this?

Re: Json Template Layout event delimiter

[Apache]

I don’t think anyone passing an escape sequence expects it to show up as a 
string. So I would be good with your proposed solution. That method should be 
part of core so we can modify all Layouts to use it.

Ralph

> On Sep 13, 2021, at 12:29 AM, Volkan Yazıcı  wrote:
> 
> I had addressed this issue in 2020 July in a post titled "String parameter
> with escapes (Was: Testing Json Template Layout)"
> .
> For one, *the issue is not specific to JTL*, but applies to almost every
> layout accepting a parameter to be emitted along with the normal output.
> Back then, the discussion focused on the null (\0) character needed by
> SocketAppender for GELF layout in JTL. In the post, I suggested adding
> something similar to `translateEscapes()` of Java 13. This would allow
> users to pass escape characters with any string literal in any
> configuration format; XML, YAML, properties, etc. Contrasting this with
> your proposal for treating certain special inputs (e.g., "null", "Form
> Feed") differently, for me, is not different than implementing a
> `translateEscapes()`. I personally think this is even worse, since we
> introduce a new syntax, whereas the former sticks to the standard Java
> string syntax.
> 
> In conclusion, I propose adding a `translateEscapes()` clone and using that
> to read `eventDelimiter` and deprecating `nullEventDelimiterEnabled`, since
> `nullEventDelimiterEnabled` will simply translate to setting
> `eventDelimiter` to `\0`. This breaks the backward compatibility of
> `eventDelimiter`, since there might be users out there who set their
> `eventDelimiter` to `\t\r\n` and was expecting to get that string literal
> as is. Yet, given the relatively recent introduction of the plugin, I think
> we can take this risk.
> 
>> On Mon, Sep 13, 2021 at 6:14 AM Ralph Goers 
>> wrote:
>> 
>> I have been working on getting a configuration that works with filebeat
>> going again and have been
>> trying to change the line delimiter so I could avoid doing the multiline
>> crap. I first configured
>> eventDelimiter=“\f” since filebeat supports that as a replacement for
>> newline. Except no matter
>> how hard I tried I couldn’t get filebeat to log anything to stdout.
>> 
>> I spent hours looking at it before I finally realized that the logs being
>> written actually had “\f” in
>> the string instead of a form feed character. It seems that XML must be
>> passing in the value
>> treating the “\” as if it is escaped.  To remedy this the only solution I
>> could come up with was
>> 
>> > locationInfoEnabled="true">
>>  
>> 
>> It seems that XML doesn’t allow a form feed character specified that way.
>> This caused filebeat
>> to start recognizing the log events.  I would suggest that we may want to
>> change eventDelimiter
>> to accept enum names instead of or in addition to characters, which is
>> what filebeat does. So
>> one could specify eventDelimiter=“Form Feed”.
>> 
>> Ralph

Re: Log4Go

[Apache]

Sorry Christopher. I am traveling on vacation and finding it difficult to do 
anything really useful this week.

Ralph

> On Jul 9, 2021, at 3:29 AM, Christofer Dutz  wrote:
> 
> Ok ...
> 
> so I'm signing off ... guess I'll go the route of adding a sub-project 
> in PLC4X to provide the things I need.
> 
> Chris
> 
> 
>> On 08.07.21 11:46, Christofer Dutz wrote:
>> (Re sending as I noticed my first message went to only Davyd and not the
>> list)
>> 
>> Hi Davyd,
>> 
>> I was talking about a document in Confluence ... not a git repo.
>> And I guess I can help with all the getting started, once we've decided
>> on a plan.
>> 
>> Chris
>> 
>>> On 07.07.21 09:52, Davyd McColl wrote:
>>> Hi Ralph
>>> 
>>> I can't create a repo under the apache org on GitHub. I'm also perhaps not 
>>> the best person to start off the project - I'm still very new to Go, having 
>>> only worked a bit in it - learned enough to have had two PRs accepted to 
>>> lazygit (https://github.com/jesseduffield/lazygit) and I'm not sure of the 
>>> generally-accepted defaults / layout / structures for go projects. When I 
>>> raised my paw, it was largely because I'd like to learn from people who do 
>>> have this kind of experience (: I've found that working on lazygit has made 
>>> me learn more than following a course, not in the least because there's 
>>> existing code and structure there and people to tell me when I Do It Wrong 
>>> :D
>>> 
>>> I'm still very happy to be involved in log4go (assuming it's called that).
>>> 
>>> -d
>>>> On 2021/07/01 17:23:40, Ralph Goers  wrote:
>>> Davyd,
>>> 
>>> You have commit rights but I am not sure if that gives you the ability to 
>>> create a new repo. But before doing that I would create a confluence page 
>>> to lay out the initial requirements and design.
>>> 
>>> If you can’t create a repo and would like one I can certainly help with 
>>> that.
>>> 
>>> Ralph
>>> 
>>>> On Jun 30, 2021, at 12:44 PM, Davyd McColl wrote:
>>>> 
>>>> I'm rather new to go, but looking for ways to improve by writing code 
>>>> alongside people who actually know what they're doing. If I can help, 
>>>> please ping me.
>>>> 
>>>> -d
>>>> 
>>>> 
>>>> On June 30, 2021 18:12:46 Christofer Dutz wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> and sorry for being late to the party ;-)
>>>>> 
>>>>> I am currently working hard on PLC4X' Go support and am also using what I 
>>>>> create in the Open-Source project in some larger corporate applications.
>>>>> 
>>>>> One thing that has always bugged me with go, was the inavailability of 
>>>>> loggers that allow me to set different log levels for different parts of 
>>>>> the application. In go with every half-efficient logging framework, it's 
>>>>> an all or nothing thing. So if I want to track down a problem in my 
>>>>> driver for protocol X and I switch logging to TRACE it's like trying to 
>>>>> drink out of an open fire-hose.
>>>>> 
>>>>> What I would love to do as a first step, and I don't think it should be 
>>>>> too complicated, would be to create a Go API that allows us to define 
>>>>> hierarchies of log levels, just like we know them in the Java world. This 
>>>>> API would be used in the application to log, but it wouldn't actually do 
>>>>> any logging but internally sort of use an underlying framework (possibly 
>>>>> auto configured to TRACE or the most talkative log level) and forward log 
>>>>> requests to that if it passes the filter criteria.
>>>>> 
>>>>> So in PLC4Go for example we could use this Go Logging API. If my company 
>>>>> now uses logrus or zerolog, then all we have to do in that application is 
>>>>> initialize the log4go system (I know there's a project using that name 
>>>>> pattern ... I'm referring to something we built) with the corresponding 
>>>>> adapter.
>>>>> 
>>>>> What do you think? I'm not one of these "I whish someone would build X 
>>>>> for me" folks ... I am willing to put quite some effort into something 
>>>>> like this. But I think it should be in a project 

Re: Log levels on a schedule

[Apache]

That would be exactly right. I would create a TimeFilter that is very much like 
the DynamicThresholdFilter but instead of using an MDC key it woul use a time 
frame. 

This would be interesting as it could be implemented to either check the time 
in the event for every request or it could create a background thread that 
changes the log level to filter on based on the times. I’d probably opt for the 
second approach.

Ralph

> On May 3, 2021, at 5:33 AM, Gary Gregory  wrote:
> 
> I just had an interesting request: Debug logging produces a ton of output
> and what is being debugged only happens in a specific time window. How can
> we configure debug logging to enable in a time window...?
> 
> Any thoughts on this? Can a TimeFilter be configured to only filter debug
> events?
> 
> Gary

Re: Running "master" tests in IntelliJ IDEA after Java 11 upgrade

[Apache]

I will be honest. I have never tun any log4j tests in IntelliJ. I rarely do it 
for any projects I work on. I use JVM remote debug all the time. I don’t want 
to force others to have to do that, but I just never think about it. 

I use various versions of Maven from time to time. 3.6.1 is the default on my 
Mac but I just installed 3.8.1 to validate what I needed to change in my setup 
to make it still work with my employers Nexus repository which still uses http.

When I am working on Log4J stuff I do a full mvn clean install several times a 
day. That takes a huge amount of time so I have learned to multitask and work 
on other stuff while builds are running.

Ralph.

> On Apr 7, 2021, at 12:15 AM, Volkan Yazıcı  wrote:
> 
> Ralph, when you delete the IDEA-specific configuration (i.e., *.iml files
> and .idea directory), compile the sources via Maven, and open the folder in
> IDEA, can you run *any* tests? If so, do you have any custom IDEA
> configurations? Which IDEA version are you using? If you are not using the
> wrapper, which Maven version are you using?
> 
> I use Maven Wrapper to make sure Maven behaves the same in all
> environments, independent of my local setup. It also saves you from a local
> Maven dependency.
> 
>> On Wed, Apr 7, 2021 at 1:17 AM Ralph Goers 
>> wrote:
>> 
>> I deleted the files from my local repo and restarted the build. It is
>> running along just fine - at least until it hits json template layout.
>> 
>> Is there a reason you use the maven wrapper instead of Maven itself? I
>> have never used the wrapper. I am wondering if there is something going on
>> there.
>> 
>> Ralph
>> 
>>> On Apr 6, 2021, at 4:10 PM, Ralph Goers 
>> wrote:
>>> 
>>> I’ve never seen that. What is maven-annotations-production:log4j-api?
>>> 
>>> Let me try removing the files from my maven local repo as you did.
>>> 
>>> Ralph
>>> 
>>>> On Apr 6, 2021, at 1:14 PM, Volkan Yazıcı 
>> wrote:
>>>> 
>>>> As subject hints, I am not able to run tests in IDEA anymore after Java
>> 11
>>>> upgrade. I have deleted all IDEA related files and issued a clean Maven
>>>> build:
>>>> 
>>>> $ rm -rf ./.idea ./**/*.iml
>>>> $ rm -rf ~/.m2/repository/org/apache/logging/log4j/*/3*-SNAPSHOT
>>>> $ ./mvnw clean install -DskipTests=true
>>>> 
>>>> Opened the directory using IDEA (2021.1 RC), but couldn't get it to have
>>>> successful build:
>>>> 
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-core/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-plugins/target/generated-test-sources/test-annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-layout-template-json/target/generated-test-sources/test-annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-plugins/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-layout-template-json/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-layout-jackson-json/target/generated-sources/annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> W: Output path
>>>> 
>> /home/vy/Projects/log4j/3/log4j-core/target/generated-test-sources/test-annotations
>>>> intersects with a source root. Only files that were created by build
>> will
>>>> be cleaned
>>>> 
>>>> *E: Cannot build maven-annotations-production:log4j-api because it is
>>>> included into a circular dependency (module 'log4j-api' production,
>>>> maven-annotations-production:log4j-api, module 'log4j-plugins'
>> production,
>>>> maven-annotations-production:log4j-plugins)E: Cannot build
>>>> maven-annotations-test:log4j-plugins because it is included into a
>> circular
>>>> dependency (maven-annotations-test:log4j-plugins, module 'log4j-api'
>> tests,
>>>> maven-annotations-test:log4j-api, module 'log4j-plugins' tests)*
>>>> 
>>>> Did you get it working? What shall I do to make it work?
>>> 
>>> 
>>> 
>> 
>> 
>> 

Re: [logging-pipelines] branch master updated: Use Java 11 for master branch

[Apache]

Can we not require a Jenkinsfile in each project that sets properties to 
control the behavior?

Ralph

> On Apr 6, 2021, at 6:45 AM, Matt Sicker  wrote:
> 
> Oops, good point. I need to make the version selection a little more
> sophisticated. Probably a branch or something for the shared lib.
> 
>> On Tue, Apr 6, 2021 at 01:56 Ralph Goers  wrote:
>> 
>> I took care of the failure on verify. I added a clean to log4j-api so it
>> will clean every time.
>> 
>> Ralph
>> 
>>> On Apr 5, 2021, at 10:55 PM, Ralph Goers 
>> wrote:
>>> 
>>> Matt,
>>> 
>>> A couple of comments
>>> This doesn’t seem right. Log4j-audit, Kotlin, and Chainsaw all use the
>> mvn command. This will modify them to use Java 11 instead of Java 8. Did we
>> really want to do that?
>>> The Jenkins build is still failing. The first phase that compiles works
>> but the second phase that runs the unit test bails because it tries to
>> recompile everything without doing a clean first. That means it will find
>> the module-info class when it tries to compile Activator and that will fail
>> because org.osgi.core is not in the module-info. It can’t be since OSGi
>> isn’t JPMS compatible - which is another reason why the code had to be
>> compiled separately from the module-info.java file. I’m really curious -
>> why do you run mvn twice and just not skip tests the first time?
>>> 
>>> Ralph
>>> 
 On Apr 5, 2021, at 2:18 PM, mattsic...@apache.org wrote:
 
 This is an automated email from the ASF dual-hosted git repository.
 
 mattsicker pushed a commit to branch master
 in repository https://gitbox.apache.org/repos/asf/logging-pipelines.git
 
 
 The following commit(s) were added to refs/heads/master by this push:
   new 10333f7  Use Java 11 for master branch
 10333f7 is described below
 
 commit 10333f76c589fa45e80db878895ad19cfcaba11c
 Author: Matt Sicker 
 AuthorDate: Mon Apr 5 16:18:13 2021 -0500
 
  Use Java 11 for master branch
 ---
 vars/mvn.groovy | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)
 
 diff --git a/vars/mvn.groovy b/vars/mvn.groovy
 index bf15449..647a15f 100644
 --- a/vars/mvn.groovy
 +++ b/vars/mvn.groovy
 @@ -17,10 +17,11 @@
 
 def call(String args) {
   if (isUnix()) {
 +String javaHome =
>> "/home/jenkins/tools/java/latest${BRANCH_NAME == 'master' ? '11' : '1.8'}"
   configFileProvider([configFile(fileId: 'ubuntu', variable:
>> 'TOOLCHAINS')]) {
   withEnv([
 -'JAVA_HOME=/home/jenkins/tools/java/latest1.8',
 -
>> 'PATH+MAVEN=/home/jenkins/tools/maven/latest3/bin:/home/jenkins/tools/java/latest1.8/bin'
 +"JAVA_HOME=${javaHome}",
 +
>> "PATH+MAVEN=/home/jenkins/tools/maven/latest3/bin:${javaHome}/bin"
   ]) {
   // note that the jenkins system property is set here to
>> activate certain pom properties in
   // some log4j modules that compile against system jars
>> (e.g., log4j-jmx-gui)
 @@ -28,10 +29,11 @@ def call(String args) {
   }
   }
   } else {
 +String javaHome =
>> "f:\\jenkins\\tools\\java\\latest${BRANCH_NAME == 'master' ? '11' : '1.8'}"
   configFileProvider([configFile(fileId: 'windows', variable:
>> 'TOOLCHAINS')]) {
   withEnv([
 -'JAVA_HOME=f:\\jenkins\\tools\\java\\latest1.8',
 -
>> 'PATH+MAVEN=f:\\jenkins\\tools\\maven\\latest3\\bin;f:\\jenkins\\tools\\java\\latest1.8\\bin'
 +"JAVA_HOME=${javaHome}",
 +
>> "PATH+MAVEN=f:\\jenkins\\tools\\maven\\latest3\\bin;${javaHome}\\bin"
   ]) {
   bat "mvn --toolchains \"%TOOLCHAINS%\" ${args}"
   }
 
>>> 
>> 
>> 
>> 

Re: Switching Spring Boot from Logback to Log4j

[Apache]

Yes, I saw the update when I woke up in the middle of the night. We use Spring 
a lot at Nextiva so making the two interoperate nicely is important to me.

Ralph

> On Apr 6, 2021, at 6:23 AM, Volkan Yazıcı  wrote:
> 
> For those who don't know yet, Spring Boot considers switching from Logback
> to Log4j .
> Ralph is performing a great lobbying example there. Recently the ticket has
> been updated with the following feature checks I have attached below.
> Spring Boot will make a great customer for many perspectives of the Log4j
> project; visibility, improvements, stability, etc. I am personally really
> excited about this development and watching it closely. I wanted to share
> these news with the rest of you.
> 
> -- Forwarded message -
> From: Andy Wilkinson 
> Date: Tue, Apr 6, 2021 at 10:42 AM
> Subject: Re: [spring-projects/spring-boot] Investigate impact of switching
> default logging system to log4j2 (#22149)
> To: spring-projects/spring-boot 
> Cc: Volkan Yazıcı , Manual <
> man...@noreply.github.com>
> 
> 
> @rgoers  Thank you.
> 
> One area that's just come up is providing log4j2-based support for the
> 
> 
> and the 
> 
> elements that we currently support with Logback.
> 
>  is rather like a lookup and is quite similar to the
> existing Spring Boot lookup.  doesn't have a dependency on
> Spring Cloud whereas it appears the Log4j2's Spring Boot lookup does?
> 
>  provides some basic conditional configuration support,
> allowing configuration to be applied based on the Spring profiles that are
> active. From what I've seen, there isn't something similar in Log4j2 at the
> moment.
> 
> Spring Boot 3 is by no means imminent (it won't be in 2021) so there's no
> urgency here at the moment, but it would be interesting to explore what
> plugging  and  support into Log4j2 might
> look like.
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .

Re: Review request: LOG4J2-3004 JsonTemplateLayout plugin support

[Apache]

Yeah, sorry for not getting to that. I will still look at it though.

Ralph

> On Apr 3, 2021, at 3:19 AM, Volkan Yazıcı  wrote:
> 
> Ralph, I know you are pretty busy with the Java 11 migration on master.
> I will merge this branch onto release-2.x and then cherry-pick into master.
> I need to get this in, so that I can continue working on other JTL tickets.
> 
>> On Mon, Mar 22, 2021 at 9:54 PM Ralph Goers 
>> wrote:
>> 
>> I will try to get to it this evening.
>> 
>> Ralph
>> 
>>> On Mar 22, 2021, at 1:26 PM, Volkan Yazıcı 
>> wrote:
>>> 
>>> Hello,
>>> 
>>> I have created a GitHub PR (#476)
>>> <https://github.com/apache/logging-log4j2/pull/476> addressing
>> LOG4J2-3004
>>> JsonTemplateLayout plugin support
>>> <https://issues.apache.org/jira/browse/LOG4J2-3004>. I needed to make a
>>> small (backward-compatible) change to TypeConverterRegistry and I have
>> some
>>> troubles with AsciiDoc. These and more are mentioned in the description
>> of
>>> the PR. I will appreciate it a lot if somebody could review the changes.
>>> 
>>> Cheers!
>> 
>> 
>> 

Re: Please do not commit to log4j2 master - but review this PR.

[Apache]

Actually, they don’t disappear. They just move to closed status. I believe you 
can still comment but it is far less noticeable after it is merged. Really, I 
suggest you check out the branch and build it. I really didn’t change much 
code. I mostly moved it around and changed whatever was needed to make 
log4j-api and Log4J-plugins real JPMS modules in Java 11.

Ralph

> On Mar 31, 2021, at 11:57 PM, Volkan Yazıcı  wrote:
> 
> I am still reviewing it.
> As Matt noted, you can merge it.
> This said, I'd appreciate an extra week.
> It is easier to discuss changes over GitHub PR.
> Once committed, PR will disappear.
> 
>> On Thu, Apr 1, 2021 at 5:58 AM Ralph Goers 
>> wrote:
>> 
>> FYI - I plan on merging this code Friday morning MST unless my schedule
>> changes between now and then.
>> 
>> Ralph
>> 
>>> On Mar 29, 2021, at 3:58 PM, Ralph Goers 
>> wrote:
>>> 
>>> I should have added that you may need a recent version of the JDK. I
>> forget what error I was encountering but upgrading the JDK to a later
>> version fixed it. But then I noticed that the Google java allocation
>> instrumenter wasn’t working and it had to be upgraded too.
>>> 
>>> Ralph
>>> 
>>>> On Mar 29, 2021, at 3:51 PM, Matt Sicker  wrote:
>>>> 
>>>> I’ll make sure to look more closely at it this week. Nice work on
>>>> simplifying the modules a bit!
>>>> 
>>>> On Sun, Mar 28, 2021 at 18:24 Ralph Goers 
>>>> wrote:
>>>> 
>>>>> I have created https://github.com/apache/logging-log4j2/pull/480 for
>> you
>>>>> to review. It has many changes and merge conflicts will be painful to
>> fix
>>>>> so please do not commit to master until this PR is merged.
>>>>> 
>>>>> Although I could merge this now I would prefer if you could checkout
>> the
>>>>> branch on your local machines, build, and test it. I haven’t tested it
>> with
>>>>> anything real yet but all the unit tests - except for the osgi module -
>>>>> pass.
>>>>> 
>>>>> If you open this in your IDE you might have some issues with some test
>>>>> classes being flagged as having compile issues. This is because of the
>>>>> weird extra directory I had to include in log4j-api and log4j-plugins
>> to
>>>>> create test jars.
>>>>> 
>>>>> Please provide feedback so I can make any changes and get this merged.
>>>>> 
>>>>> Ralph
>>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 

Re: Another JsonTemplateLayout question on StackOverflow....

[Apache]

I just go periodically and search for “Log4j2” newest.


Ralph

> On Mar 31, 2021, at 4:32 AM, Volkan Yazıcı  wrote:
> 
> Thanks! Replied.
> 
> Ralph, how do you track SO questions? I am watching log4j and log4j2 tags,
> though I don't see any notifications. In particular, I was expecting to get
> notified by e-mail.
> 
>> On Wed, Mar 31, 2021 at 7:27 AM Ralph Goers 
>> wrote:
>> 
>> 
>> https://stackoverflow.com/questions/66832654/how-to-set-jsontemplatelayout-eventtemplateuri-outside-of-classpath-in-log4j2
>> 
>> Ralph
>> 

Re: unable to build from source

[Apache]

I was just about to ask what platform you were building on. I can run other 
operating systems in a VM to try to duplicate the problem. Aloso, in this case 
knowing what your default locale is would probably help.

Ralph

> On Dec 9, 2020, at 12:17 AM, Joseph Tsai  wrote:
> 
> 
> I have been trying to figure out why I'm failing the assertion test
> 
> 
> So far from looking at LocalizedMessage.java
> 
> I think $locale is always null and therefore $bundle is always null, and this 
> sets $msgPattern to $myKey which $myKey is just "hello_world". And eventually 
> the getFormattedMessage() would just chain return $formattedMessage.
> 
> But in ParameterizedMessage.java, $formattedMessage is set to be $buffer's 
> content
> 
> 
> And $buffer would get its content from $messagePattern in 
> ParameterFormatter.java, which is just "hello_world"
> 
> 
> So I'm getting the fix would be to have $locale != null with some default 
> value when passed in to getResourceBundle()? I don't know, I could be way 
> wrong on my whole analysis and the problem is not actually related to what I 
> think it is at all.
> 
> 
>> On Wed, 9 Dec 2020 at 03:37, Ralph Goers  wrote:
>> You are making progress! I saw those same errors in one of our automated 
>> builds the other day. I am not sure what the problem is but haven’t looked 
>> into it yet.
>> 
>> Ralph
>> 
>> > On Dec 8, 2020, at 9:23 AM, Joseph Tsai  wrote:
>> > 
>> > I kinda inferred that from reading the mvnw script when Volkan directed me 
>> > to run command. So I exported JAVA_HOME=[path/to/my/Java8] into my .bashrc 
>> > and I'm not failing the same thing anymore.
>> > 
>> > But I'm still getting errors, this time it is failing some unit tests from 
>> > the surefire plugin. I tried to fix it but I couldn't.
>> > 
>> > 
>> > 
>> > From reading some 
>> > <https://stackoverflow.com/questions/36427868/failed-to-execute-goal-org-apache-maven-pluginsmaven-surefire-plugin2-12test/55835974>
>> >  StackOverflow 
>> > <https://stackoverflow.com/questions/46831762/maven-build-and-maven-failsafe-plugin-the-forked-vm-terminated-without-properl>
>> >  posts, it seems to have something to do with the surefire plugin version 
>> > number? I tried to downgrade it to some lower versions but it didn't work.
>> > 
>> > I have also attached a zip of the surefire reports.
>> > 
>> > Thanks,
>> > 
>> > 
>> > On Wed, 9 Dec 2020 at 02:37, Matt Sicker > > <mailto:boa...@gmail.com>> wrote:
>> > The full build isn't compatible with Java 11 yet, so you need both 8 and 11
>> > configured in a toolchains.xml config. Then you need to use Java 8 as the
>> > default JVM (or at least the contents of JAVA_HOME), and the build will
>> > switch to higher version compilers for the modules that require it.
>> > Ideally, the build would be updated to simplify this, but it's a fairly
>> > difficult problem as it's still a relatively new area in Maven with
>> > multiple alternatives to how to support it.
>> > 
>> > On Tue, 8 Dec 2020 at 08:13, Volkan Yazıcı > > <mailto:volkan.yaz...@gmail.com>> wrote:
>> > 
>> > > Would you mind changing the default JDK you start *mvnw* to version 8 and
>> > > retrying via *./mvnw clean package -DskipTests*, please? (Here *clean*
>> > > goal is necessary for removing the class files compiled earlier with the
>> > > wrong JDK.)
>> > > [Sorry for the short answer, struggling with my day-job in the meantime.]
>> > >
>> > > On Tue, Dec 8, 2020 at 3:02 PM Joseph Tsai > > > <mailto:jtsa0...@gmail.com>> wrote:
>> > >
>> > >> Hi Volkan,
>> > >>
>> > >> I just installed both JDK8 and 11 and tried to do mvn clean install. The
>> > >> same error persists, and I think it's looking at my default Java
>> > >> installation?
>> > >> Running "sudo update-alternatives --config java" shows the following:
>> > >> [image: image.png]
>> > >> Currently it is defaulted to Java15, and everytime I change the default
>> > >> Java the wrong version circled in blue changes.
>> > >> [image: image.png]
>> > >> I also looked up what version 53 is, it is apparently Java9?
>> > >>
>> > >> My questions are:
>> > >>
>> > >>- Am I supposed to update the default Java to Java1

Re: Tidying up JIRA after 2.14.0 release

[Apache]

I will take care of 1 & 2 and will check your Jira permissions. The next 
release will be 2.14.1 unless new enhancements are added.

Our general policy has been to mark issues resolved and ask users to close them 
when they verify the fix. It would be nice if Jira would automatically close 
them after some amount of time if users don’t.

Ralph

> On Nov 13, 2020, at 1:02 AM, Volkan Yazıcı  wrote:
> 
> Hello,
> 
> I have a couple of questions and requests regarding the JIRA board:
> 
>   1. 2.14.0 appears to be not released yet, would anybody mind marking it
>   as released, please? (I couldn't pull it out myself. I am not sure if it is
>   due to my insufficient JIRA experience or privileges.)
>   2. Would you also create the 2.15.0 release, please?
>   3. Some issues are marked as RESOLVED and some as CLOSED. Do we have a
>   certain preference? Shall I close all resolved issues?
> 
> Kind regards.

Re: Log4j 2.14.0 release status

[Apache]

The public repo is most likely a group repo configured with both the release 
repo and the snapshot repo.that way by configuring Maven to use the public repo 
builds can access both releases and snapshots.  But all the snapshots only 
exist in the snapshot repo.

Ralph

> On Nov 1, 2020, at 6:08 AM, Gary Gregory  wrote:
> 
> Very odd indeed, the public (non-snapshot) repository is full of snapshots:
> 
> https://repository.apache.org/content/groups/public/org/apache/logging/log4j/log4j-core/
> 
> Gary
> 
>> On Sun, Nov 1, 2020, 00:51 Ralph Goers  wrote:
>> 
>> I started the process of preparing for the release today. The Maven site
>> build is failing because somehow a version named 2.14.0—SNAPSHOT was
>> uploaded to the Nexus Snapshot repository.  While investigating I noticed
>> that there is at least one snapshot for every past release so Nexus
>> apparently is not configured to delete snapshots after a release is
>> performed.
>> 
>> I’ve asked in Slack to have all the snapshots under logging be deleted but
>> I suspect I will need to create a Jira issue. In my experience Jira isn’t
>> especially quick about acting on these so I don’t know when I will be able
>> to proceed. Matt or Gary, if you have more karma then me for some reason
>> please see what you can do.
>> 
>> Ralph
>> 

Re: [VOTE] [log4net] Release 2.0.11

[Apache]

You need to close the vote thread with the results first before performing the 
final release steps.

Ralph

> On Oct 25, 2020, at 11:24 PM, Davyd McColl  wrote:
> 
> Thanks Ralph
> 
> Could you assist with getting artifacts up to downloads.apache.org? I'm going 
> to push the nupkg because people are waiting on it, and will have to set the 
> new documentation live because people will expect it, but right now, the 
> download links are broken.
> 
> Thanks
> -d
> 
> On 2020/10/25 01:21:15, Ralph Goers  wrote:
> My +1
> 
> Ralph
> 
>> On Sep 22, 2020, at 11:21 PM, Davyd McColl wrote:
>> 
>> Thanks all; I've completed the release as far as I can (Ralph, please push 
>> the relevant artifacts from 
>> https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.11 the last 
>> mile) and pushed the nuget package.
>> 
>> -d
>> 
>> On 2020/09/22 17:34:34, Matt Sicker wrote:
>> +1
>> 
>>> On Tue, Sep 22, 2020 at 04:23 Dominik Psenner wrote:
>>> 
>>> +1
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>>> 
>>> them.
>>> 
>>> 
>>> 
>>>> On Tue, Sep 22, 2020, 08:37 Davyd McColl wrote:
>>> 
>>> 
>>> 
>>>> Hi all
>>> 
>>>> 
>>> 
>>>> I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out
>>> 
>>>> the door because it fixes confusing versioning on the released binaries
>>> (in
>>> 
>>>> particular, nuget consumers)
>>> 
>>>> 
>>> 
>>>> Thanks
>>> 
>>>> -d
>>> 
>>>>> On 2020/09/20 22:33:49, Matt Sicker wrote:
>>> 
>>>> I can use whatever.
>>> 
>>>> 
>>> 
>>>>> On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
>>> 
>>>>> 
>>> 
>>>>> I don’t have google meet and I can’t use Skype since Microsoft hosed my
>>> 
>>>> authentication. I have zoom. My company uses Amazon Chime, which is
>>> fairly
>>> 
>>>> new, as part of our product offering. I’ve sent you both emails for a
>>> 
>>>> meeting using that.
>>> 
>>>>> 
>>> 
>>>>> Ralph
>>> 
>>>>> 
>>> 
>>>>>>> On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:
>>> 
>>>>>> 
>>> 
>>>>>> I sent a Google Meet invite to you.
>>> 
>>>>>> 
>>> 
>>>>>>> On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:
>>> 
>>>>>>> 
>>> 
>>>>>>> I'm happy to be available at 8am my side, if that works for everyone
>>> 
>>>> else.
>>> 
>>>>>>> It sounds like earlier would be better, but I'm doing the morning
>>> 
>>>> school
>>> 
>>>>>>> run from 7am and can't guarantee I'll be back significantly before
>>> 
>>>> 8am.
>>> 
>>>>>>> 
>>> 
>>>>>>> How to do this? I have zoom and slack on my work machine, can
>>> install
>>> 
>>>>>>> Skype if that's more convenient, can do google meet, I assume,
>>> though
>>> 
>>>>>>> haven't ever tried, so may need a bit of a crash intro.
>>> 
>>>>>>> 
>>> 
>>>>>>> If posting meeting details to the mailing list is not on, feel free
>>> to
>>> 
>>>>>>> email me directly (:
>>> 
>>>>>>> 
>>> 
>>>>>>> -d
>>> 
>>>>>>> 
>>> 
>>>>>>> 
>>> 
>>>>>>>> On September 20, 2020 20:58:29 Ralph Goers wrote:
>>> 
>>>>>>> 
>>> 
>>>>>>>> 8am in Durban South Africa is 11pm the night before in Phoenix AZ.
>>> 
>>>>>>>> However, I frequently am up until midnight so that could work.
>>> 
>>>> 5-5:30 pm is
>>> 
>>>>>>>> 7:30-8 am in Phoenix. I usually am not in front of my computer on a
>>> 
>>>> weekday
>>> 
>>>>>>>> until 8 am but on occasion I can do earlier.
>>> 
>>>>>>>

Re: [log4cxx] Site / Documentation thoughts

[Apache]

Changes made to subversion will have no effect. Logging services no longer uses 
the ASF CMS.

Ralph

> On Sep 19, 2020, at 12:53 AM, Thorsten Schöning  wrote:
> 
> Guten Tag Ralph Goers,
> am Samstag, 19. September 2020 um 04:16 schrieben Sie:
> 
>> The main web site is built using JBake. Although it is Java based and still 
>> uses Maven the command to build the site is just mvn install (although it 
>> doesn’t actually do an install).  All the web pages are either Markdown or 
>> AsciiDoctor. I should also add that you don’t have to use Maven. You can 
>> always just run it from the command line although that requires installing 
>> JBake on your computer. 
> 
>> The documentation for log4cxx is already maintained in its own repo. I moved 
>> it a couple of weeks ago. It is now at 
>> https://github.com/apache/logging-log4cxx-site 
>> <https://github.com/apache/logging-log4cxx-site>.[...]
> 
> How does that interact with the still available SVN-repo? Where does one need 
> to commit changes now to update "the site"? Which is "the site" anyway, that 
> in GIT or SVN cor ...?
> 
> https://svn.apache.org/repos/infra/websites/production/logging/content/log4cxx
> 
> My current setup still builds into the SVN-repo and that's where I committed 
> last changes.
> 
> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
> 
> -- 
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
> 
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
> 
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> 
> 

Re: JsonTemplateLayout is ready to be shipped!

[Apache]

It is no problem. I have been heads down trying to get something done for work. 
Should be soon though.

Ralph

> On Sep 11, 2020, at 4:40 AM, Volkan Yazıcı  wrote:
> 
> Hey Ralph! This is your friendly reminder for the pending 2.x release.
> (Apologies for the inconvenience.)
> 
>> On Thu, Aug 27, 2020 at 3:55 PM Apache  wrote:
>> 
>> No, you are not expected to do anything else. While anyone can be the
>> release manager, typically I have been doing them. They take a fair amount
>> of time so I typically start them on a weekend when I have enough time.
>> 
>> Ralph
>> 
>>> On Aug 27, 2020, at 6:14 AM, Volkan Yazıcı 
>> wrote:
>>> 
>>> Would anybody mind giving some indication on an ETA, please?
>>> Or am I expected to do anything else further?
>>> 
>>>> On Tue, Aug 25, 2020 at 1:59 PM Volkan Yazıcı 
>>>> wrote:
>>>> 
>>>> Yes, you read the subject right! I will appreciate it if people can
>> spare
>>>> some time on skimming through the change set one last time regarding
>> JTL.
>>>> 
>>>> So... When are we gonna cut the ribbon for the upcoming 2.x release?
>>>> 
>> 
>> 
>> 

Re: [log4net] cleaning up JIRA

[Apache]

It is good that you are letting others know your plans. As the only formal 
Log4Net committer you are free to do whatever works for you. Hopefully that 
won’t remain the case forever. 

Ralph

> On Sep 10, 2020, at 2:17 AM, Davyd McColl  wrote:
> 
> Hi all
> 
> I'd like to start (at some point) clearing up JIRA a bit and getting on top 
> of associated pull requests (for example, the one for a REST appender, 
> https://issues.apache.org/jira/projects/LOG4NET/issues/LOG4NET-644) and I'd 
> appreciate any guidance on the accepted methods. To clarify, if it were 
> solely up to me I'd:
> 
> 1. close out anything referring to really old versions of log4net or raised 
> over 2 years ago (eg 
> https://issues.apache.org/jira/projects/LOG4NET/issues/LOG4NET-514) with a 
> polite message to please re-submit if the problem persists
> 2. close out any wishlist items without a corresponding pull request with a 
> polite message to the effect that pull requests are welcome.
> 
> This is really simply a part of how I normally work -- reduce the noise so 
> that I can get stuff done.
> 
> -d

Re: [VOTE] [log4net] Release log4net 2.0.10

[Apache]

My +1

Dominic, if you are going to vote you need to do it formally.

Ralph

> On Sep 10, 2020, at 12:57 AM, Dominik Psenner  wrote:
> 
> Knowing that those changes are intentional I am confident that the next
> release is better than the last. This is reason enough to move on. If
> something breaks we can still address those issues with another future
> release.
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
> 
>> On Thu, Sep 10, 2020, 09:20 Davyd McColl  wrote:
>> 
>> Hi Dominik
>> 
>> I have had a long look over the changes (both via the PR and locally, as I
>> contributed to help with some infra changes) and I'm happy -- there's been
>> a lot of clean-up and simplification and in addition, tests are now run
>> against all targets -- so that's a good thing. Some of these changes are
>> required to resolve issues for netstandard2.0 users who have upgraded to
>> 2.0.9. Community member NicholasNoise put in a lot of work on this.
>> 
>> If it helps, the original PR is here:
>> https://github.com/apache/logging-log4net/pull/63 -- it makes viewing
>> changes a lot simpler. Changes to a lot of the #ifdefs are updates from
>> NETSTANDARD1_3 to simply NETSTANDARD as many of the changes required for
>> netstandard2.0 are compatible. I contributed on that PR too, mainly around
>> getting build to work as expected.
>> 
>> You're welcome to use the npm-based build / test pipeline to verify: I've
>> just updated master to automatically test across all platforms when running
>> `npm test`, so it should be easy to verify that all things are functional:
>> - install node if you don't have it yet (I suggest via nvm)
>> - `npm ci`
>> - `npm test`
>> 
>> (assuming that you have all the required build targets -- there are helper
>> .ps1 scripts to get the older targets -- netcore 1.1 and netfx35)
>> 
>> -d
>> 
>> 
>> On 2020/09/10 09:03:45, Dominik Psenner  wrote:
>> Hi
>> 
>> Sorry to not have responded earlier. Time is short and the days are busy. I
>> looked at the diff and found several suspicious changes. Several hundred
>> ifdefs have been removed/replaced along with tests. Therefore I have a bad
>> feeling about those changes without further careful checking. I propose to
>> release the cve fix alone and follow up a second release as soon as someone
>> had the time to verify that the netstandard2 changes are ok.
>> 
>> Best regards
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>> them.
>> 
>>> On Thu, Sep 10, 2020, 08:48 Davyd McColl wrote:
>>> 
>>> Hi
>>> 
>>> Sorry to be a bother, but I haven't heard anything back on this apart
>> from
>>> Dominik's inquiry into netstandard 1.3 support. I'd really like to get
>> this
>>> out as:
>>> a) it contains the CVE fix that has been asked about so much
>>> b) it solves some issues affecting netstandard users
>>> 
>>> Thanks
>>> -d
>>> 
>>>> On 2020/09/06 20:51:38, Davyd McColl wrote:
>>> Hi all
>>> 
>>> I'd like to propose a vote to release 2.0.10 of log4net, with:
>>> - updated netstandard 2.0 support from community member NicholasNoise
>>> - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
>>> mechanism used there is outdated for netstandard 2.0, but the principle
>>> stands
>>> 
>>> I've created an RC release at GitHub:
>>> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and
>>> pushed updated site material to the `asf-staging` branch of the
>>> logging-log4net-site repo.
>>> 
>>> Thanks
>>> -d
>> 

Re: [VOTE] Release Log4Net 2.0.9

[Apache]

Unfortunately the staging and release locations for the release artifacts are 
still using s not. But everything else is now in git. So in a release you 
should publish the web site to the asf-staging branch of the site repo and 
publish the artifacts to the dev location of the SVN dist repo. Once they are 
approved they can be published. You should have permission to publish the web 
site already.

I will try to verify your changes tomorrow.

Ralph

> On Sep 1, 2020, at 11:11 PM, Davyd McColl  wrote:
> 
> Hi Ralph
> 
> The missing tag is my fault -- I had a `rel/2.0.9` tag locally and obviously 
> forgot to push with tags ):
> 
> I've updated the source files for the site:
> - removed the mirror references
> - updated the links for 2.0.9
> - updated the link to point to the html instead of the cgi
> 
> I've also updated the README in the project to take out the dormant status 
> commentary.
> 
> Please review & update the live site if you're happy.
> 
> Previously, as I understand it, the point of the SVN staging area was to 
> provide built artifacts for the website. Since that's not in play any more, I 
> was wondering how that's going to happen now? Someone will have to build 
> before pushing. If you'd like, I could add the target folder that is built 
> into git so that it's just a matter of copying files.
> 
> I've also added an npm script around building the site, which checks if you 
> have maven available & builds if possible -- perhaps this makes it easier for 
> the next new person (:
> 
> -d
> 
> On 2020/09/02 05:20:50, Ralph Goers  wrote:
> I also just noticed that the git repo has no tag to represent 2.0.9. Without 
> a tag essentially there is no release.
> 
> Ralph
> 
>> On Aug 24, 2020, at 3:27 PM, Ralph Goers wrote:
>> 
>> The release isn’t done yet. The web site still reflects 2.0.8. Release 
>> announcements can’t be sent out until that is updated.
>> 
>> Ralph
>> 
>>>> On Aug 24, 2020, at 2:45 PM, Remko Popma wrote:
>>> 
>>> Well done, everyone!
>>> 
>>>> On Mon, Aug 24, 2020 at 10:43 PM Matt Sicker wrote:
>>> 
>>>> Thanks again for managing the release! I’m sure you’ve just made a lot of
>>>> developers happy. :D
>>>> 
>>>> On Mon, Aug 24, 2020 at 01:40 Davyd McColl wrote:
>>>> 
>>>>> Ok, log4net 2.0.9 is up on nuget.org (:
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks for all the help (:
>>>>> 
>>>>> 
>>>>> 
>>>>> -d
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2020/08/23 19:13:36, Matt Sicker wrote:
>>>>> 
>>>>> Yes, please go ahead and finish the release. The PMC approved this
>>>>> 
>>>>> during our release vote. :)
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sun, 23 Aug 2020 at 10:22, Apache wrote:
>>>>> 
>>>>>> 
>>>>> 
>>>>>> There can’t be. That is what the release vote was for.
>>>>> 
>>>>>> 
>>>>> 
>>>>>> Ralph
>>>>> 
>>>>>> 
>>>>> 
>>>>>>> On Aug 23, 2020, at 1:02 AM, Davyd McColl wrote:
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> Thanks Dominik
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> Are there any objections to me pushing the 2.0.9 package that had
>>>> been
>>>>> approved and uploaded to https://downloads.apache.org/logging/log4net/
>>>> to
>>>>> nuget.org?
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> -d
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>> 
>>>>> 
>>>>>>>> On August 23, 2020 09:59:02 Dominik Psenner wrote:
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> Davyd, I added you as a collaborator. This should grant you the
>>>>> privilege
>>>>> 
>>>>>>>> to manage packages. You can now submit new and update or unlist
>>>>> existing
>>>>> 
>>>>>>>> packages.
>>>>> 
>>>>>>>> 
>>>>> 
>>>>>>>> It would be great to have at least one other me

Re: A little stuck with publishing updated site / docs for log4net 2.0.9

[Apache]

I will take care of the main logging site. It currently uses the ASF CMS but we 
have to get off of it so there isn’t much point in you having to learn how to 
deal with it.

Ralph

> On Aug 28, 2020, at 12:26 AM, Davyd McColl  wrote:
> 
> Hi all
> 
> I've been trying to update content for http://logging.apache.org/log4net (in 
> particular http://logging.apache.org/log4net/release) and I'm sure I'm just 
> doing something silly or missing something.
> 
> I've followed instructions at 
> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
>  up to point 7, which is where I'm stuck: I'm not sure where to find the 
> mentioned index.twig, mainly because I'm not sure what the document is 
> referring to with "main web site". I haven't found an index.twig in 
> https://svn.apache.org/repos/infra/websites/production/logging/content/ or 
> https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly 
> possible I'm just missing it. Or that neither of these is the correct place 
> to look.
> 
> I have updated documentation and committed via SVN for 2.0.9, including 
> updating the 2.x link. I haven't marked the project as "not dormant" (yet -- 
> I'll be more confident to do so once I've seen a complete release with all 
> the entailed bits, including this site, so that I have some semblance of 
> confidence to do it again!). All I've done is update the release notes to 
> include the changes for 2.0.9, which I'm sure some people might appreciate, 
> minor though the changes may be.
> 
> Any assistance appreciated. I've already received much assistance from Ralph 
> and Matt (thanks!).
> 
> -d

Re: JsonTemplateLayout is ready to be shipped!

[Apache]

No, you are not expected to do anything else. While anyone can be the release 
manager, typically I have been doing them. They take a fair amount of time so I 
typically start them on a weekend when I have enough time. 

Ralph

> On Aug 27, 2020, at 6:14 AM, Volkan Yazıcı  wrote:
> 
> Would anybody mind giving some indication on an ETA, please?
> Or am I expected to do anything else further?
> 
>> On Tue, Aug 25, 2020 at 1:59 PM Volkan Yazıcı 
>> wrote:
>> 
>> Yes, you read the subject right! I will appreciate it if people can spare
>> some time on skimming through the change set one last time regarding JTL.
>> 
>> So... When are we gonna cut the ribbon for the upcoming 2.x release?
>> 

Re: Log4net: 2.0.9 release notes missing

[Apache]

I do not believe the site has been updated to reflect the release. I looked 
into it but couldn’t figure out how to build the site.

Ralph

> On Aug 24, 2020, at 6:38 AM, Dominik Psenner  wrote:
> 
> Hi
> 
> People noticed that the release notes of 2.0.9 are missing while they
> should be documented here:
> 
> http://logging.apache.org/log4net/release/release-notes.html
> 
> Best regards
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.

Re: [VOTE] Release Log4Net 2.0.9

[Apache]

e.com
>>> >> >
>>> >> >> wrote:
>>> >> >> >>
>>> >> >> >> Going back through my old emails I see Dominik had the same
>>> problem
>>> >> in
>>> >> >> 2016. I forgot to update my files and now I see the instructions have
>>> >> >> changed.
>>> >> >> >>
>>> >> >> >> Ralph
>>> >> >> >>
>>> >> >> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers <
>>> >> ralph.go...@dslextreme.com>
>>> >> >> wrote:
>>> >> >> >>>
>>> >> >> >>> I figured out that the document is now at home.apache.org <
>>> >> >> http://home.apache.org/>. Unfortunately, that didn’t do me any good.
>>> >> gpg
>>> >> >> -d is failing with “No secret key”. That doesn’t seem too surprising
>>> >> since
>>> >> >> my key wasn’t used to sign the document.
>>> >> >> >>>
>>> >> >> >>> Ralph
>>> >> >> >>>
>>> >> >> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers <
>>> >> ralph.go...@dslextreme.com>
>>> >> >> wrote:
>>> >> >> >>>>
>>> >> >> >>>> Dominik,
>>> >> >> >>>>
>>> >> >> >>>> The README file says that the keys can be found at
>>> >> >> https://people.apache.org/keys/group/logging-pmc.asc <
>>> >> >> https://people.apache.org/keys/group/logging-pmc.asc>.  That url
>>> >> returns
>>> >> >> a 404. Any idea where it moved to?
>>> >> >> >>>>
>>> >> >> >>>> Ralph
>>> >> >> >>>>
>>> >> >> >>>>> On Aug 17, 2020, at 9:39 AM, Dominik Psenner <
>>> dpsen...@gmail.com>
>>> >> >> wrote:
>>> >> >> >>>>>
>>> >> >> >>>>> I guess that would be a nuget publish.
>>> >> >> >>>>>
>>> >> >> >>>>>
>>> >> https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package
>>> >> >> >>>>>
>>> >> >> >>>>> The credentials to that account are stored in the private
>>> repos of
>>> >> >> logging
>>> >> >> >>>>> pmc. Most members of the pmc should be in the set of recipients
>>> >> with
>>> >> >> their
>>> >> >> >>>>> gpg key.
>>> >> >> >>>>> --
>>> >> >> >>>>> Sent from my phone. Typos are a kind gift to anyone who
>>> happens to
>>> >> >> find
>>> >> >> >>>>> them.
>>> >> >> >>>>>
>>> >> >> >>>>> On Mon, Aug 17, 2020, 08:56 Davyd McColl 
>>> >> wrote:
>>> >> >> >>>>>
>>> >> >> >>>>>> Great!
>>> >> >> >>>>>>
>>> >> >> >>>>>> How do we get the nupkg to nuget.org? This is the final step
>>> >> that
>>> >> >> most
>>> >> >> >>>>>> users are going to be interested in.
>>> >> >> >>>>>>
>>> >> >> >>>>>> Having a look at what's at the url you posted, I have ideas on
>>> >> how
>>> >> >> to
>>> >> >> >>>>>> streamline future releases, so the next time I'm in that area,
>>> >> I'm
>>> >> >> >>>>>> definitely implementing those ideas. I don't see changes to
>>> the
>>> >> >> Release
>>> >> >> >>>>>> Notes area -- if I were to try to streamline that into a
>>> release,
>>> >> >> would a
>>> >> >> >>>>>> CHANGELOG file be useful? Or is there a better way?
>>> >> >> >>>>>>
>>> >> >> >>>>>> -d
>>> >> &

Re: Literals in Velocity Templates

[Apache]

Don’t convert whole files. You only need to convert where there is an existing 
document that is xdoc that needs to be updated.

Ralph

> On Aug 19, 2020, at 11:53 PM, Volkan Yazıcı  wrote:
> 
> Hello,
> 
> I have started cherry-picking JsonTemplateLayout from master into
> release-2.x. There I was welcomed by a big surprise: documentation infra
> between master (AsciiDoc) and release-2.x (Xdoc, Markdown, Velocity) are
> totally different. Right now I am busy with (manually?) converting
> thousands of lines of AsciiDoc to Xdoc. Though I could not make Velocity
> Template literals work. Given the following input
> 
> 200 #[[{
> 201 "mdc": "${json:mdcfoo}",
> ...
> 218 }]]#
> 
> "./mvnw site -DskipTests" produces the following error:
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pdf-plugin:1.2:pdf (pdf) on project log4j:
> Error during document generation: Error whenn parsing Velocity file
> /home/vy/Projects/log4j2/target/pdf/site.tmp/xdoc/manual/layouts.xml.vm:
> Encountered ":mdcfoo}\",\n  \"exception\": {\n\"exception_class\": \""
> at line 201, column 17 of
> /home/vy/Projects/log4j2/target/pdf/site.tmp/xdoc/manual/layouts.xml.vm
> [ERROR] Was expecting one of:
> [ERROR] "}" ...
> [ERROR]  ...
> 
> Any ideas on how to fix it? (I prefer to avoid replacing every occurence of
> a $ with ${dollar}, for obvious reasons.)
> 
> Kind regards.

Build failed in Jenkins: logging-log4net » PR-54 #5

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-54/5/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3 rather than 
80088d26a12b253e26530374fabc3a3429e869a3
Obtained Jenkinsfile from b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-1 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
 > git merge b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3 # timeout=10
Merge succeeded, producing a631f0cabc7465f52143fd4a3202148bc75579b7
Checking out Revision a631f0cabc7465f52143fd4a3202148bc75579b7 (PR-54)
Commit message: "Merge commit 'b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3' into 
HEAD"
First time build. Skipping changelog.
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f a631f0cabc7465f52143fd4a3202148bc75579b7
 > git rev-list --no-walk 9fab96197398da75a48ac44c575791a530a880a0 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
 > git merge b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3 # timeout=10
Merge succeeded, producing a7584d7ed4f75b588571a72273c98e634e49e7a7
Checking out Revision a7584d7ed4f75b588571a72273c98e634e49e7a7 (PR-54)
Commit message: "Merge commit 'b08dbcc6f715cc1bbd2989a7793d56b60f45c0b3' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f a7584d7ed4f75b588571a72273c98e634e49e7a7
 > git rev-list --no-walk 9fab96197398da75a48ac44c575791a530a880

Re: Testing Json Template Layout

[Apache]

Yes, please do.

Ralph

> On Jul 22, 2020, at 6:22 AM, Volkan Yazıcı  wrote:
> 
> Ralph, I am fine with the current state of the plugin. I don't intend to
> have further improvements in the short-term regarding KeyValuePair
> enhancements and/or escape character handling. If you are okay with it, I
> want to start rebasing this onto 2.x branch.
> 
>> On Mon, Jul 6, 2020 at 8:01 AM Ralph Goers 
>> wrote:
>> 
>> I finally got some time to start testing JsonTemplateLayout against the
>> logging in the cloud documentation. The first problem I ran into is that
>> additional fields don’t work. I don’t see any configurations that have them
>> and the Builder doesn’t have annotations on the key and value fields so I
>> suspect it just doesn’t work.  Why didn’t you just enhance KeyValuePair to
>> add the type attribute?
>> 
>> After I corrected the EventTemplateAdditionalField plugin I still can’t
>> get stack traces the way I want them. I thought you said you added the
>> ability to format the message using a pattern, but I don’t see that in the
>> documentation or in MessageResolver. Was that not included? As I said, I
>> require the stack trace to print in the message field in Kibana, not just
>> be a key in the additional data.
>> 
>> 
>> Ralph
>> 

Build failed in Jenkins: logging-log4net » PR-61 #1

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-61/1/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 rather than 
7eb91b44e73b61b02941b259d6bdef217522d0f7
Obtained Jenkinsfile from ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-61
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-61 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/61/head:refs/remotes/origin/PR-61 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/61/head:refs/remotes/origin/PR-61 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/61/head:refs/remotes/origin/PR-61 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 
into PR head commit 7eb91b44e73b61b02941b259d6bdef217522d0f7
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7eb91b44e73b61b02941b259d6bdef217522d0f7
Merge succeeded, producing 7eb91b44e73b61b02941b259d6bdef217522d0f7
Checking out Revision 7eb91b44e73b61b02941b259d6bdef217522d0f7 (PR-61)
 > git merge ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7eb91b44e73b61b02941b259d6bdef217522d0f7
Commit message: ":fire: remove circleci config: it won't be adopted and it 
fails now"
First time build. Skipping changelog.
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 
into PR head commit 7eb91b44e73b61b02941b259d6bdef217522d0f7
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/61/head:refs/remotes/origin/PR-61 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
Merge succeeded, producing 7eb91b44e73b61b02941b259d6bdef217522d0f7
Checking out Revision 7eb91b44e73b61b02941b259d6bdef217522d0f7 (PR-61)
Commit message: ":fire: remove circleci config: it won't be adopted and it 
fails now"
 > git checkout -f 7eb91b44e73b61b02941b259d6bdef217522d0f7
 > git merge ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7eb91b44e73b61b02941b259d6bdef217522d0f7
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] envVarsForTool

Build failed in Jenkins: logging-log4net » PR-54 #4

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-54/4/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 rather than 
80088d26a12b253e26530374fabc3a3429e869a3
Obtained Jenkinsfile from ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-4 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
 > git merge ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 # timeout=10
Merge succeeded, producing 9fab96197398da75a48ac44c575791a530a880a0
Checking out Revision 9fab96197398da75a48ac44c575791a530a880a0 (PR-54)
Commit message: "Merge commit 'ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4' into 
HEAD"
First time build. Skipping changelog.
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 9fab96197398da75a48ac44c575791a530a880a0
 > git rev-list --no-walk f64cdcbf587112e883d8951e5c60d5b4afc590ca # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
 > git merge ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4 # timeout=10
Merge succeeded, producing cfcb932577ae47b017059f1acdb665d781f54212
Checking out Revision cfcb932577ae47b017059f1acdb665d781f54212 (PR-54)
Commit message: "Merge commit 'ce1b9fbb7a2a9ab60e80f3060d1397e57f10e1c4' into 
HEAD"
First time build. Skipping changelog.
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f cfcb932577ae47b017059f1acdb665d781f54212
 > git rev-list --no-walk 

Build failed in Jenkins: logging-log4net » PR-24 #3

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-24/3/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
918aed62930cfcb44617f4c6a69aa40ac3034f33 rather than 
42ddcc6379c1e007bba5bb9395aa1432a0be5d35
Obtained Jenkinsfile from 918aed62930cfcb44617f4c6a69aa40ac3034f33
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-24
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-24 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
Merge succeeded, producing 5e4ef7380f7b4d57dec75979d8aa1e0b0f69e5d4
Checking out Revision 5e4ef7380f7b4d57dec75979d8aa1e0b0f69e5d4 (PR-24)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
First time build. Skipping changelog.
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 5e4ef7380f7b4d57dec75979d8aa1e0b0f69e5d4
 > git rev-list --no-walk eb93090f2c243b7a0cb9a225488378e85e29c0d7 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
Merge succeeded, producing ada1e26201ff4d20363001dee741fe08c0b590e3
Checking out Revision ada1e26201ff4d20363001dee741fe08c0b590e3 (PR-24)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
First time build. Skipping changelog.
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git c

Build failed in Jenkins: logging-log4net » PR-51 #8

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-51/8/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
918aed62930cfcb44617f4c6a69aa40ac3034f33 rather than 
806b756299fc33576c83799c156ffe2864943a64
Obtained Jenkinsfile from 918aed62930cfcb44617f4c6a69aa40ac3034f33
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-51
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-51 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 
 > +refs/heads/master:refs/remotes/origin/master
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
Fetching without tags
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 806b756299fc33576c83799c156ffe2864943a64
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 806b756299fc33576c83799c156ffe2864943a64
Merge succeeded, producing 1fbc6017c215969f2c0efb5bff3898f649eda16f
Checking out Revision 1fbc6017c215969f2c0efb5bff3898f649eda16f (PR-51)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 1fbc6017c215969f2c0efb5bff3898f649eda16f
 > git rev-list --no-walk c145545ec41e75c54e9c358c80afe92c102dc4cd # timeout=10
First time build. Skipping changelog.
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 806b756299fc33576c83799c156ffe2864943a64
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 806b756299fc33576c83799c156ffe2864943a64
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
Merge succeeded, producing a7f1e7895d5bf90cb7720dadb0a42751d3c9e219
Checking out Revision a7f1e7895d5bf90cb7720dadb0a42751d3c9e219 (PR-51)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
First time build. Skipping changelog.
 > git config core.sparsecheckout # timeout=10
 > git c

Build failed in Jenkins: logging-log4net » PR-43 #3

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-43/3/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
918aed62930cfcb44617f4c6a69aa40ac3034f33 rather than 
b4f9b36bfbea56d57c609e8fd1d715a2747780e9
Obtained Jenkinsfile from 918aed62930cfcb44617f4c6a69aa40ac3034f33
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-43
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/43/head:refs/remotes/origin/PR-43 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit b4f9b36bfbea56d57c609e8fd1d715a2747780e9
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b4f9b36bfbea56d57c609e8fd1d715a2747780e9
Merge succeeded, producing 62b9de2d5951b21f88e000d7a86743975ca175c0
Checking out Revision 62b9de2d5951b21f88e000d7a86743975ca175c0 (PR-43)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 62b9de2d5951b21f88e000d7a86743975ca175c0
 > git rev-list --no-walk 0c45ecbfa7638f4da08512675d12ad265e75fe21 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit b4f9b36bfbea56d57c609e8fd1d715a2747780e9
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/43/head:refs/remotes/origin/PR-43 
 > +refs/heads/master:refs/remotes/origin/master
Merge succeeded, producing 8c40847e30784c654610c96c64faf4308351173d
Checking out Revision 8c40847e30784c654610c96c64faf4308351173d (PR-43)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b4f9b36bfbea56d57c609e8fd1d715a2747780e9
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 8c40847e30784c654610c96c64faf4308351173d
 > git rev-list --no-walk 0c45ecbfa7638f4da08512675d12ad265e75fe21 # timeout=10
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] bat

f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-43>F:\jenkins\tools\nant\nant-0.92\bin\NAnt.exe
 -buildfile:log4net.build 
The system cannot find the path specified.
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Test on Windows)
Stage "Test on Windows" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build-Site)
Stage "Build-Site" skipped due to earlier failure(s)
[Pip

Build failed in Jenkins: logging-log4net » PR-56 #3

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-56/3/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
918aed62930cfcb44617f4c6a69aa40ac3034f33 rather than 
7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
Obtained Jenkinsfile from 918aed62930cfcb44617f4c6a69aa40ac3034f33
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-56
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/56/head:refs/remotes/origin/PR-56 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
Merge succeeded, producing ea72cee94ef84ca78ea294f8335d75b1d89f5aea
Checking out Revision ea72cee94ef84ca78ea294f8335d75b1d89f5aea (PR-56)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ea72cee94ef84ca78ea294f8335d75b1d89f5aea
 > git rev-list --no-walk 5e9e637646ea5795be60fcc7146929a9da5b5571 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/56/head:refs/remotes/origin/PR-56 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
Merge succeeded, producing 286802ae30ec460f0f8bb9ab20c3a5804cd62d71
Checking out Revision 286802ae30ec460f0f8bb9ab20c3a5804cd62d71 (PR-56)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 286802ae30ec460f0f8bb9ab20c3a5804cd62d71
 > git rev-list --no-walk 5e9e637646ea5795be60fcc7146929a9da5b5571 # timeout=10
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] bat

f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-56>F:\jenkins\tools\nant\nant-0.92\bin\NAnt.exe
 -buildfile:log4net.build 
The system cannot find the path specified.
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Test on Windows)
Stage "Test on Windows" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build-Site)
Stage "Build-Site" skipped due to earlier failure(s)
[Pip

Build failed in Jenkins: logging-log4net » PR-53 #3

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-53/3/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
918aed62930cfcb44617f4c6a69aa40ac3034f33 rather than 
db67b317320029d280a04e8f54a23bc72ca04050
Obtained Jenkinsfile from 918aed62930cfcb44617f4c6a69aa40ac3034f33
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-53
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/53/head:refs/remotes/origin/PR-53 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit db67b317320029d280a04e8f54a23bc72ca04050
 > git config core.sparsecheckout # timeout=10
 > git checkout -f db67b317320029d280a04e8f54a23bc72ca04050
Merge succeeded, producing 783c6423e276407c25e07f8c0d025c79c62def64
Checking out Revision 783c6423e276407c25e07f8c0d025c79c62def64 (PR-53)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 783c6423e276407c25e07f8c0d025c79c62def64
 > git rev-list --no-walk 63ebb914827b966e498af9c44b4ef8c9948aa428 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/53/head:refs/remotes/origin/PR-53 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit db67b317320029d280a04e8f54a23bc72ca04050
Merge succeeded, producing 484b8653f82a03bcdd164ef0990ebd4577cd6021
Checking out Revision 484b8653f82a03bcdd164ef0990ebd4577cd6021 (PR-53)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f db67b317320029d280a04e8f54a23bc72ca04050
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 484b8653f82a03bcdd164ef0990ebd4577cd6021
 > git rev-list --no-walk 63ebb914827b966e498af9c44b4ef8c9948aa428 # timeout=10
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] bat

f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-53>F:\jenkins\tools\nant\nant-0.92\bin\NAnt.exe
 -buildfile:log4net.build 
The system cannot find the path specified.
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Test on Windows)
Stage "Test on Windows" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build-Site)
Stage "Build-Site" skipped due to earlier failure(s)
[Pip

Build failed in Jenkins: logging-log4net » PR-59 #3

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-59/3/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
918aed62930cfcb44617f4c6a69aa40ac3034f33 rather than 
3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
Obtained Jenkinsfile from 918aed62930cfcb44617f4c6a69aa40ac3034f33
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-59
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-59 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
Merge succeeded, producing 9a30a80ff016c422101600fac0695e6ec45de7b7
Checking out Revision 9a30a80ff016c422101600fac0695e6ec45de7b7 (PR-59)
 > git checkout -f 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 9a30a80ff016c422101600fac0695e6ec45de7b7
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git rev-list --no-walk 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
Merge succeeded, producing 07a2132e0fd8ac94b04492c2cb8b980a68cca078
Checking out Revision 07a2132e0fd8ac94b04492c2cb8b980a68cca078 (PR-59)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 07a2132e0fd8ac94b04492c2cb8b980a68cca078
 > git rev-list --no-walk 

Build failed in Jenkins: logging-log4net » PR-54 #3

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-54/3/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
918aed62930cfcb44617f4c6a69aa40ac3034f33 rather than 
80088d26a12b253e26530374fabc3a3429e869a3
Obtained Jenkinsfile from 918aed62930cfcb44617f4c6a69aa40ac3034f33
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
Merge succeeded, producing f64cdcbf587112e883d8951e5c60d5b4afc590ca
Checking out Revision f64cdcbf587112e883d8951e5c60d5b4afc590ca (PR-54)
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f64cdcbf587112e883d8951e5c60d5b4afc590ca
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
First time build. Skipping changelog.
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
 > git rev-list --no-walk 2f460b7ad0b313fd19a06650fa84e5426ece3724 # timeout=10
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 918aed62930cfcb44617f4c6a69aa40ac3034f33 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
Merge succeeded, producing 0cceb82ad5dd959577f16c437f59eb8581d51bba
Checking out Revision 0cceb82ad5dd959577f16c437f59eb8581d51bba (PR-54)
Commit message: "Merge commit '918aed62930cfcb44617f4c6a69aa40ac3034f33' into 
HEAD"
First time build. Skipping changelog.
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
 > git merge 918aed62930cfcb44617f4c6a69aa40ac3034f33 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git c

Build failed in Jenkins: logging-log4net » PR-60 #1

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-60/1/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-1 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-60
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-60 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/60/head:refs/remotes/origin/PR-60 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/60/head:refs/remotes/origin/PR-60 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/60/head:refs/remotes/origin/PR-60 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
Merge succeeded, producing f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
Checking out Revision f3fc67044cfe1bc9f74c717df3f6f1a9b941b685 (PR-60)
Commit message: "fix typo"
First time build. Skipping changelog.
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/60/head:refs/remotes/origin/PR-60 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
Merge succeeded, producing f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
Checking out Revision f3fc67044cfe1bc9f74c717df3f6f1a9b941b685 (PR-60)
Commit message: "fix typo"
[Pipeline] }
[Pipeline] // withEnv
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f3fc67044cfe1bc9f74c717df3f6f1a9b941b685
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] bat

f:\jenkins\jenkins-slave\worksp

Re: Json Template Layout

[Apache]

Feel free to merge it. I will test it there when I can.

Ralph


> On May 22, 2020, at 4:50 AM, Volkan Yazıcı  wrote:
> 
> Hey Ralph,
> 
> Here is my status update:
> 
> -~- Benchmarks -~-
> 
> I have removed the benchmarks results. It takes ~8h for a complete run
> and I don't want to repeat that cycle after every change. I might
> revisit this idea once JTL becomes more stable in terms of its
> features.
> 
> -~- Flattening of MDC fields -~-
> 
> I have changed the MDC directive as follows:
> 
>mdc
>mdc:flatten[=][,stringify]
>mdc:pattern=[,flatten=][,stringify]
>mdc:key=[,stringify]
> 
> This also allowed JsonTemplateLayout to produce the *exact* output as
> GelfLayout and EcsLayout, where MDC keys are flattened and values are
> stringified.
> 
> -~- Null termination, newlines, Logstash, and etc. -~-
> 
> I have tried to reproduce the experiment you have shared, though could
> not really succeed due to some Docker command failure in restartApp.sh.
> Further, I find the associated Spring setup quite cumbersome to wrap my
> mind around it. That said, I have done something else: I have improved
> LogstashIT such that
> 
> 1. Logstash is configured with both "tcp" and "gelf" input plugins,
> 
> 2. LogstashIT employs JsonTemplateLayout against both inputs, repeats
>   the same using GelfLayout and EcsLayout, and verifies the populated
>   content in Elasticsearch.
> 
> One can easily validate this on the branch as follows:
> 
>$ ./mvnw clean package -DskipTests
>$ ./mvnw \
>verify -o -P docker \
>-pl 
> log4j-layout-jackson-json,log4j-plugins,log4j-core,log4j-api,log4j-layout-json-template
> \
>-Dtest="Dummy.java" -DtrimStackTrace=false -DfailIfNoTests=false
> 
> One can repeat the very same by running LogstashIT in IDE after
> starting the containers:
> 
>$ ./mvnw \
>docker:start -o -P docker \
>-pl 
> log4j-layout-jackson-json,log4j-plugins,log4j-core,log4j-api,log4j-layout-json-template
> 
> I don't know what is wrong with the Spring Cloud Config setup you have
> shared, but I have no reasons to believe that JsonTemplateLayout is the
> suspect.
> 
> Regarding your remark about everything getting escaped... This might
> happen when Logstash fails to read an input. In such a case, it puts
> the entire payload into the "message" field (hence, the escaping) and
> stores it like that.
> 
> From now on, I don't know how to proceed with this problem, in
> particular, given I believe the problem is in somewhere else but
> JsonTemplateLayout.
> 
> -~- Merging branch to master -~-
> 
> Unless there are objections, I want to merge the branch to master.
> There on I will share json-template-layout.md with the community to
> collect some feedback on the API. In particular, I have existing users
> of LogstashLayout in mind.
> 
> Kind regards.
> 
>> On Mon, May 18, 2020 at 1:18 AM Ralph Goers  
>> wrote:
>> 
>> 
>> 
 On May 17, 2020, at 2:37 PM, Volkan Yazıcı  wrote:
>>> 
>>> Thanks so much for the thorough review Ralph, really appreciated! I
>>> will address issues you have raised.
>>> 
>>> [As a side note, I have pushed changes containing performance
>>> improvements and benchmark results. The module is still dependency
>>> free and performance-wise pretty good.]
>>> 
 all the default templates separate the message from the exception
>>> 
>>> Yes, this I have also realized while studying the source code of
>>> GelfLayout. Some random thoughts:
>>> 
>>> 1. How about introducing a firstNonNull-like operator:
>>>  ${json:op:firstNonNull:${json:message},${json:exception:message}}.
>>>  Parsing this would not be trivial, given the list of variables
>>>  can include comma in various forms. Though the rest should
>>>  be tractable. (Feels like JsonTemplateLayout directives will at
>>>  some point catch up the with ones in PatternLayout.)
>> 
>> The problem here is that I want newlines in the message. I’m not sure what 
>> firstNonNull means in the context of a message. The message itself won’t 
>> have nulls. The Gelf format dictates the null is at the end of the JSON 
>> string.
>> 
>>> 
>>> 2. How about introducing a fallback parameter to the "message"
>>>  directive: ${json:message:fallback=exception:message}.
>> 
>> Again, I don’t know what that means or how it solves my problem of wanting 
>> newlines in the message.
>> 
>>> 
>>> 3. May I challenge the request: Do one really need it? You store
>>>  individual values, i.e, message and exception, in individual fields.
>>>  When one is missing and the other is present, isn't it just a
>>>  presentation layer issue to display it properly?
>> 
>> Picture how a log event looks in a file with a “standard” PatternLayout. In 
>> Kibana by default you get 3 columns, the timestamp, a field I don’t care 
>> about and the message. I want the message to appear just as it would in a 
>> log file without the timestamp. Yes, I can click on each message and see its 
>> attributes, but that takes longer. And I 

Build failed in Jenkins: logging-log4net » PR-59 #2

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-59/2/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-1 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-59
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
Checking out Revision 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e (PR-59)
Commit message: ":memo: add more specifics about required .net"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git rev-list --no-walk 7643c18c1548ac5f08fcc90e4006f9ba8511616c # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
Merge succeeded, producing 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
Checking out Revision 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e (PR-59)
Commit message: ":memo: add more specifics about required .net"
 > git checkout -f 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3fe51311cac1932518bd4b79f1cf1b6c1b06f35e
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] bat

f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-59>F:\jenkins\tools\nant\nant-0.92\bin\NAnt.exe
 -buildfile:log4net.build 
The system cannot find the path specified.
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Test on Windows)
Stage "Test on Windows" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build-Site)
Stage "Build-Site" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Deploy-Site)
Stage "Deploy-Site" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Declarative: Post Actions)
[Pipeline] step

Build failed in Jenkins: logging-log4net » PR-59 #1

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-59/1/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
7643c18c1548ac5f08fcc90e4006f9ba8511616c
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-1 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-59
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-59 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 7643c18c1548ac5f08fcc90e4006f9ba8511616c
Merge succeeded, producing 7643c18c1548ac5f08fcc90e4006f9ba8511616c
Checking out Revision 7643c18c1548ac5f08fcc90e4006f9ba8511616c (PR-59)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7643c18c1548ac5f08fcc90e4006f9ba8511616c
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7643c18c1548ac5f08fcc90e4006f9ba8511616c
Commit message: ":package: generate build artifact: zip of all released 
binaries"
First time build. Skipping changelog.
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 7643c18c1548ac5f08fcc90e4006f9ba8511616c
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/59/head:refs/remotes/origin/PR-59 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
Merge succeeded, producing 7643c18c1548ac5f08fcc90e4006f9ba8511616c
Checking out Revision 7643c18c1548ac5f08fcc90e4006f9ba8511616c (PR-59)
Commit message: ":package: generate build artifact: zip of all released 
binaries"
 > git checkout -f 7643c18c1548ac5f08fcc90e4006f9ba8511616c
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7643c18c1548ac5f08fcc90e4006f9ba8511616c
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline]

Re: log4net: resurrection

[Apache]

What you are seeing is exactly what I have been saying. The major problem is 
that none of the existing logging services committers know how to perform a 
release. We know there have been fixes committed that are needed. We just don’t 
know how to make them available. That is exactly why I said your focus should 
be getting a release built.

Ralph

> On Apr 6, 2020, at 10:15 PM, Davyd McColl  wrote:
> 
> That sounds promising, and I'm aware that I'm probably being a little 
> annoying by now, but I've also noticed that the source package is version is 
> at 2.0.9 where the latest release package version is 2.0.8. That version was 
> bumped 3 years ago. In between the last release date and last commits are 
> commits including at least 2 PR merges (42 and 23 ), both of which seen 
> significant.
> 
> I guess what I'm asking is what's holding up the 2.0.9 release? If I'm to 
> fork, PR and even if that PR is accepted, how do I avoid the fate of 2.0.9?
> 
> Or is that something I can assist with right now?
> 
> Please understand where I'm coming from: I'd really like to keep log4net 
> alive, but, like anyone, I have limited time resources, so I'd prefer to 
> spend that time on tasks with some reasonable probability of success.
> 
> Thanks
> -d
> 
> 
>> On April 6, 2020 23:00:36 Ralph Goers  wrote:
>> 
>> No. What I am implying is that you would begin the work necessary to perform 
>> a release on a fork. When you are ready you would submit a PR and one or 
>> more of the existing PMC members would review that and merge it. You would 
>> then collaborate with us to get the release published.
>> 
>> There is a big difference between us reviewing PRs and merging them for 
>> stuff we know little about vs us providing the karma you will need to 
>> formally get a release done.
>> 
>> Ralph
>> 
>>>> On Apr 6, 2020, at 12:57 PM, Davyd McColl  wrote:
>>> Unfortunately, this would suggest that forking and publishing under a 
>>> different package name is probably the best idea. There are, as noted 
>>> before, 34 stagnated pull requests currently at GitHub, many of which 
>>> haven't seen any attention since 2018. It would seem to be a fool's errand 
>>> to open a 35th I'm hopes that it would be the one to get attention.
>>> If I'm wrong (and I'd love to be) please correct me.
>>> -d
>>> On April 6, 2020 15:59:26 Apache  wrote:
>>>> The only requirement to become an experienced open source developer is 
>>>> passion. Open source developers are just people who like to work on code 
>>>> that everyone can use. That’s it. If you have the time, can help with the 
>>>> technical problems needed to get the project moving, and can collaborate 
>>>> with others you have everything you need.
>>>> Yes, the code base is still at Github and nothing has been done that can’t 
>>>> be undone. But for the PMC to move the project out of dormant status you 
>>>> would first need to demonstrate progress, which might mean collaborating 
>>>> on a private fork until you are ready to merge it.
>>>> Ralph
>>>>> On Apr 6, 2020, at 1:10 AM, Tim Sargent  wrote:
>>>>> I remember reading the call for .NET devs (a few years back) to help with
>>>>> the .NET core version for Log4Net.   That's about the time I joined the
>>>>> mailing list.
>>>>> As I understand it, dormant just means it's no longer being maintained, 
>>>>> but
>>>>> the current version is still available for download and use via NuGet.
>>>>> I've toyed with the idea of getting involved in an open source project,
>>>>> which is why I originally joined the list.  Unfortunately, I don't think I
>>>>> have the background in open source projects to be an effective 
>>>>> contributor,
>>>>> let alone sponsor.   I'm very experienced in .NET (having been doing it
>>>>> since it was in its final preview for 1.0), and I have experience with 
>>>>> unit
>>>>> tests, automated builds and release pipelines (though it's all MS based 
>>>>> via
>>>>> TFS and MSTest).
>>>>> Having said that, it sounds like Mr McColl has a strong interest in 
>>>>> keeping
>>>>> it alive, and I'd be happy to offer assistance in any way he finds
>>>>> beneficial.
>>>>> Thanks.
>>>>>> On Mon, Apr 6, 2020 at 12:50 AM Apache  
>>>>>> wrote:
>>>>>> No one is ever happy moving a project to dorman

Re: log4net: resurrection

[Apache]

The only requirement to become an experienced open source developer is passion. 
Open source developers are just people who like to work on code that everyone 
can use. That’s it. If you have the time, can help with the technical problems 
needed to get the project moving, and can collaborate with others you have 
everything you need. 

Yes, the code base is still at Github and nothing has been done that can’t be 
undone. But for the PMC to move the project out of dormant status you would 
first need to demonstrate progress, which might mean collaborating on a private 
fork until you are ready to merge it.

Ralph

> On Apr 6, 2020, at 1:10 AM, Tim Sargent  wrote:
> 
> I remember reading the call for .NET devs (a few years back) to help with
> the .NET core version for Log4Net.   That's about the time I joined the
> mailing list.
> 
> As I understand it, dormant just means it's no longer being maintained, but
> the current version is still available for download and use via NuGet.
> I've toyed with the idea of getting involved in an open source project,
> which is why I originally joined the list.  Unfortunately, I don't think I
> have the background in open source projects to be an effective contributor,
> let alone sponsor.   I'm very experienced in .NET (having been doing it
> since it was in its final preview for 1.0), and I have experience with unit
> tests, automated builds and release pipelines (though it's all MS based via
> TFS and MSTest).
> 
> Having said that, it sounds like Mr McColl has a strong interest in keeping
> it alive, and I'd be happy to offer assistance in any way he finds
> beneficial.
> 
> Thanks.
> 
>> On Mon, Apr 6, 2020 at 12:50 AM Apache  wrote:
>> 
>> No one is ever happy moving a project to dormant status.  But it is unfair
>> to users to let them think the project is being maintained when the reality
>> is quite different than that.
>> 
>> The main issue that needs to be overcome is getting a release out. The ASF
>> has some requirements around releases that have to be met, but that isn’t
>> the hard part. Most users want convenience binaries and no one who is
>> active knows how to do that. There is a documented process in confluence
>> but I have no idea how accurate it is.
>> 
>> Once a release is able to be cut getting assistance from others would
>> probably be easier.
>> 
>> Also, the ASF infra team really doesn’t care about the status of the
>> project and is not a driving force in this.
>> 
>> To be honest, log4cxx was in a similar position. But that project has had
>> a couple of people come forward and are working towards a release. We hope
>> they succeed.
>> 
>> Ralph
>> 
>>>> On Apr 5, 2020, at 11:56 PM, Davyd McColl  wrote:
>>> 
>>> Hi all
>>> 
>>> I'm new to this list, been using log4net for around 9 years, and only
>> this
>>> week discovered that it is being made dormant (and what that means).
>>> 
>>> I've been told that the team has been looking for outside help for
>> around 2
>>> years, with no-one forthcoming. Unfortunately, as I say, this is the
>> first
>>> I've heard of it. I'd like to keep log4net alive because it's used
>>> ubiquitously and I think it's a valuable project.
>>> 
>>> I publish my own nuget packages (https://www.nuget.org/profiles/davydm)
>>> though obviously, not with the same methodologies of the existing log4net
>>> infrastructure. I see that there's a 2.0.9 release that could potentially
>>> happen (as per the source), whilst 2.0.8 is still the current release, so
>>> I'm assuming there's something holding that up. I also see 34 pull
>> requests
>>> on GitHub which are in different states of activity, but many have been
>>> dormant since 2018.
>>> 
>>> I'd like to help, but I'm not sure where to start with the log4net infra
>> (I
>>> hear there's Jira (I've had little experience) and Jenkins (I've had
>>> reasonable experience, but not with pipelines)). I'm not even sure what
>> the
>>> state of play is for that infra. I'm sure there are good reasons for
>> making
>>> the project dormant -- some of those may include the desire to free up
>>> infra which could be used elsewhere (or just not paid for).
>>> 
>>> As I say, I'd like to keep log4net alive. I see a few options here:
>>> 
>>> 1. I learn your infra and your processes. I integrate and try to keep
>>> things pretty-much as they were (though I'm sure some things would have
>> to
>>> change -- all things do). I don't mind spending th

Re: log4net: resurrection

[Apache]

No one is ever happy moving a project to dormant status.  But it is unfair to 
users to let them think the project is being maintained when the reality is 
quite different than that. 

The main issue that needs to be overcome is getting a release out. The ASF has 
some requirements around releases that have to be met, but that isn’t the hard 
part. Most users want convenience binaries and no one who is active knows how 
to do that. There is a documented process in confluence but I have no idea how 
accurate it is. 

Once a release is able to be cut getting assistance from others would probably 
be easier. 

Also, the ASF infra team really doesn’t care about the status of the project 
and is not a driving force in this. 

To be honest, log4cxx was in a similar position. But that project has had a 
couple of people come forward and are working towards a release. We hope they 
succeed.

Ralph

> On Apr 5, 2020, at 11:56 PM, Davyd McColl  wrote:
> 
> Hi all
> 
> I'm new to this list, been using log4net for around 9 years, and only this
> week discovered that it is being made dormant (and what that means).
> 
> I've been told that the team has been looking for outside help for around 2
> years, with no-one forthcoming. Unfortunately, as I say, this is the first
> I've heard of it. I'd like to keep log4net alive because it's used
> ubiquitously and I think it's a valuable project.
> 
> I publish my own nuget packages (https://www.nuget.org/profiles/davydm)
> though obviously, not with the same methodologies of the existing log4net
> infrastructure. I see that there's a 2.0.9 release that could potentially
> happen (as per the source), whilst 2.0.8 is still the current release, so
> I'm assuming there's something holding that up. I also see 34 pull requests
> on GitHub which are in different states of activity, but many have been
> dormant since 2018.
> 
> I'd like to help, but I'm not sure where to start with the log4net infra (I
> hear there's Jira (I've had little experience) and Jenkins (I've had
> reasonable experience, but not with pipelines)). I'm not even sure what the
> state of play is for that infra. I'm sure there are good reasons for making
> the project dormant -- some of those may include the desire to free up
> infra which could be used elsewhere (or just not paid for).
> 
> As I say, I'd like to keep log4net alive. I see a few options here:
> 
> 1. I learn your infra and your processes. I integrate and try to keep
> things pretty-much as they were (though I'm sure some things would have to
> change -- all things do). I don't mind spending the time learning the
> domain, if that's agreeable to everyone and the project retains it's
> original branding and status. One thing I'm concerned about here is the
> dormant backlog
> 2. As above, with a bit of a clean-slate philosophy: I'd like to remove all
> backlog items that aren't critical and start with the least outstanding
> stuff possible. If a report is important, it will be reported again. Trying
> to trace down the authors and origins of 2+year-old reports is going to be
> frustrating. Issues which aren't attended to just become noise in the
> backlog, imo.
> 3. I fork and perform the "clean slate" approach of above, inviting others
> to use my variant and log issues there. Uptake will naturally be slow (if
> even noticeable), which will give me time to deal with incoming issues. On
> the other hand, I'd have full control and no need to bother anyone else. I
> would have to come up with a new name and make it clear that it's a fork,
> though also make it clear I'd be standing on the shoulders of giants.
> 
> Personally, I'd like (1) because it keeps the project that people rely on
> alive. Since I'm new to the mailing list, I can't discern yet the sentiment
> towards the project, except that everyone was quite happy to have it made
> dormant, so it feels like there's not a lot of desire to keep it going --
> which is ok: everything comes to an end at some point, and, as stated
> earlier, I'm sure there are good reasons for making log4net dormant. As a
> consumer of log4net, I'd much rather not have to switch over to another
> framework once there's an issue which affects me more than my logged one
> (inability to flush logs -- it was on a proof-of-concept project, so it
> isn't _that_ important to have the functionality right now).
> 
> Apologies for the rambling message. I was prompted to reach out by Ralph
> Goers in the discussion for LOG4NET-606, so I hope I haven't been a bother.
> 
> -d
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> If you say that getting the money is the most important thing
> You will spend your life completely wasting your time
> You will be doing things you don't like doing
> In order to go on living
> That is, to go on doing things you don't like doing
> 
> Which is stupid.
> 
> - Alan Watts
> https://www.youtube.com/watch?v=-gXTZM_uPMY
> 
> *Quidquid latine dictum sit, altum sonatur. *

Build failed in Jenkins: logging-log4net » PR-54 #2

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-54/2/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
80088d26a12b253e26530374fabc3a3429e869a3
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-4 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-54 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing 2f460b7ad0b313fd19a06650fa84e5426ece3724
Checking out Revision 2f460b7ad0b313fd19a06650fa84e5426ece3724 (PR-54)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 2f460b7ad0b313fd19a06650fa84e5426ece3724
 > git rev-list --no-walk 80088d26a12b253e26530374fabc3a3429e869a3 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/54/head:refs/remotes/origin/PR-54 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 80088d26a12b253e26530374fabc3a3429e869a3
Merge succeeded, producing 56fd09f2c29c395ffa1776be1c6f2050fc1b83a6
Checking out Revision 56fd09f2c29c395ffa1776be1c6f2050fc1b83a6 (PR-54)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 80088d26a12b253e26530374fabc3a3429e869a3
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 56fd09f2c29c395ffa1776be1c6f2050fc1b83a6
 > git rev-list --no-walk 80088d26a12b253e26530374fabc3a3429e869a3 # timeout=10
[Pipeline] }
[Pipeli

Build failed in Jenkins: logging-log4net » PR-43 #2

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-43/2/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
b4f9b36bfbea56d57c609e8fd1d715a2747780e9
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-43
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-43 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/43/head:refs/remotes/origin/PR-43 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/43/head:refs/remotes/origin/PR-43 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/43/head:refs/remotes/origin/PR-43 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit b4f9b36bfbea56d57c609e8fd1d715a2747780e9
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b4f9b36bfbea56d57c609e8fd1d715a2747780e9
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing 0c45ecbfa7638f4da08512675d12ad265e75fe21
Checking out Revision 0c45ecbfa7638f4da08512675d12ad265e75fe21 (PR-43)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 0c45ecbfa7638f4da08512675d12ad265e75fe21
 > git rev-list --no-walk b4f9b36bfbea56d57c609e8fd1d715a2747780e9 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit b4f9b36bfbea56d57c609e8fd1d715a2747780e9
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/43/head:refs/remotes/origin/PR-43 
 > +refs/heads/master:refs/remotes/origin/master
Merge succeeded, producing c51964993ef6c5a8b940f95a3b4b27a555df4deb
Checking out Revision c51964993ef6c5a8b940f95a3b4b27a555df4deb (PR-43)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b4f9b36bfbea56d57c609e8fd1d715a2747780e9
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f c51964993ef6c5a8b940f95a3b4b27a555df4deb
 > git rev-list --no-walk b4f9b36bfbea56d57c609e8fd1d715a2747780e9 # timeout=10
[Pipeline] }
[Pipeli

Build failed in Jenkins: logging-log4net » PR-53 #2

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-53/2/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
db67b317320029d280a04e8f54a23bc72ca04050
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-53
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-53 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/53/head:refs/remotes/origin/PR-53 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/53/head:refs/remotes/origin/PR-53 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/53/head:refs/remotes/origin/PR-53 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit db67b317320029d280a04e8f54a23bc72ca04050
 > git config core.sparsecheckout # timeout=10
 > git checkout -f db67b317320029d280a04e8f54a23bc72ca04050
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing 63ebb914827b966e498af9c44b4ef8c9948aa428
Checking out Revision 63ebb914827b966e498af9c44b4ef8c9948aa428 (PR-53)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 63ebb914827b966e498af9c44b4ef8c9948aa428
 > git rev-list --no-walk db67b317320029d280a04e8f54a23bc72ca04050 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/53/head:refs/remotes/origin/PR-53 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit db67b317320029d280a04e8f54a23bc72ca04050
Merge succeeded, producing ad4f6d0cd4fc9523a0814db13efc8b8ea76f97e7
Checking out Revision ad4f6d0cd4fc9523a0814db13efc8b8ea76f97e7 (PR-53)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f db67b317320029d280a04e8f54a23bc72ca04050
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ad4f6d0cd4fc9523a0814db13efc8b8ea76f97e7
 > git rev-list --no-walk db67b317320029d280a04e8f54a23bc72ca04050 # timeout=10
[Pipeline] }
[Pipeli

Build failed in Jenkins: logging-log4net » PR-51 #7

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-51/7/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
806b756299fc33576c83799c156ffe2864943a64
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-5 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-51
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-51 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 806b756299fc33576c83799c156ffe2864943a64
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 806b756299fc33576c83799c156ffe2864943a64
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing c145545ec41e75c54e9c358c80afe92c102dc4cd
Checking out Revision c145545ec41e75c54e9c358c80afe92c102dc4cd (PR-51)
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f c145545ec41e75c54e9c358c80afe92c102dc4cd
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-list --no-walk 806b756299fc33576c83799c156ffe2864943a64 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/51/head:refs/remotes/origin/PR-51 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 806b756299fc33576c83799c156ffe2864943a64
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 806b756299fc33576c83799c156ffe2864943a64
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing 1934b4276871ca885dfad78f405f49659a8ac5a3
Checking out Revision 1934b4276871ca885dfad78f405f49659a8ac5a3 (PR-51)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 1934b4276871ca885dfad78f405f49659a8ac5a3
 > git rev-list --no-walk 806b756299fc33576c83799c156ffe2864943a64 # timeout=10
[Pipeline] }
[Pipeli

Build failed in Jenkins: logging-log4net » PR-24 #2

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-24/2/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
42ddcc6379c1e007bba5bb9395aa1432a0be5d35
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-6 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-24
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-24 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing eb93090f2c243b7a0cb9a225488378e85e29c0d7
Checking out Revision eb93090f2c243b7a0cb9a225488378e85e29c0d7 (PR-24)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f eb93090f2c243b7a0cb9a225488378e85e29c0d7
 > git rev-list --no-walk 42ddcc6379c1e007bba5bb9395aa1432a0be5d35 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/24/head:refs/remotes/origin/PR-24 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
Merge succeeded, producing 73f15a9b43f422f3773b8c51031a88fe05466140
Checking out Revision 73f15a9b43f422f3773b8c51031a88fe05466140 (PR-24)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git checkout -f 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 73f15a9b43f422f3773b8c51031a88fe05466140
 > git rev-list --no-walk 42ddcc6379c1e007bba5bb9395aa1432a0be5d35 # timeout=10
[Pipeline] }
[Pipeli

Build failed in Jenkins: logging-log4net » PR-56 #2

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-56/2/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-3 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-56
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-56 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/56/head:refs/remotes/origin/PR-56 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/56/head:refs/remotes/origin/PR-56 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/56/head:refs/remotes/origin/PR-56 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing 5e9e637646ea5795be60fcc7146929a9da5b5571
Checking out Revision 5e9e637646ea5795be60fcc7146929a9da5b5571 (PR-56)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 5e9e637646ea5795be60fcc7146929a9da5b5571
 > git rev-list --no-walk 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58 # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/56/head:refs/remotes/origin/PR-56 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
Merge succeeded, producing 4d5785d45151278840986e23480dad3bd6b572b8
Checking out Revision 4d5785d45151278840986e23480dad3bd6b572b8 (PR-56)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 4d5785d45151278840986e23480dad3bd6b572b8
 > git rev-list --no-walk 7c1d45c16fe43c52a2030aafb8ae046ea0b78f58 # timeout=10
[Pipeline] }
[Pipeli

Build failed in Jenkins: logging-log4net » PR-57 #2

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-57/2/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 rather than 
749ce7871f1bb3a8eef9a4663cddd4159553bbcd
Obtained Jenkinsfile from 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on jenkins-win-he-de-6 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-57
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-57 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 
 > +refs/heads/master:refs/remotes/origin/master
Fetching without tags
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 # timeout=10
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
Merge succeeded, producing f825ccba664aa8aecedcec6aa38e5b2a5bc8aba2
Checking out Revision f825ccba664aa8aecedcec6aa38e5b2a5bc8aba2 (PR-57)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f825ccba664aa8aecedcec6aa38e5b2a5bc8aba2
 > git rev-list --no-walk 749ce7871f1bb3a8eef9a4663cddd4159553bbcd # timeout=10
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
Merging remotes/origin/master commit 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 
into PR head commit 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
 > git merge 644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8 # timeout=10
Merge succeeded, producing 1a8461f19eafa782ac1da8d7f46f72c59348702c
Checking out Revision 1a8461f19eafa782ac1da8d7f46f72c59348702c (PR-57)
Commit message: "Merge commit '644cfa1ba879fb41fac8e92b22c3dc7e84ed0ab8' into 
HEAD"
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 1a8461f19eafa782ac1da8d7f46f72c59348702c
 > git rev-list --no-walk 749ce7871f1bb3a8eef9a4663cddd4159553bbcd # timeout=10
[Pipeline] }
[Pipeli

Build failed in Jenkins: logging-log4net » PR-57 #1

[Apache Jenkins Server]

See <https://builds.apache.org/job/logging-log4net/job/PR-57/1/display/redirect>

Changes:


--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at github)
Loading trusted files from base branch master at 
c04a774240fd4500ed3206124aba5b4bc8bc4933 rather than 
749ce7871f1bb3a8eef9a4663cddd4159553bbcd
Obtained Jenkinsfile from c04a774240fd4500ed3206124aba5b4bc8bc4933
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Still waiting to schedule task
Waiting for next available executor on ‘Windows’
Running on jenkins-win-he-de-1 in 
f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-57
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
 > git init f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-57 # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 
 > +refs/heads/master:refs/remotes/origin/master
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
 > git config --add remote.origin.fetch 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 # timeout=10
Fetching without tags
Merging remotes/origin/master commit c04a774240fd4500ed3206124aba5b4bc8bc4933 
into PR head commit 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
 > git config --add remote.origin.fetch 
 > +refs/heads/master:refs/remotes/origin/master # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 
 > +refs/heads/master:refs/remotes/origin/master
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
Merge succeeded, producing 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
Checking out Revision 749ce7871f1bb3a8eef9a4663cddd4159553bbcd (PR-57)
Commit message: "Fix link to FileAppender Class docs"
First time build. Skipping changelog.
 > git merge c04a774240fd4500ed3206124aba5b4bc8bc4933 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout
using credential github-logging-log4net-dpsenner
Fetching changes from the remote Git repository
Fetching without tags
 > git rev-parse --is-inside-work-tree # timeout=10
 > git config remote.origin.url https://github.com/apache/logging-log4net.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/logging-log4net.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
 > git fetch --no-tags --progress -- 
 > https://github.com/apache/logging-log4net.git 
 > +refs/pull/57/head:refs/remotes/origin/PR-57 
 > +refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit c04a774240fd4500ed3206124aba5b4bc8bc4933 
into PR head commit 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
Merge succeeded, producing 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
Checking out Revision 749ce7871f1bb3a8eef9a4663cddd4159553bbcd (PR-57)
Commit message: "Fix link to FileAppender Class docs"
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
 > git merge c04a774240fd4500ed3206124aba5b4bc8bc4933 # timeout=10
 > git rev-parse "HEAD^{commit}" # timeout=10
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 749ce7871f1bb3a8eef9a4663cddd4159553bbcd
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] tool
[Pipeline] 

Re: TimeFilterTest

[Apache]

I started testing this. It doesn’t handle daylight savings at all and some of 
the tests make no sense. I’m rewriting it using java.time and implementing 
better tests.

Ralph

> On Mar 8, 2020, at 11:19 AM, Ralph Goers  wrote:
> 
> Is anyone else having problems with TimeFilterTest in core today?  I am in 
> Arizona so we did not spring forward as we are MST all year.  I see the test 
> is setting a timezone of America/Los Angeles.
> 
> Ralph

Re: Modularization

[Apache]

Rats. Substitute “no plans” with “only plans”.

Ralph

> On Mar 8, 2020, at 6:31 AM, Apache  wrote:
> 
> I have no plans to do this in master. One of the main goals of 3.0 is to be 
> fully modularized. This is just one part of that.
> 
> Ralph
> 
>> On Mar 8, 2020, at 5:26 AM, Gary Gregory  wrote:
>> 
>> Is this worthy doing in 2.0? In 3 we can do whatever we want IMO.
>> 
>> Gary
>> 
>>>> On Sat, Mar 7, 2020, 23:24 Ralph Goers  wrote:
>>> 
>>> I started looking at log4j-core in master today with an eye towards
>>> creating the module-info.java file. As I went through it I realized we
>>> would have to expose almost all of the packages because we have co-mingled
>>> private implementations along with public interfaces and abstract class. We
>>> really can’t move the public classes as user’s are currently referencing
>>> them so I am proposing that we move the private classes. I already started
>>> that with LogBuilder by creating a directory named “internal” off of core.
>>> Rather than having internal directories all over the place I am thinking we
>>> should mimic the same existing package structure under the internal
>>> directory and move private classes there.
>>> 
>>> Thoughts?
>>> 
>>> Ralph
>>> 

Re: Modularization

[Apache]

I have no plans to do this in master. One of the main goals of 3.0 is to be 
fully modularized. This is just one part of that.

Ralph

> On Mar 8, 2020, at 5:26 AM, Gary Gregory  wrote:
> 
> Is this worthy doing in 2.0? In 3 we can do whatever we want IMO.
> 
> Gary
> 
>> On Sat, Mar 7, 2020, 23:24 Ralph Goers  wrote:
>> 
>> I started looking at log4j-core in master today with an eye towards
>> creating the module-info.java file. As I went through it I realized we
>> would have to expose almost all of the packages because we have co-mingled
>> private implementations along with public interfaces and abstract class. We
>> really can’t move the public classes as user’s are currently referencing
>> them so I am proposing that we move the private classes. I already started
>> that with LogBuilder by creating a directory named “internal” off of core.
>> Rather than having internal directories all over the place I am thinking we
>> should mimic the same existing package structure under the internal
>> directory and move private classes there.
>> 
>> Thoughts?
>> 
>> Ralph
>>