@Log annotation

[Rob Tompkins]

Hey folks,

I’m curious if anyone has thought about adding a class level @Log annotation 
such that upon debug or trace configuration, method entry and exit gets 
automatically logged?

-Rob

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 9:29 AM, Gary Gregory  wrote:
> 
> Annotation-based logging comes up once in a while here but we have not
> implemented it. Project Lombok does that IIRC.

Any reason for having not yet implemented it, or just the standard “time”?

> 
> Gary
> 
> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
> 
>> Hey folks,
>> 
>> I’m curious if anyone has thought about adding a class level @Log
>> annotation such that upon debug or trace configuration, method entry and
>> exit gets automatically logged?
>> 
>> -Rob

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 10:17 AM, Gary Gregory  wrote:
> 
> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins  wrote:
> 
>> 
>> 
>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
>> wrote:
>>> 
>>> Annotation-based logging comes up once in a while here but we have not
>>> implemented it. Project Lombok does that IIRC.
>> 
>> Any reason for having not yet implemented it, or just the standard “time”?
>> 
> 
> It's just more "stuff" and yes, time. And also, no one's wanted to put the
> time in.
> 
> But then there are design issues and adding more "stuff" to the API jar.
> 
> - Would you allow @Log(level=Level.TRACE) (should be the default?) and
> @Log(level=Level.DEBUG)
> - What happens if you say both?
> - Should you be able to break it up and only say @LogEntry() or @LogExit().
> - What about @Log(file="${user.home}\foo.log")
> - and on and on ;-)

Definitely fair points, I think I would try to go as simple as possible in a 
first pass…right?

@Log
@Log(level=X)

-Rob

> 
> Gary
> 
> 
>> 
>>> 
>>> Gary
>>> 
>>> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
>>> 
>>>> Hey folks,
>>>> 
>>>> I’m curious if anyone has thought about adding a class level @Log
>>>> annotation such that upon debug or trace configuration, method entry and
>>>> exit gets automatically logged?
>>>> 
>>>> -Rob
>> 
>> 

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 11:48 AM, Gary Gregory  wrote:
> 
> FTR: https://projectlombok.org/features/log
> 
> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory  wrote:
> 
>> 
>> 
>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins  wrote:
>> 
>>> 
>>> 
>>>> On Jul 19, 2018, at 10:17 AM, Gary Gregory 
>>> wrote:
>>>> 
>>>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
>>>>> wrote:
>>>>>> 
>>>>>> Annotation-based logging comes up once in a while here but we have not
>>>>>> implemented it. Project Lombok does that IIRC.
>>>>> 
>>>>> Any reason for having not yet implemented it, or just the standard
>>> “time”?
>>>>> 
>>>> 
>>>> It's just more "stuff" and yes, time. And also, no one's wanted to put
>>> the
>>>> time in.
>>>> 
>>>> But then there are design issues and adding more "stuff" to the API jar.
>>>> 
>>>> - Would you allow @Log(level=Level.TRACE) (should be the default?) and
>>>> @Log(level=Level.DEBUG)
>>>> - What happens if you say both?
>>>> - Should you be able to break it up and only say @LogEntry() or
>>> @LogExit().
>>>> - What about @Log(file="${user.home}\foo.log")
>>>> - and on and on ;-)
>>> 
>>> Definitely fair points, I think I would try to go as simple as possible
>>> in a first pass…right?
>>> 
>>> @Log
>>> @Log(level=X)
>>> 
>> 
>> Well, yes. But we need to think about the scope of the annotation. The
>> name @Log is as broad as you can think of making the name. So if we want to
>> put more in there later, then we need to make sure that's the best name.
>> 
>> Do you think
>> 
>> @Log()
>> 
>> could be the default for (for example)
>> 
>> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
>> exitValue=true)
>> 
>> Where entryParameters (if on a method) would let me list which params for
>> that methods to log)
>> 
>> How do I avoid logging a password argument for example? Sounds like we can
>> do away with entryParameters if we have a @LogHide to annotate a
>> parameter.
>> 
>> I could see that as step one but we need to think about all that we would
>> want to do to make sure @Log is the right name. What's a name that says log
>> all entries and exits?  @LogEntryExit?
>> 
>> Overall I would think that this kind of annotated class would change that
>> class' byte codes after compilation so that there are no runtime
>> requirements even for annotations. I certainly would not want to leave
>> behind clues like @LogHide to would be attackers
>> 
>> Thoughts?

I think that @Log is the wrong name because it’s quite vague. Maybe 
@LogMethodCalls, or as you suggest @LogEntryExit.

I like the signature you suggested @Gary.

@Matt - As for mechanics, I would think we would want to do compile time byte 
code weaving. (Is there any appetite for using aspectJ? Feels like a large ask 
to add a dependency to log4j2 though.)

>> 
>> Gary
>> 
>> 
>>> -Rob
>>> 
>>>> 
>>>> Gary
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Thu, Jul 19, 2018, 07:15 Rob Tompkins  wrote:
>>>>>> 
>>>>>>> Hey folks,
>>>>>>> 
>>>>>>> I’m curious if anyone has thought about adding a class level @Log
>>>>>>> annotation such that upon debug or trace configuration, method entry
>>> and
>>>>>>> exit gets automatically logged?
>>>>>>> 
>>>>>>> -Rob
>>>>> 
>>>>> 
>>> 
>>> 

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 1:41 PM, Ralph Goers  wrote:
> 
> To be clear, Log4j-core should have no required dependencies other than 
> Log4j-API. And we would like to keep optional dependencies to a minimum.

Right that makes sense to me. Hence it being an after thought, and I like 
Gary’s suggestion of a compile time dependency for the sake of weaving.

> 
> Ralph
> 
>> On Jul 19, 2018, at 10:36 AM, Gary Gregory  wrote:
>> 
>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins > <mailto:chtom...@gmail.com>> wrote:
>> 
>>> 
>>> 
>>>> On Jul 19, 2018, at 11:48 AM, Gary Gregory 
>>> wrote:
>>>> 
>>>> FTR: https://projectlombok.org/features/log
>>>> 
>>>> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
>>> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jul 19, 2018, at 10:17 AM, Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Annotation-based logging comes up once in a while here but we have
>>> not
>>>>>>>>> implemented it. Project Lombok does that IIRC.
>>>>>>>> 
>>>>>>>> Any reason for having not yet implemented it, or just the standard
>>>>>> “time”?
>>>>>>>> 
>>>>>>> 
>>>>>>> It's just more "stuff" and yes, time. And also, no one's wanted to put
>>>>>> the
>>>>>>> time in.
>>>>>>> 
>>>>>>> But then there are design issues and adding more "stuff" to the API
>>> jar.
>>>>>>> 
>>>>>>> - Would you allow @Log(level=Level.TRACE) (should be the default?) and
>>>>>>> @Log(level=Level.DEBUG)
>>>>>>> - What happens if you say both?
>>>>>>> - Should you be able to break it up and only say @LogEntry() or
>>>>>> @LogExit().
>>>>>>> - What about @Log(file="${user.home}\foo.log")
>>>>>>> - and on and on ;-)
>>>>>> 
>>>>>> Definitely fair points, I think I would try to go as simple as possible
>>>>>> in a first pass…right?
>>>>>> 
>>>>>> @Log
>>>>>> @Log(level=X)
>>>>>> 
>>>>> 
>>>>> Well, yes. But we need to think about the scope of the annotation. The
>>>>> name @Log is as broad as you can think of making the name. So if we
>>> want to
>>>>> put more in there later, then we need to make sure that's the best name.
>>>>> 
>>>>> Do you think
>>>>> 
>>>>> @Log()
>>>>> 
>>>>> could be the default for (for example)
>>>>> 
>>>>> @Log(level=Level.TRACE, entry=true, entryParameters=ALL, exit=true,
>>>>> exitValue=true)
>>>>> 
>>>>> Where entryParameters (if on a method) would let me list which params
>>> for
>>>>> that methods to log)
>>>>> 
>>>>> How do I avoid logging a password argument for example? Sounds like we
>>> can
>>>>> do away with entryParameters if we have a @LogHide to annotate a
>>>>> parameter.
>>>>> 
>>>>> I could see that as step one but we need to think about all that we
>>> would
>>>>> want to do to make sure @Log is the right name. What's a name that says
>>> log
>>>>> all entries and exits?  @LogEntryExit?
>>>>> 
>>>>> Overall I would think that this kind of annotated class would change
>>> that
>>>>> class' byte codes after compilation so that there are no runtime
>>>>> requirements even for annotations. I certainly would not want to leave
>>>>> behind clues like @LogHide to would be attackers
>>>>> 
>>>>> Thoughts?
>>> 
>>> I think that @Log is the wrong name because it’s quite vague. Maybe
>>> @LogMethodCalls, or as you suggest @LogEntryExit.
>>> 
>>> I like the signature you suggested @Gary.
>>> 
>>> @Matt - As for mechanics, I would think we would want to do compile time
>>> byte code weaving. (Is there any appetite for using aspectJ? Feels like a
>>> large ask to add a dependency to log4j2 though.)
>>> 
>> 
>> I've not lloked at AspectJ for a long time, not sure it requires a runtime;
>> I think we want a compile time only dep, Apache Commson Weaver or Apache
>> Commons BCEL come to mind.
>> 
>> Gary
>> 
>> 
>>> 
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 
>>>>>> -Rob
>>>>>> 
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Gary
>>>>>>>>> 
>>>>>>>>> On Thu, Jul 19, 2018, 07:15 Rob Tompkins >>>>>>>> <mailto:chtom...@gmail.com>>
>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Hey folks,
>>>>>>>>>> 
>>>>>>>>>> I’m curious if anyone has thought about adding a class level @Log
>>>>>>>>>> annotation such that upon debug or trace configuration, method
>>> entry
>>>>>> and
>>>>>>>>>> exit gets automatically logged?
>>>>>>>>>> 
>>>>>>>>>> -Rob
> 

Re: @Log annotation

[Rob Tompkins]

That doesn’t seem like a bad idea at all. Have you done that before or are you 
at least familiar with the process so that I could begin working on that?

-Rob

> On Jul 19, 2018, at 2:04 PM, Ralph Goers  wrote:
> 
> We should really propose a new Logging JSR.  I would make sure it includes 
> the ability for the compiler to provide the class name, method name and line 
> number as “special” variables.
> 
> Ralph
> 
>> On Jul 19, 2018, at 10:53 AM, Gary Gregory  wrote:
>> 
>> Maybe the smallest feature we could/should start with it a
>> class-level @ClassLogger() annotation which create a static final Logger
>> initialized with the class name. Too bad Java does not have what Smalltalk
>> calls class instance variables.
>> 
>> I am using "ClassLogger" like JUnit has ClassRule so it leave room for
>> a @Logger like JUnit has @Rule.
>> 
>> Gary
>> 
>> On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins  wrote:
>> 
>>> 
>>> 
>>>> On Jul 19, 2018, at 1:41 PM, Ralph Goers 
>>> wrote:
>>>> 
>>>> To be clear, Log4j-core should have no required dependencies other than
>>> Log4j-API. And we would like to keep optional dependencies to a minimum.
>>> 
>>> Right that makes sense to me. Hence it being an after thought, and I like
>>> Gary’s suggestion of a compile time dependency for the sake of weaving.
>>> 
>>>> 
>>>> Ralph
>>>> 
>>>>> On Jul 19, 2018, at 10:36 AM, Gary Gregory 
>>> wrote:
>>>>> 
>>>>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins >> <mailto:chtom...@gmail.com>> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Jul 19, 2018, at 11:48 AM, Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>> FTR: https://projectlombok.org/features/log
>>>>>>> 
>>>>>>> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Jul 19, 2018, at 10:17 AM, Gary Gregory >>> 
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory <
>>> garydgreg...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Annotation-based logging comes up once in a while here but we
>>> have
>>>>>> not
>>>>>>>>>>>> implemented it. Project Lombok does that IIRC.
>>>>>>>>>>> 
>>>>>>>>>>> Any reason for having not yet implemented it, or just the standard
>>>>>>>>> “time”?
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> It's just more "stuff" and yes, time. And also, no one's wanted to
>>> put
>>>>>>>>> the
>>>>>>>>>> time in.
>>>>>>>>>> 
>>>>>>>>>> But then there are design issues and adding more "stuff" to the API
>>>>>> jar.
>>>>>>>>>> 
>>>>>>>>>> - Would you allow @Log(level=Level.TRACE) (should be the default?)
>>> and
>>>>>>>>>> @Log(level=Level.DEBUG)
>>>>>>>>>> - What happens if you say both?
>>>>>>>>>> - Should you be able to break it up and only say @LogEntry() or
>>>>>>>>> @LogExit().
>>>>>>>>>> - What about @Log(file="${user.home}\foo.log")
>>>>>>>>>> - and on and on ;-)
>>>>>>>>> 
>>>>>>>>> Definitely fair points, I think I would try to go as simple as
>>> possibl

Re: @Log annotation

[Rob Tompkins]

> On Jul 19, 2018, at 2:35 PM, Ralph Goers  wrote:
> 
> It has been brought up before. You can read about the JSR process at 
> http://jcp.org <http://jcp.org/>.

Seems like we’d want to make this a collaborative effort, particularly because 
they look for a collection of experts. I’ll see if I can come up with a draft 
that we could go over here.

-Rob

> 
> Ralph
> 
>> On Jul 19, 2018, at 11:19 AM, Rob Tompkins  wrote:
>> 
>> That doesn’t seem like a bad idea at all. Have you done that before or are 
>> you at least familiar with the process so that I could begin working on that?
>> 
>> -Rob
>> 
>>> On Jul 19, 2018, at 2:04 PM, Ralph Goers  wrote:
>>> 
>>> We should really propose a new Logging JSR.  I would make sure it includes 
>>> the ability for the compiler to provide the class name, method name and 
>>> line number as “special” variables.
>>> 
>>> Ralph
>>> 
>>>> On Jul 19, 2018, at 10:53 AM, Gary Gregory  wrote:
>>>> 
>>>> Maybe the smallest feature we could/should start with it a
>>>> class-level @ClassLogger() annotation which create a static final Logger
>>>> initialized with the class name. Too bad Java does not have what Smalltalk
>>>> calls class instance variables.
>>>> 
>>>> I am using "ClassLogger" like JUnit has ClassRule so it leave room for
>>>> a @Logger like JUnit has @Rule.
>>>> 
>>>> Gary
>>>> 
>>>> On Thu, Jul 19, 2018 at 11:43 AM Rob Tompkins  wrote:
>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 19, 2018, at 1:41 PM, Ralph Goers 
>>>>> wrote:
>>>>>> 
>>>>>> To be clear, Log4j-core should have no required dependencies other than
>>>>> Log4j-API. And we would like to keep optional dependencies to a minimum.
>>>>> 
>>>>> Right that makes sense to me. Hence it being an after thought, and I like
>>>>> Gary’s suggestion of a compile time dependency for the sake of weaving.
>>>>> 
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On Jul 19, 2018, at 10:36 AM, Gary Gregory 
>>>>> wrote:
>>>>>>> 
>>>>>>> eOn Thu, Jul 19, 2018 at 10:19 AM Rob Tompkins >>>> <mailto:chtom...@gmail.com>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Jul 19, 2018, at 11:48 AM, Gary Gregory 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> FTR: https://projectlombok.org/features/log
>>>>>>>>> 
>>>>>>>>> On Thu, Jul 19, 2018 at 8:48 AM Gary Gregory 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Thu, Jul 19, 2018 at 8:26 AM Rob Tompkins 
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Jul 19, 2018, at 10:17 AM, Gary Gregory >>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Jul 19, 2018 at 8:07 AM Rob Tompkins 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jul 19, 2018, at 9:29 AM, Gary Gregory <
>>>>> garydgreg...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Annotation-based logging comes up once in a while here but we
>>>>> have
>>>>>>>> not
>>>>>>>>>>>>>> implemented it. Project Lombok does that IIRC.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Any reason for having not yet implemented it, or just the standard
>>>>>>>>>>> “time”?
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>

Re: Build failed in Jenkins: Log4j 2 3.x #148

[Rob Tompkins]

Looks like Jenkins timed out on checkout or something. 

> On Jul 20, 2018, at 1:08 PM, Ralph Goers  wrote:
> 
> No idea.
> 
> Ralph
> 
>> On Jul 20, 2018, at 9:56 AM, Gary Gregory  wrote:
>> 
>> Could this be a corrupt local repo or an out of disk space issue?
>> 
>> Gary
>> 
>> On Fri, Jul 20, 2018 at 10:44 AM Apache Jenkins Server <
>> jenk...@builds.apache.org> wrote:
>> 
>>> See 
>>> 
>>> --
>>> Started by an SCM change
>>> [EnvInject] - Loading node environment variables.
>>> Building remotely on H35 (ubuntu xenial) in workspace <
>>> https://builds.apache.org/job/Log4j%202%203.x/ws/>
 git rev-parse --is-inside-work-tree # timeout=10
>>> Fetching changes from the remote Git repository
 git config remote.origin.url
>>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git # timeout=10
>>> Cleaning workspace
 git rev-parse --verify HEAD # timeout=10
>>> Resetting working tree
 git reset --hard # timeout=10
>>> ERROR: Error fetching remote repo 'origin'
>>> hudson.plugins.git.GitException: Failed to fetch from
>>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
>>>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888)
>>>   at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155)
>>>   at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
>>>   at hudson.scm.SCM.checkout(SCM.java:504)
>>>   at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
>>>   at
>>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
>>>   at
>>> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>>   at
>>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
>>>   at hudson.model.Run.execute(Run.java:1794)
>>>   at
>>> hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
>>>   at
>>> hudson.model.ResourceController.execute(ResourceController.java:97)
>>>   at hudson.model.Executor.run(Executor.java:429)
>>> Caused by: hudson.plugins.git.GitException: Command "git reset --hard"
>>> returned status code 128:
>>> stdout:
>>> stderr: fatal: unable to read tree 0ea7b3d65fb95137b65531d1c9277951123986a6
>>> 
>>>   at
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)
>>>   at
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1970)
>>>   at
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1966)
>>>   at
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
>>>   at
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.reset(CliGitAPIImpl.java:463)
>>>   at
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:786)
>>>   at hudson.plugins.git.GitAPI.clean(GitAPI.java:311)
>>>   at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
>>>   at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>   at java.lang.reflect.Method.invoke(Method.java:498)
>>>   at
>>> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929)
>>>   at
>>> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:903)
>>>   at
>>> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:855)
>>>   at hudson.remoting.UserRequest.perform(UserRequest.java:212)
>>>   at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>>>   at hudson.remoting.Request$2.run(Request.java:369)
>>>   at
>>> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>>>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>   at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>   at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>   at java.lang.Thread.run(Thread.java:748)
>>>   Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote
>>> call to H35
>>>   at
>>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
>>>   at
>>> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>>>   at hudson.remoting.Channel.call(Channel.java:955)
>>>   at
>>> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:283)
>>>   at com.sun.proxy.$Proxy117.clean(Unknown Source)
>>>   at
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:450)
>>>   at
>>> hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:30)
>>>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:

Re: Build failed in Jenkins: Log4j 2 3.x #148

[Rob Tompkins]

> On Jul 21, 2018, at 8:24 AM, Dominik Psenner  wrote:
> 
> Jenkins slaves currently have very low disk space. This may be a out of
> disk space in disguise.

I definitely agree with that thought. Disk space issues cause all sorts of 
weird exceptions in Jenkins because that’s its data storage mechanism


> 
>> On Sat, 21 Jul 2018, 14:12 Rob Tompkins,  wrote:
>> 
>> Looks like Jenkins timed out on checkout or something.
>> 
>>> On Jul 20, 2018, at 1:08 PM, Ralph Goers 
>> wrote:
>>> 
>>> No idea.
>>> 
>>> Ralph
>>> 
>>>> On Jul 20, 2018, at 9:56 AM, Gary Gregory 
>> wrote:
>>>> 
>>>> Could this be a corrupt local repo or an out of disk space issue?
>>>> 
>>>> Gary
>>>> 
>>>> On Fri, Jul 20, 2018 at 10:44 AM Apache Jenkins Server <
>>>> jenk...@builds.apache.org> wrote:
>>>> 
>>>>> See <
>> https://builds.apache.org/job/Log4j%202%203.x/148/display/redirect>
>>>>> 
>>>>> --
>>>>> Started by an SCM change
>>>>> [EnvInject] - Loading node environment variables.
>>>>> Building remotely on H35 (ubuntu xenial) in workspace <
>>>>> https://builds.apache.org/job/Log4j%202%203.x/ws/>
>>>>>> git rev-parse --is-inside-work-tree # timeout=10
>>>>> Fetching changes from the remote Git repository
>>>>>> git config remote.origin.url
>>>>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git #
>> timeout=10
>>>>> Cleaning workspace
>>>>>> git rev-parse --verify HEAD # timeout=10
>>>>> Resetting working tree
>>>>>> git reset --hard # timeout=10
>>>>> ERROR: Error fetching remote repo 'origin'
>>>>> hudson.plugins.git.GitException: Failed to fetch from
>>>>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
>>>>>  at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888)
>>>>>  at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155)
>>>>>  at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
>>>>>  at hudson.scm.SCM.checkout(SCM.java:504)
>>>>>  at
>> hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
>>>>>  at
>>>>> 
>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
>>>>>  at
>>>>> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>>>>  at
>>>>> 
>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
>>>>>  at hudson.model.Run.execute(Run.java:1794)
>>>>>  at
>>>>> hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
>>>>>  at
>>>>> hudson.model.ResourceController.execute(ResourceController.java:97)
>>>>>  at hudson.model.Executor.run(Executor.java:429)
>>>>> Caused by: hudson.plugins.git.GitException: Command "git reset --hard"
>>>>> returned status code 128:
>>>>> stdout:
>>>>> stderr: fatal: unable to read tree
>> 0ea7b3d65fb95137b65531d1c9277951123986a6
>>>>> 
>>>>>  at
>>>>> 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)
>>>>>  at
>>>>> 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1970)
>>>>>  at
>>>>> 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1966)
>>>>>  at
>>>>> 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
>>>>>  at
>>>>> 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.reset(CliGitAPIImpl.java:463)
>>>>>  at
>>>>> 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:786)
>>>>>  at hudson.plugins.git.GitAPI.clean(GitAPI.java:311)
>>>>>  at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
>>>>>  at
>>>>> 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>  at java.lang.reflect.Method.invoke(Method.java:498)
>&g

Re: Logging and containers

[Rob Tompkins]

I find myself writing to either standard out or a file. When I write to a file 
in docker I tend to “share” that file with the filesystem on the docker host. 
But, I prefer writing to standard our and appending that to a file on the 
machine as it deals with less of the underlying filesystem networking (which is 
cumbersome).

Don’t know if that helps.

-Rob

> On Aug 6, 2018, at 11:44 AM, Ralph Goers  wrote:
> 
> I don’t know. That is why I am asking if you guys have tried anything with 
> Docker containers. Writing to stdout is a “best practice” so I am just trying 
> to validate whether that is good or bad advice or what needs to be done to 
> make it work well. Or if Log4j should implement a Docker plugin to write to, 
> or something else.
> 
>> On Aug 6, 2018, at 8:28 AM, Gary Gregory  wrote:
>> 
>> Can't you just configure the console appender with a large-ish buffer and
>> remove the bottleneck?
>> 
>> Gary
>> 
>> On Mon, Aug 6, 2018 at 8:55 AM Ralph Goers 
>> wrote:
>> 
>>> So that begs the question, when logging to stdout in a container is a
>>> console attached? i.e. can you normally view the output like you could in a
>>> regular VM or is it all redirected somewhere else?  I haven’t worked much
>>> with Docker yet so I am afraid I don’t know  the answer.
>>> 
>>> Ralph
>>> 
 On Aug 6, 2018, at 6:40 AM, Remko Popma  wrote:
 
 It may be to do with whether a tty is attached and how fast it is:
>>> https://stackoverflow.com/questions/3857052/why-is-printing-to-stdout-so-slow-can-it-be-sped-up
 
 (Shameless plug) Every java main() method deserves http://picocli.info
 
> On Aug 6, 2018, at 4:21, Ralph Goers 
>>> wrote:
> 
> Our performance page shows that logging to the console is extremely
>>> slow. Yet one of the “best practices” for containers is to have the
>>> applications log to STDOUT or STDERR. This leads me to two questions:
> Is the performance of writing to STDOUT just as bad in a container? I
>>> have no reason to believe it wouldn’t be but have no evidence.
> Assuming performance is poor what are the realistic alternatives? Is
>>> there something more Log4j needs to be doing to play well in a cloud
>>> environment?
> 
> Ralph
>>> 
>>> 
>>> 
> 
> 

Re: Hacktoberfest 2018

[Rob Tompkins]

Me too :-P

> On Nov 2, 2018, at 12:10 PM, Matt Sicker  wrote:
> 
> Same here!
> 
>> On Fri, 2 Nov 2018 at 10:53, Gary Gregory  wrote:
>> 
>> I should get my t-shirt soon :-)
>> 
>> Gary
>> 
>>> On Mon, Oct 1, 2018 at 10:05 AM Matt Sicker  wrote:
>>> 
>>> https://hacktoberfest.digitalocean.com/
>>> 
>>> I should have more time this month to help review PRs and such. Spread
>> the
>>> word!
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
> 
> 
> -- 
> Matt Sicker 

Re: [ALL] Using Dependabot for automatic dependency updates?

[Rob Tompkins]

Do you guys want to try this on something in commons first? We could try it on 
a lesser used component to see how it performs.

-Rob

> On Mar 31, 2019, at 8:25 PM, Matt Sicker  wrote:
> 
> It files a PR which kicks off a CI build. I think you can configure it to
> automatically merge if the build passes. Otherwise it’s jus another open PR.
> 
> On Sun, Mar 31, 2019 at 17:17, Gary Gregory  wrote:
> 
>> Might be worth a try.  I take it it only flies PRs if a build passes all
>> tests?
>> 
>> Gary
>> 
>> On Mon, Mar 25, 2019, 14:23 Matt Sicker  wrote:
>> 
>>> I wasn't thinking of automating this fully at any point. The bot does
>>> file PRs for each dependency individually. I'm not sure how
>>> configurable everything is, but I do like the sound of having multiple
>>> dependency management profiles for compatibility testing purposes.
>>> 
>>> On Mon, 25 Mar 2019 at 13:07, Gary Gregory 
>> wrote:
 
 This reminds me: What happened to Apache Gump? Didn't it handle this?
 
 Gary
 
 On Mon, Mar 25, 2019 at 2:02 PM Gary Gregory 
>>> wrote:
 
> There room for automation in this area, but I only seen it as an
> informative step for now. Like the tool saying "I've ran the build
>> with
> this change and it's green/red". Today, without this tool, I could
>> see
>>> a
> tool doing :
> - create a branch for a change and push it, create a PR
> - look at what GitHub/Travis-CI reports
> 
> then you, the dev:
> 
> - accept/reject the PR
> 
> This would only be done one dep change at a time. IOW, only once
>> you've
> accepted/rejected a dep change would you move on to the next one.
> 
> Gary
> 
> On Mon, Mar 25, 2019 at 1:46 PM Ralph Goers <
>>> ralph.go...@dslextreme.com>
> wrote:
> 
>> I have mixed feelings. Gary has been manually doing this for quite a
>> while and I have always had concerns - besides driving his commit
>>> count
>> artificially through the roof.
>> 
>> Managing dependencies really needs to be managed carefully. When we
>> upgrade a dependency that effectively becomes the minimum supported
>> version. In that sense we are upgrading dependencies way too fast.
>> At
>>> the
>> same time, we need to insure that we don’t have problems with new
>>> releases.
>> As such we really need two versions of the parent pom - one that is
>>> used
>> for verifying the latest versions of dependencies and one that is
>>> used for
>> the release that specifies the minimum supported version (typically
>>> this
>> would be expressed as a version range).
>> 
>> I’m also concerned because some dependencies upgrade their minimum
>> required JDK version in a minor release. That happened with the
>> Flume
>>> 1.8
>> release. So we cannot upgrade to that version in the release-2.x
>>> branch,
>> although our users can if they want to.  We also ran into a problem
>>> with
>> SLF4J. The latest release dropped a class that we use. We have
>>> modified the
>> code to support the latest releases but we require the last release
>>> that
>> had the class to compile.
>> 
>> Also, our process has always been to create a Jira for everything,
>> including updating dependency versions, and including them in
>>> changes.xml.
>> It looks like this tool doesn’t do either of these things.
>> 
>> Ralph
>> 
>>> On Mar 25, 2019, at 9:24 AM, Matt Sicker 
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> Various Jenkins projects have been using Dependabot [1] to
>>> automatically make PRs to update dependencies. We could use this
>> for
>>> most of our components it looks like. What do you think about
>>> adopting
>>> use of this bot?
>>> 
>>> [1]: https://dependabot.com/
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
> -- 
> Matt Sicker 

Re: Your project website

[Rob Tompkins]

> On Aug 5, 2020, at 12:30 PM, Matt Sicker  wrote:
> 
> The CMS is the transformation system itself from my understanding. I
> don't believe svnpubsub is being deprecated here. Our landing page
> templates may need to be converted, but that's about it.

Thanks Matt for that clarification.

-Rob

> 
> On Wed, 5 Aug 2020 at 11:10, Ralph Goers  wrote:
>> 
>> Yes, the main landing pages are all in the CMS.  I was always under the 
>> impression that even the Maven generated projects are considered to be part 
>> of the CMS since it provides a way to link to them via the external 
>> definitions and they have to be published to a specific location in svn.
>> 
>> This is the first time I have heard that the CMS was reaching end-of-life. 
>> Giving us a couple of weeks to move to something else is unrealistic.
>> 
>> Ralph
>> 
>>> On Aug 5, 2020, at 7:36 AM, Matt Sicker  wrote:
>>> 
>>> From what I can tell, we have a few pages that use the CMS on
>>> logging.apache.org, though most of the site is generated from Maven
>>> and committed to Subversion.
>>> 
>>> For the root site, I'd imagine we can migrate to Pelican or whatever.
>>> This could be an opportunity to switch over to Git for publishing the
>>> site (which might take less time to upload), too, but I think that's
>>> unrelated.
>>> 
>>> On Wed, 5 Aug 2020 at 07:31, Andrew Wetmore  wrote:
 
 Hi:
 
 I am part of the Infrastructure team, and am writing to ask whether your
 project is still using the Apache CMS for your project website. As you
 know, the CMS is reaching end-of-life, and we need projects to move their
 websites onto a different option within the next few weeks.
 
 There are several alternatives available, including those listed on this
 page [1] on managing project websites. Infra is assembling a Wiki page [2]
 on migrating a website from the CMS, and is looking forward to helping
 projects with this transition.
 
 Please let me know whether your site is still on the Apache CMS and, if so,
 who will be the project point-of-contact with Infra for the migration.
 
 Thank you!
 
 
 
 
 [1] https://infra.apache.org/project-site.html
 
 [2]
 https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
 
 
 
 --
 Andrew Wetmore
 Technical Writer-Editor
 Infra
 *Apache Software Foundation*
 andr...@apache.org
 
 
 Virus-free.
 www.avast.com
 
 <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
>> 
> 
> 
> -- 
> Matt Sicker 

Re: [ANNOUNCE] Welcome our new committer, Stephen Webb!

[Rob Tompkins]

(Applause) Congratulations!

-Rob

> On Aug 11, 2020, at 3:41 PM, Matt Sicker  wrote:
> 
> Hi,
> 
> It is my pleasure to announce to the community that Stephen Webb
> has joined our ranks.
> 
> Stephen has been contributing to log4cxx for a while and helping to
> shape a new release, and we think that he'll be a valuable member of
> Apache Logging Services now and in the future. Please welcome aboard
> our newest committer, Robert!
> 
> Kind regards,
> Matt Sicker
> VP Logging Services, ASF

Re: Migrating the landing page

[Rob Tompkins]

Gentlemen, Im hoping we can get project chainsaw launched off at NASA on the 
coming months. If I can just keep my foot in the door there and maybe climb a 
few stairs, I think NASA might just want it ;-), but Im going to need a few 
weeks to see if we can get up those stairs.

Nonetheless, I hope some contributions I could make might get it off the ground 
:-)

Very much hope you all are doing well

Cheers,
-Rob

> On Sep 23, 2023, at 7:47 AM, Christian Grobmeier  wrote:
> 
> 
> 
>> On Sat, Sep 23, 2023, at 02:30, Apache wrote:
>> You have to be kidding me. I now need to use Docker to build the web 
>> site? And that is somehow simpler?
> 
> The actual build is then done by GitHub Actions. And yes, I consider it a lot 
> simpler to run one docker command (I even have a shell script for this) to 
> check and let actions do the rest.
> 
> You can see it in action on the privacy website. 
> 
>> 
>> 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: Migrating the landing page

[Rob Tompkins]

Sound good…tell me where to start helping out.

-Rob

> On Sep 23, 2023, at 4:43 PM, Ralph Goers  wrote:
> 
> Rob,
> 
> It looks like you are a PMC member of Commons as well as an ASF member.  
> Given that, if you are interested in committing to and supporting Chainsaw I 
> would happily vote to give you Logging Services commit privy.
> 
> Ralph
> 
> 
>> On Sep 23, 2023, at 12:00 PM, Rob Tompkins  wrote:
>> 
>> Gentlemen, Im hoping we can get project chainsaw launched off at NASA on the 
>> coming months. If I can just keep my foot in the door there and maybe climb 
>> a few stairs, I think NASA might just want it ;-), but Im going to need a 
>> few weeks to see if we can get up those stairs.
>> 
>> Nonetheless, I hope some contributions I could make might get it off the 
>> ground :-)
>> 
>> Very much hope you all are doing well
>> 
>> Cheers,
>> -Rob
>> 
>>> On Sep 23, 2023, at 7:47 AM, Christian Grobmeier  wrote:
>>> 
>>> 
>>> 
>>>> On Sat, Sep 23, 2023, at 02:30, Apache wrote:
>>>> You have to be kidding me. I now need to use Docker to build the web 
>>>> site? And that is somehow simpler?
>>> 
>>> The actual build is then done by GitHub Actions. And yes, I consider it a 
>>> lot simpler to run one docker command (I even have a shell script for this) 
>>> to check and let actions do the rest.
>>> 
>>> You can see it in action on the privacy website. 
>>> 
>>>> 
>>>> 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
>>>>> 
>

Re: `chainsaw` vs `logging-chainsaw`

[Rob Tompkins]

Maybe we should un-archive it and run with it in a new direction?

-Rob

> On Sep 26, 2023, at 4:43 PM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> Infra archived this repo for us:
> https://github.com/apache/chainsaw
> 
> Kind regards,
> Christian
> 
> On Fri, Sep 22, 2023, at 22:33, Gary Gregory wrote:
>> On Fri, Sep 22, 2023 at 2:28 PM Christian Grobmeier
>>  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Sep 22, 2023, at 20:16, Gary Gregory wrote:
 An svn mirror should be useless. Would you please do a sanity check? Is the
 last commit from repo in our git repo?
>>> 
>>> Yes, the Git repo: Updated on Jul 19, 2023  1,134 commits
>>> SVN: Updated on Jul 8, 2022,  934 commits
>> 
>> TY for checking Christian.
>> 
>> Gary
>> 
>>> 
 
 TY,
 Gary
 
 On Fri, Sep 22, 2023, 1:50 PM Christian Grobmeier  
 wrote:
 
> 
> On Thu, Sep 21, 2023, at 21:53, Robert Middleton wrote:
>> I think #1 is a mirror of SVN(
>> https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while #2 is a
>> mirror of the gitbox repository.
> 
> Looks like the SVN mirror is outdated. Can we safely remove it?
> If there are no objections, I will create a ticket with infra
> 
> Christian
> 
>> -Robert
>> 
>> On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı  wrote:
>> 
>>> Does anybody know the difference between these two repositories[1][2]
>>> and why the mirroring does not work? [1] hasn't been updated since
>>> 2014.
>>> 
>>> [1] https://github.com/apache/chainsaw
>>> [2] https://github.com/apache/logging-chainsaw
>>> 
> 

Re: `chainsaw` vs `logging-chainsaw`

[Rob Tompkins]

Ah :-)

Cheers,
-Rob

> On Sep 26, 2023, at 6:03 PM, Robert Middleton  wrote:
> 
> logging-chainsaw is not archived and contains the most up-to-date code.
> The old 'chainsaw' repository has been archived.
> 
> -Robert Middleton
> 
> On Tue, Sep 26, 2023 at 5:57 PM Rob Tompkins  wrote:
> 
>> Maybe we should un-archive it and run with it in a new direction?
>> 
>> -Rob
>> 
>>> On Sep 26, 2023, at 4:43 PM, Christian Grobmeier 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> Infra archived this repo for us:
>>> https://github.com/apache/chainsaw
>>> 
>>> Kind regards,
>>> Christian
>>> 
>>> On Fri, Sep 22, 2023, at 22:33, Gary Gregory wrote:
>>>> On Fri, Sep 22, 2023 at 2:28 PM Christian Grobmeier
>>>>  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Sep 22, 2023, at 20:16, Gary Gregory wrote:
>>>>>> An svn mirror should be useless. Would you please do a sanity check?
>> Is the
>>>>>> last commit from repo in our git repo?
>>>>> 
>>>>> Yes, the Git repo: Updated on Jul 19, 2023  1,134 commits
>>>>> SVN: Updated on Jul 8, 2022,  934 commits
>>>> 
>>>> TY for checking Christian.
>>>> 
>>>> Gary
>>>> 
>>>>> 
>>>>>> 
>>>>>> TY,
>>>>>> Gary
>>>>>> 
>>>>>> On Fri, Sep 22, 2023, 1:50 PM Christian Grobmeier 
>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Sep 21, 2023, at 21:53, Robert Middleton wrote:
>>>>>>>> I think #1 is a mirror of SVN(
>>>>>>>> https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while
>> #2 is a
>>>>>>>> mirror of the gitbox repository.
>>>>>>> 
>>>>>>> Looks like the SVN mirror is outdated. Can we safely remove it?
>>>>>>> If there are no objections, I will create a ticket with infra
>>>>>>> 
>>>>>>> Christian
>>>>>>> 
>>>>>>>> -Robert
>>>>>>>> 
>>>>>>>> On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı 
>> wrote:
>>>>>>>> 
>>>>>>>>> Does anybody know the difference between these two
>> repositories[1][2]
>>>>>>>>> and why the mirroring does not work? [1] hasn't been updated since
>>>>>>>>> 2014.
>>>>>>>>> 
>>>>>>>>> [1] https://github.com/apache/chainsaw
>>>>>>>>> [2] https://github.com/apache/logging-chainsaw
>>>>>>>>> 
>>>>>>> 
>> 
>> 

Re: `chainsaw` vs `logging-chainsaw`

[Rob Tompkins]

I would support https://github.com/apache/chainsaw being a set of standard go 
libraries much like commons is for java. 

Thoughts?

-Rob

> On Sep 26, 2023, at 6:08 PM, Rob Tompkins  wrote:
> 
> Ah :-)
> 
> Cheers,
> -Rob
> 
>> On Sep 26, 2023, at 6:03 PM, Robert Middleton  wrote:
>> 
>> logging-chainsaw is not archived and contains the most up-to-date code.
>> The old 'chainsaw' repository has been archived.
>> 
>> -Robert Middleton
>> 
>>> On Tue, Sep 26, 2023 at 5:57 PM Rob Tompkins  wrote:
>>> 
>>> Maybe we should un-archive it and run with it in a new direction?
>>> 
>>> -Rob
>>> 
>>>> On Sep 26, 2023, at 4:43 PM, Christian Grobmeier 
>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Infra archived this repo for us:
>>>> https://github.com/apache/chainsaw
>>>> 
>>>> Kind regards,
>>>> Christian
>>>> 
>>>> On Fri, Sep 22, 2023, at 22:33, Gary Gregory wrote:
>>>>> On Fri, Sep 22, 2023 at 2:28 PM Christian Grobmeier
>>>>>  wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, Sep 22, 2023, at 20:16, Gary Gregory wrote:
>>>>>>> An svn mirror should be useless. Would you please do a sanity check?
>>> Is the
>>>>>>> last commit from repo in our git repo?
>>>>>> 
>>>>>> Yes, the Git repo: Updated on Jul 19, 2023  1,134 commits
>>>>>> SVN: Updated on Jul 8, 2022,  934 commits
>>>>> 
>>>>> TY for checking Christian.
>>>>> 
>>>>> Gary
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> TY,
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Fri, Sep 22, 2023, 1:50 PM Christian Grobmeier 
>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Sep 21, 2023, at 21:53, Robert Middleton wrote:
>>>>>>>>> I think #1 is a mirror of SVN(
>>>>>>>>> https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while
>>> #2 is a
>>>>>>>>> mirror of the gitbox repository.
>>>>>>>> 
>>>>>>>> Looks like the SVN mirror is outdated. Can we safely remove it?
>>>>>>>> If there are no objections, I will create a ticket with infra
>>>>>>>> 
>>>>>>>> Christian
>>>>>>>> 
>>>>>>>>> -Robert
>>>>>>>>> 
>>>>>>>>> On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı 
>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Does anybody know the difference between these two
>>> repositories[1][2]
>>>>>>>>>> and why the mirroring does not work? [1] hasn't been updated since
>>>>>>>>>> 2014.
>>>>>>>>>> 
>>>>>>>>>> [1] https://github.com/apache/chainsaw
>>>>>>>>>> [2] https://github.com/apache/logging-chainsaw
>>>>>>>>>> 
>>>>>>>> 
>>> 
>>> 
>