You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2020/12/09 21:28:47 UTC
Log4Go
The company I work for has started using Go for some of the middleware components we are developing. I have looked at several logging frameworks for Go and have not been impressed by any of them. As such, I am considering starting a project here. The major goals of this would be:
Use an external configuration (at least JSON and XML).
Allow the configuration to be accessed via HTTP(S) - Spring Cloud Configuration.
Allow dynamic reconfiguration.
Allow plugins (probably as Go plugins?)
Support for Markers, context attributes, Layouts, Appenders.
Anyone interested?
Ralph
Re: Log4Go
Posted by Matt Sicker <bo...@gmail.com>.
Sounds cool to me, too. This could be a nice chance to standardize config
file formats across the various languages here, too, though more of a nice
to have.
On Wed, Dec 9, 2020 at 16:01 Gary Gregory <ga...@gmail.com> wrote:
> I'm always up for learning something new :-)
>
> Gary
>
> On Wed, Dec 9, 2020, 16:29 Ralph Goers <ra...@dslextreme.com> wrote:
>
> > The company I work for has started using Go for some of the middleware
> > components we are developing. I have looked at several logging frameworks
> > for Go and have not been impressed by any of them. As such, I am
> > considering starting a project here. The major goals of this would be:
> >
> > Use an external configuration (at least JSON and XML).
> > Allow the configuration to be accessed via HTTP(S) - Spring Cloud
> > Configuration.
> > Allow dynamic reconfiguration.
> > Allow plugins (probably as Go plugins?)
> > Support for Markers, context attributes, Layouts, Appenders.
> >
> > Anyone interested?
> >
> > Ralph
> >
> >
>
Re: Log4Go
Posted by Gary Gregory <ga...@gmail.com>.
I'm always up for learning something new :-)
Gary
On Wed, Dec 9, 2020, 16:29 Ralph Goers <ra...@dslextreme.com> wrote:
> The company I work for has started using Go for some of the middleware
> components we are developing. I have looked at several logging frameworks
> for Go and have not been impressed by any of them. As such, I am
> considering starting a project here. The major goals of this would be:
>
> Use an external configuration (at least JSON and XML).
> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
> Configuration.
> Allow dynamic reconfiguration.
> Allow plugins (probably as Go plugins?)
> Support for Markers, context attributes, Layouts, Appenders.
>
> Anyone interested?
>
> Ralph
>
>
Re: Log4Go
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
so I don't have the karma to create a page (probably also not for
editing it) I would really like to start with this. So could someone
with the ability to do so, grant me the karma to create and edit pages
(created by myself) in your wiki?
Chris
On 01.07.21 18:28, Christofer Dutz wrote:
> Hi all,
>
> as far as I know, PMCs have the carma to create repos.
>
> And sure ... happy to do a rough plan before starting to write code. As
> long as it's not like writing a RFC document. If you or someone here
> could setup a root document, we could start writing and drawing.
>
> Chris
>
>
> On 01.07.21 17:23, 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 <da...@gmail.com> 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 <cd...@apache.org> 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 like Apache Logging and not as a side project of PLC4X.
>>>>
>>>> Chris
>>>>
>>>>
>>>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>>>> I support the initiative. At bol.com, we also needed to implement our own
>>>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>>>> and I don't think I will be able to spare time to both learn a new language
>>>>> (even though I am really into learning Go) and maintain such a project. I
>>>>> mean, not that you need my help, but just wanted to share my availability.
>>>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>>>> I also agree with Matt that this would pave the road to standardizing the
>>>>> logging configuration file formats across multiple languages.
>>>>> What I witness most for code — in particular libraries, APIs, etc. —
>>>>> written by programmers whose expertise is actually in another language,
>>>>> that they mostly don't get the language conventions right. For instance, I
>>>>> was horrified many times in the past to read/use Java code written by
>>>>> JavaScript (front-end) developers. These two languages have totally
>>>>> different approaches and (community embraced) conventions that one cannot
>>>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>>>> recommend consulting to experts in this domain before publishing something
>>>>> to the outside world. For one, I am pretty sure there should be Go experts
>>>>> within the Apache community, hence having expert reviews should be
>>>>> relatively easy. Second, Apache has such a good track record in delivering
>>>>> high quality software, even an inferior project might get quite some
>>>>> attraction and we will be bound to maintain it for years. These are my
>>>>> concerns in general. That said, I would be more than happy to ditch off our
>>>>> custom Go loggers with an Apache-approved alternative.
>>>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
>>>>> wrote:
>>>>>> The company I work for has started using Go for some of the middleware
>>>>>> components we are developing. I have looked at several logging frameworks
>>>>>> for Go and have not been impressed by any of them. As such, I am
>>>>>> considering starting a project here. The major goals of this would be:
>>>>>>
>>>>>> Use an external configuration (at least JSON and XML).
>>>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>>>>> Configuration.
>>>>>> Allow dynamic reconfiguration.
>>>>>> Allow plugins (probably as Go plugins?)
>>>>>> Support for Markers, context attributes, Layouts, Appenders.
>>>>>>
>>>>>> Anyone interested?
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>
>>
Re: Log4Go
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
as far as I know, PMCs have the carma to create repos.
And sure ... happy to do a rough plan before starting to write code. As
long as it's not like writing a RFC document. If you or someone here
could setup a root document, we could start writing and drawing.
Chris
On 01.07.21 17:23, 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 <da...@gmail.com> 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 <cd...@apache.org> 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 like Apache Logging and not as a side project of PLC4X.
>>>
>>> Chris
>>>
>>>
>>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>>> I support the initiative. At bol.com, we also needed to implement our own
>>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>>> and I don't think I will be able to spare time to both learn a new language
>>>> (even though I am really into learning Go) and maintain such a project. I
>>>> mean, not that you need my help, but just wanted to share my availability.
>>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>>> I also agree with Matt that this would pave the road to standardizing the
>>>> logging configuration file formats across multiple languages.
>>>> What I witness most for code — in particular libraries, APIs, etc. —
>>>> written by programmers whose expertise is actually in another language,
>>>> that they mostly don't get the language conventions right. For instance, I
>>>> was horrified many times in the past to read/use Java code written by
>>>> JavaScript (front-end) developers. These two languages have totally
>>>> different approaches and (community embraced) conventions that one cannot
>>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>>> recommend consulting to experts in this domain before publishing something
>>>> to the outside world. For one, I am pretty sure there should be Go experts
>>>> within the Apache community, hence having expert reviews should be
>>>> relatively easy. Second, Apache has such a good track record in delivering
>>>> high quality software, even an inferior project might get quite some
>>>> attraction and we will be bound to maintain it for years. These are my
>>>> concerns in general. That said, I would be more than happy to ditch off our
>>>> custom Go loggers with an Apache-approved alternative.
>>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>> The company I work for has started using Go for some of the middleware
>>>>> components we are developing. I have looked at several logging frameworks
>>>>> for Go and have not been impressed by any of them. As such, I am
>>>>> considering starting a project here. The major goals of this would be:
>>>>>
>>>>> Use an external configuration (at least JSON and XML).
>>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>>>> Configuration.
>>>>> Allow dynamic reconfiguration.
>>>>> Allow plugins (probably as Go plugins?)
>>>>> Support for Markers, context attributes, Layouts, Appenders.
>>>>>
>>>>> Anyone interested?
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>
>
Re: Log4Go
Posted by Apache <ra...@dslextreme.com>.
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 <ch...@c-ware.de> 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 <ra...@dslextreme.com> 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 like Apache Logging and not as a side project of PLC4X.
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>>>>> I support the initiative. At bol.com, we also needed to implement our own
>>>>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>>>>> and I don't think I will be able to spare time to both learn a new language
>>>>>> (even though I am really into learning Go) and maintain such a project. I
>>>>>> mean, not that you need my help, but just wanted to share my availability.
>>>>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>>>>> I also agree with Matt that this would pave the road to standardizing the
>>>>>> logging configuration file formats across multiple languages.
>>>>>> What I witness most for code — in particular libraries, APIs, etc. —
>>>>>> written by programmers whose expertise is actually in another language,
>>>>>> that they mostly don't get the language conventions right. For instance, I
>>>>>> was horrified many times in the past to read/use Java code written by
>>>>>> JavaScript (front-end) developers. These two languages have totally
>>>>>> different approaches and (community embraced) conventions that one cannot
>>>>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>>>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>>>>> recommend consulting to experts in this domain before publishing something
>>>>>> to the outside world. For one, I am pretty sure there should be Go experts
>>>>>> within the Apache community, hence having expert reviews should be
>>>>>> relatively easy. Second, Apache has such a good track record in delivering
>>>>>> high quality software, even an inferior project might get quite some
>>>>>> attraction and we will be bound to maintain it for years. These are my
>>>>>> concerns in general. That said, I would be more than happy to ditch off our
>>>>>> custom Go loggers with an Apache-approved alternative.
>>>>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers
>>>>>> wrote:
>>>>>>> The company I work for has started using Go for some of the middleware
>>>>>>> components we are developing. I have looked at several logging frameworks
>>>>>>> for Go and have not been impressed by any of them. As such, I am
>>>>>>> considering starting a project here. The major goals of this would be:
>>>>>>>
>>>>>>> Use an external configuration (at least JSON and XML).
>>>>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>>>>>> Configuration.
>>>>>>> Allow dynamic reconfiguration.
>>>>>>> Allow plugins (probably as Go plugins?)
>>>>>>> Support for Markers, context attributes, Layouts, Appenders.
>>>>>>>
>>>>>>> Anyone interested?
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>
>>>
>>>
>>>
Re: Log4Go
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ra...@dslextreme.com> 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 like Apache Logging and not as a side project of PLC4X.
>>>>
>>>> Chris
>>>>
>>>>
>>>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>>>> I support the initiative. At bol.com, we also needed to implement our own
>>>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>>>> and I don't think I will be able to spare time to both learn a new language
>>>>> (even though I am really into learning Go) and maintain such a project. I
>>>>> mean, not that you need my help, but just wanted to share my availability.
>>>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>>>> I also agree with Matt that this would pave the road to standardizing the
>>>>> logging configuration file formats across multiple languages.
>>>>> What I witness most for code — in particular libraries, APIs, etc. —
>>>>> written by programmers whose expertise is actually in another language,
>>>>> that they mostly don't get the language conventions right. For instance, I
>>>>> was horrified many times in the past to read/use Java code written by
>>>>> JavaScript (front-end) developers. These two languages have totally
>>>>> different approaches and (community embraced) conventions that one cannot
>>>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>>>> recommend consulting to experts in this domain before publishing something
>>>>> to the outside world. For one, I am pretty sure there should be Go experts
>>>>> within the Apache community, hence having expert reviews should be
>>>>> relatively easy. Second, Apache has such a good track record in delivering
>>>>> high quality software, even an inferior project might get quite some
>>>>> attraction and we will be bound to maintain it for years. These are my
>>>>> concerns in general. That said, I would be more than happy to ditch off our
>>>>> custom Go loggers with an Apache-approved alternative.
>>>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers
>>>>> wrote:
>>>>>> The company I work for has started using Go for some of the middleware
>>>>>> components we are developing. I have looked at several logging frameworks
>>>>>> for Go and have not been impressed by any of them. As such, I am
>>>>>> considering starting a project here. The major goals of this would be:
>>>>>>
>>>>>> Use an external configuration (at least JSON and XML).
>>>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>>>>> Configuration.
>>>>>> Allow dynamic reconfiguration.
>>>>>> Allow plugins (probably as Go plugins?)
>>>>>> Support for Markers, context attributes, Layouts, Appenders.
>>>>>>
>>>>>> Anyone interested?
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>
>>
>>
Re: Log4Go
Posted by Christofer Dutz <ch...@c-ware.de>.
(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 <ra...@dslextreme.com> 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 like Apache Logging and not as a side project of PLC4X.
>>>
>>> Chris
>>>
>>>
>>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>>> I support the initiative. At bol.com, we also needed to implement our own
>>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>>> and I don't think I will be able to spare time to both learn a new language
>>>> (even though I am really into learning Go) and maintain such a project. I
>>>> mean, not that you need my help, but just wanted to share my availability.
>>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>>> I also agree with Matt that this would pave the road to standardizing the
>>>> logging configuration file formats across multiple languages.
>>>> What I witness most for code — in particular libraries, APIs, etc. —
>>>> written by programmers whose expertise is actually in another language,
>>>> that they mostly don't get the language conventions right. For instance, I
>>>> was horrified many times in the past to read/use Java code written by
>>>> JavaScript (front-end) developers. These two languages have totally
>>>> different approaches and (community embraced) conventions that one cannot
>>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>>> recommend consulting to experts in this domain before publishing something
>>>> to the outside world. For one, I am pretty sure there should be Go experts
>>>> within the Apache community, hence having expert reviews should be
>>>> relatively easy. Second, Apache has such a good track record in delivering
>>>> high quality software, even an inferior project might get quite some
>>>> attraction and we will be bound to maintain it for years. These are my
>>>> concerns in general. That said, I would be more than happy to ditch off our
>>>> custom Go loggers with an Apache-approved alternative.
>>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers
>>>> wrote:
>>>>> The company I work for has started using Go for some of the middleware
>>>>> components we are developing. I have looked at several logging frameworks
>>>>> for Go and have not been impressed by any of them. As such, I am
>>>>> considering starting a project here. The major goals of this would be:
>>>>>
>>>>> Use an external configuration (at least JSON and XML).
>>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>>>> Configuration.
>>>>> Allow dynamic reconfiguration.
>>>>> Allow plugins (probably as Go plugins?)
>>>>> Support for Markers, context attributes, Layouts, Appenders.
>>>>>
>>>>> Anyone interested?
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>
>
>
Re: Log4Go
Posted by Davyd McColl <da...@gmail.com>.
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 <ra...@dslextreme.com> 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 like Apache Logging and not as a side project of PLC4X.
>>
>> Chris
>>
>>
>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>> I support the initiative. At bol.com, we also needed to implement our own
>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>> and I don't think I will be able to spare time to both learn a new language
>>> (even though I am really into learning Go) and maintain such a project. I
>>> mean, not that you need my help, but just wanted to share my availability.
>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>> I also agree with Matt that this would pave the road to standardizing the
>>> logging configuration file formats across multiple languages.
>>> What I witness most for code — in particular libraries, APIs, etc. —
>>> written by programmers whose expertise is actually in another language,
>>> that they mostly don't get the language conventions right. For instance, I
>>> was horrified many times in the past to read/use Java code written by
>>> JavaScript (front-end) developers. These two languages have totally
>>> different approaches and (community embraced) conventions that one cannot
>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>> recommend consulting to experts in this domain before publishing something
>>> to the outside world. For one, I am pretty sure there should be Go experts
>>> within the Apache community, hence having expert reviews should be
>>> relatively easy. Second, Apache has such a good track record in delivering
>>> high quality software, even an inferior project might get quite some
>>> attraction and we will be bound to maintain it for years. These are my
>>> concerns in general. That said, I would be more than happy to ditch off our
>>> custom Go loggers with an Apache-approved alternative.
>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers
>>> wrote:
>>> > The company I work for has started using Go for some of the middleware
>>> > components we are developing. I have looked at several logging frameworks
>>> > for Go and have not been impressed by any of them. As such, I am
>>> > considering starting a project here. The major goals of this would be:
>>> >
>>> > Use an external configuration (at least JSON and XML).
>>> > Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>> > Configuration.
>>> > Allow dynamic reconfiguration.
>>> > Allow plugins (probably as Go plugins?)
>>> > Support for Markers, context attributes, Layouts, Appenders.
>>> >
>>> > Anyone interested?
>>> >
>>> > Ralph
>>> >
>>> >
Re: Log4Go
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <da...@gmail.com> 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 <cd...@apache.org> 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 like Apache Logging and not as a side project of PLC4X.
>>
>> Chris
>>
>>
>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>> I support the initiative. At bol.com, we also needed to implement our own
>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>> and I don't think I will be able to spare time to both learn a new language
>>> (even though I am really into learning Go) and maintain such a project. I
>>> mean, not that you need my help, but just wanted to share my availability.
>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>> I also agree with Matt that this would pave the road to standardizing the
>>> logging configuration file formats across multiple languages.
>>> What I witness most for code — in particular libraries, APIs, etc. —
>>> written by programmers whose expertise is actually in another language,
>>> that they mostly don't get the language conventions right. For instance, I
>>> was horrified many times in the past to read/use Java code written by
>>> JavaScript (front-end) developers. These two languages have totally
>>> different approaches and (community embraced) conventions that one cannot
>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>> recommend consulting to experts in this domain before publishing something
>>> to the outside world. For one, I am pretty sure there should be Go experts
>>> within the Apache community, hence having expert reviews should be
>>> relatively easy. Second, Apache has such a good track record in delivering
>>> high quality software, even an inferior project might get quite some
>>> attraction and we will be bound to maintain it for years. These are my
>>> concerns in general. That said, I would be more than happy to ditch off our
>>> custom Go loggers with an Apache-approved alternative.
>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>> > The company I work for has started using Go for some of the middleware
>>> > components we are developing. I have looked at several logging frameworks
>>> > for Go and have not been impressed by any of them. As such, I am
>>> > considering starting a project here. The major goals of this would be:
>>> >
>>> > Use an external configuration (at least JSON and XML).
>>> > Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>> > Configuration.
>>> > Allow dynamic reconfiguration.
>>> > Allow plugins (probably as Go plugins?)
>>> > Support for Markers, context attributes, Layouts, Appenders.
>>> >
>>> > Anyone interested?
>>> >
>>> > Ralph
>>> >
>>> >
Re: Re: Log4Go
Posted by Davyd McColl <da...@gmail.com>.
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 <cd...@apache.org> 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 like Apache Logging and not as
> a side project of PLC4X.
>
> Chris
>
>
> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>> I support the initiative. At bol.com, we also needed to implement our own
>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>> and I don't think I will be able to spare time to both learn a new language
>> (even though I am really into learning Go) and maintain such a project. I
>> mean, not that you need my help, but just wanted to share my availability.
>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>
>> I also agree with Matt that this would pave the road to standardizing the
>> logging configuration file formats across multiple languages.
>>
>> What I witness most for code — in particular libraries, APIs, etc. —
>> written by programmers whose expertise is actually in another language,
>> that they mostly don't get the language conventions right. For instance, I
>> was horrified many times in the past to read/use Java code written by
>> JavaScript (front-end) developers. These two languages have totally
>> different approaches and (community embraced) conventions that one cannot
>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>> none of us is programming in Go on a daily basis. Hence, I strongly
>> recommend consulting to experts in this domain before publishing something
>> to the outside world. For one, I am pretty sure there should be Go experts
>> within the Apache community, hence having expert reviews should be
>> relatively easy. Second, Apache has such a good track record in delivering
>> high quality software, even an inferior project might get quite some
>> attraction and we will be bound to maintain it for years. These are my
>> concerns in general. That said, I would be more than happy to ditch off our
>> custom Go loggers with an Apache-approved alternative.
>>
>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> > The company I work for has started using Go for some of the middleware
>> > components we are developing. I have looked at several logging frameworks
>> > for Go and have not been impressed by any of them. As such, I am
>> > considering starting a project here. The major goals of this would be:
>> >
>> > Use an external configuration (at least JSON and XML).
>> > Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>> > Configuration.
>> > Allow dynamic reconfiguration.
>> > Allow plugins (probably as Go plugins?)
>> > Support for Markers, context attributes, Layouts, Appenders.
>> >
>> > Anyone interested?
>> >
>> > Ralph
>> >
>> >
>>
Re: Log4Go
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes, I understand what you are asking for. From what I can see that would involve
creating our Log4Go (wish we could use that name) to emulate Log4j as much as
possible and then creating separate Appender projects to pass events to logrus,
zerolog, etc. Typically, I would expect those frameworks to have their logging set
to TRACE so that Log4Go would completely control the filtering, but I suppose it
is possible that a Filter could be configured on the bridge appender that really just
configured the logging backend.
However, that isn’t typically the use case we find in Java. Usually, folks want the
logging frameworks that their dependencies use to somehow have their log events
routed into Log4j for processing. Then it is as if everything is using Log4j. I have my
doubts that this is possible in Go because the existing logging frameworks typically
don’t allow you to add your own appenders, etc to them.
Ralph
> On Jul 1, 2021, at 12:18 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Ralph and others,
>
> right now the thing that annoys me most is that for example in PLC4Go we
> used zerolog ... in an application at work we used logrus. Now I needed
> to setup a configuration to sync the config of zerolog with that of
> logrus. This is just annoying. With my proposed log4go API, I would
> instead use log4go in PLC4X. In this case in my application I could
> simply configure log4go to use the logrus backend for logging and we
> would forward the log commands to logrus.
>
> For me that and the option to intercept log commands with a
> configuration hierarchy is the key feature. So if in my above example we
> set logrus to "INFO", then we couldn't log anything less severe than
> INFO, but if it's set to TRACE we could define which parts of my
> application are set to any severity. So my PLC4X Modbus-Driver could be
> set to WARN and my KNX Driver is set to TRACE and log4go simply filters
> out the INFO, DEBUG and TRACE calls in the Modbus driver.
>
> Hope that explains a bit more, what I'm proposing.
>
> Chris
>
>
>
>
> On 30.06.21 23:45, Ralph Goers wrote:
>> Well, I am on board with part of what you want.
>>
>> When I looked at various Go logging libraries most of them defined where the logs
>> ere going and how they are formatted at build time. 90% of what Log4j does is figure
>> out all of that at run time. Go is not nearly as dynamic as Java because the application
>> is constructed completely at build time. You can’t just add libraries and have the
>> behavior change without rebuilding.
>>
>> However, it is still possible to include all the things you want your application to be
>> able to choose from and then bind to a specific component via configuration. So it
>> should still be possible to implement much of the flexibility that Log4j provides.
>>
>> One problem I did notice though is that there are several popular logging libraries.
>> Due to the nature of Go it isn’t really possible to replace them with a bridge to the
>> logging framework you really want to use. To be honest, I have no idea how Go
>> applications deal with having dependencies that all use different logging libraries.
>>
>> Ralph
>>
>>
>>> On Jun 30, 2021, at 9:12 AM, Christofer Dutz <cd...@apache.org> 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 like Apache Logging and not as a side project of PLC4X.
>>>
>>> Chris
>>>
>>>
>>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>>> I support the initiative. At bol.com, we also needed to implement our own
>>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>>> and I don't think I will be able to spare time to both learn a new language
>>>> (even though I am really into learning Go) and maintain such a project. I
>>>> mean, not that you need my help, but just wanted to share my availability.
>>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>>>
>>>> I also agree with Matt that this would pave the road to standardizing the
>>>> logging configuration file formats across multiple languages.
>>>>
>>>> What I witness most for code — in particular libraries, APIs, etc. —
>>>> written by programmers whose expertise is actually in another language,
>>>> that they mostly don't get the language conventions right. For instance, I
>>>> was horrified many times in the past to read/use Java code written by
>>>> JavaScript (front-end) developers. These two languages have totally
>>>> different approaches and (community embraced) conventions that one cannot
>>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>>> recommend consulting to experts in this domain before publishing something
>>>> to the outside world. For one, I am pretty sure there should be Go experts
>>>> within the Apache community, hence having expert reviews should be
>>>> relatively easy. Second, Apache has such a good track record in delivering
>>>> high quality software, even an inferior project might get quite some
>>>> attraction and we will be bound to maintain it for years. These are my
>>>> concerns in general. That said, I would be more than happy to ditch off our
>>>> custom Go loggers with an Apache-approved alternative.
>>>>
>>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> The company I work for has started using Go for some of the middleware
>>>>> components we are developing. I have looked at several logging frameworks
>>>>> for Go and have not been impressed by any of them. As such, I am
>>>>> considering starting a project here. The major goals of this would be:
>>>>>
>>>>> Use an external configuration (at least JSON and XML).
>>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>>>> Configuration.
>>>>> Allow dynamic reconfiguration.
>>>>> Allow plugins (probably as Go plugins?)
>>>>> Support for Markers, context attributes, Layouts, Appenders.
>>>>>
>>>>> Anyone interested?
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>
>>>
>>
>>
Re: Log4Go
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Ralph and others,
right now the thing that annoys me most is that for example in PLC4Go we
used zerolog ... in an application at work we used logrus. Now I needed
to setup a configuration to sync the config of zerolog with that of
logrus. This is just annoying. With my proposed log4go API, I would
instead use log4go in PLC4X. In this case in my application I could
simply configure log4go to use the logrus backend for logging and we
would forward the log commands to logrus.
For me that and the option to intercept log commands with a
configuration hierarchy is the key feature. So if in my above example we
set logrus to "INFO", then we couldn't log anything less severe than
INFO, but if it's set to TRACE we could define which parts of my
application are set to any severity. So my PLC4X Modbus-Driver could be
set to WARN and my KNX Driver is set to TRACE and log4go simply filters
out the INFO, DEBUG and TRACE calls in the Modbus driver.
Hope that explains a bit more, what I'm proposing.
Chris
On 30.06.21 23:45, Ralph Goers wrote:
> Well, I am on board with part of what you want.
>
> When I looked at various Go logging libraries most of them defined where the logs
> ere going and how they are formatted at build time. 90% of what Log4j does is figure
> out all of that at run time. Go is not nearly as dynamic as Java because the application
> is constructed completely at build time. You can’t just add libraries and have the
> behavior change without rebuilding.
>
> However, it is still possible to include all the things you want your application to be
> able to choose from and then bind to a specific component via configuration. So it
> should still be possible to implement much of the flexibility that Log4j provides.
>
> One problem I did notice though is that there are several popular logging libraries.
> Due to the nature of Go it isn’t really possible to replace them with a bridge to the
> logging framework you really want to use. To be honest, I have no idea how Go
> applications deal with having dependencies that all use different logging libraries.
>
> Ralph
>
>
>> On Jun 30, 2021, at 9:12 AM, Christofer Dutz <cd...@apache.org> 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 like Apache Logging and not as a side project of PLC4X.
>>
>> Chris
>>
>>
>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>> I support the initiative. At bol.com, we also needed to implement our own
>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>> and I don't think I will be able to spare time to both learn a new language
>>> (even though I am really into learning Go) and maintain such a project. I
>>> mean, not that you need my help, but just wanted to share my availability.
>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>>
>>> I also agree with Matt that this would pave the road to standardizing the
>>> logging configuration file formats across multiple languages.
>>>
>>> What I witness most for code — in particular libraries, APIs, etc. —
>>> written by programmers whose expertise is actually in another language,
>>> that they mostly don't get the language conventions right. For instance, I
>>> was horrified many times in the past to read/use Java code written by
>>> JavaScript (front-end) developers. These two languages have totally
>>> different approaches and (community embraced) conventions that one cannot
>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>> recommend consulting to experts in this domain before publishing something
>>> to the outside world. For one, I am pretty sure there should be Go experts
>>> within the Apache community, hence having expert reviews should be
>>> relatively easy. Second, Apache has such a good track record in delivering
>>> high quality software, even an inferior project might get quite some
>>> attraction and we will be bound to maintain it for years. These are my
>>> concerns in general. That said, I would be more than happy to ditch off our
>>> custom Go loggers with an Apache-approved alternative.
>>>
>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> The company I work for has started using Go for some of the middleware
>>>> components we are developing. I have looked at several logging frameworks
>>>> for Go and have not been impressed by any of them. As such, I am
>>>> considering starting a project here. The major goals of this would be:
>>>>
>>>> Use an external configuration (at least JSON and XML).
>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>>> Configuration.
>>>> Allow dynamic reconfiguration.
>>>> Allow plugins (probably as Go plugins?)
>>>> Support for Markers, context attributes, Layouts, Appenders.
>>>>
>>>> Anyone interested?
>>>>
>>>> Ralph
>>>>
>>>>
>>>
>>
>
>
Re: Log4Go
Posted by Ralph Goers <ra...@dslextreme.com>.
Well, I am on board with part of what you want.
When I looked at various Go logging libraries most of them defined where the logs
ere going and how they are formatted at build time. 90% of what Log4j does is figure
out all of that at run time. Go is not nearly as dynamic as Java because the application
is constructed completely at build time. You can’t just add libraries and have the
behavior change without rebuilding.
However, it is still possible to include all the things you want your application to be
able to choose from and then bind to a specific component via configuration. So it
should still be possible to implement much of the flexibility that Log4j provides.
One problem I did notice though is that there are several popular logging libraries.
Due to the nature of Go it isn’t really possible to replace them with a bridge to the
logging framework you really want to use. To be honest, I have no idea how Go
applications deal with having dependencies that all use different logging libraries.
Ralph
> On Jun 30, 2021, at 9:12 AM, Christofer Dutz <cd...@apache.org> 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 like Apache Logging and not as a side project of PLC4X.
>
> Chris
>
>
> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>> I support the initiative. At bol.com, we also needed to implement our own
>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>> and I don't think I will be able to spare time to both learn a new language
>> (even though I am really into learning Go) and maintain such a project. I
>> mean, not that you need my help, but just wanted to share my availability.
>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>
>> I also agree with Matt that this would pave the road to standardizing the
>> logging configuration file formats across multiple languages.
>>
>> What I witness most for code — in particular libraries, APIs, etc. —
>> written by programmers whose expertise is actually in another language,
>> that they mostly don't get the language conventions right. For instance, I
>> was horrified many times in the past to read/use Java code written by
>> JavaScript (front-end) developers. These two languages have totally
>> different approaches and (community embraced) conventions that one cannot
>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>> none of us is programming in Go on a daily basis. Hence, I strongly
>> recommend consulting to experts in this domain before publishing something
>> to the outside world. For one, I am pretty sure there should be Go experts
>> within the Apache community, hence having expert reviews should be
>> relatively easy. Second, Apache has such a good track record in delivering
>> high quality software, even an inferior project might get quite some
>> attraction and we will be bound to maintain it for years. These are my
>> concerns in general. That said, I would be more than happy to ditch off our
>> custom Go loggers with an Apache-approved alternative.
>>
>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> The company I work for has started using Go for some of the middleware
>>> components we are developing. I have looked at several logging frameworks
>>> for Go and have not been impressed by any of them. As such, I am
>>> considering starting a project here. The major goals of this would be:
>>>
>>> Use an external configuration (at least JSON and XML).
>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
>>> Configuration.
>>> Allow dynamic reconfiguration.
>>> Allow plugins (probably as Go plugins?)
>>> Support for Markers, context attributes, Layouts, Appenders.
>>>
>>> Anyone interested?
>>>
>>> Ralph
>>>
>>>
>>
>
Re: Re: Log4Go
Posted by Christofer Dutz <cd...@apache.org>.
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 like Apache Logging and not as a side project of PLC4X.
Chris
On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
> I support the initiative. At bol.com, we also needed to implement our own
> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
> and I don't think I will be able to spare time to both learn a new language
> (even though I am really into learning Go) and maintain such a project. I
> mean, not that you need my help, but just wanted to share my availability.
> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>
> I also agree with Matt that this would pave the road to standardizing the
> logging configuration file formats across multiple languages.
>
> What I witness most for code — in particular libraries, APIs, etc. —
> written by programmers whose expertise is actually in another language,
> that they mostly don't get the language conventions right. For instance, I
> was horrified many times in the past to read/use Java code written by
> JavaScript (front-end) developers. These two languages have totally
> different approaches and (community embraced) conventions that one cannot
> plug-n-play the mindset of one to another. In conclusion, as far as I know,
> none of us is programming in Go on a daily basis. Hence, I strongly
> recommend consulting to experts in this domain before publishing something
> to the outside world. For one, I am pretty sure there should be Go experts
> within the Apache community, hence having expert reviews should be
> relatively easy. Second, Apache has such a good track record in delivering
> high quality software, even an inferior project might get quite some
> attraction and we will be bound to maintain it for years. These are my
> concerns in general. That said, I would be more than happy to ditch off our
> custom Go loggers with an Apache-approved alternative.
>
> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > The company I work for has started using Go for some of the middleware
> > components we are developing. I have looked at several logging frameworks
> > for Go and have not been impressed by any of them. As such, I am
> > considering starting a project here. The major goals of this would be:
> >
> > Use an external configuration (at least JSON and XML).
> > Allow the configuration to be accessed via HTTP(S) - Spring Cloud
> > Configuration.
> > Allow dynamic reconfiguration.
> > Allow plugins (probably as Go plugins?)
> > Support for Markers, context attributes, Layouts, Appenders.
> >
> > Anyone interested?
> >
> > Ralph
> >
> >
>
Re: Log4Go
Posted by Volkan Yazıcı <vo...@gmail.com>.
I support the initiative. At bol.com, we also needed to implement our own
Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
and I don't think I will be able to spare time to both learn a new language
(even though I am really into learning Go) and maintain such a project. I
mean, not that you need my help, but just wanted to share my availability.
If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
I also agree with Matt that this would pave the road to standardizing the
logging configuration file formats across multiple languages.
What I witness most for code — in particular libraries, APIs, etc. —
written by programmers whose expertise is actually in another language,
that they mostly don't get the language conventions right. For instance, I
was horrified many times in the past to read/use Java code written by
JavaScript (front-end) developers. These two languages have totally
different approaches and (community embraced) conventions that one cannot
plug-n-play the mindset of one to another. In conclusion, as far as I know,
none of us is programming in Go on a daily basis. Hence, I strongly
recommend consulting to experts in this domain before publishing something
to the outside world. For one, I am pretty sure there should be Go experts
within the Apache community, hence having expert reviews should be
relatively easy. Second, Apache has such a good track record in delivering
high quality software, even an inferior project might get quite some
attraction and we will be bound to maintain it for years. These are my
concerns in general. That said, I would be more than happy to ditch off our
custom Go loggers with an Apache-approved alternative.
On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> The company I work for has started using Go for some of the middleware
> components we are developing. I have looked at several logging frameworks
> for Go and have not been impressed by any of them. As such, I am
> considering starting a project here. The major goals of this would be:
>
> Use an external configuration (at least JSON and XML).
> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
> Configuration.
> Allow dynamic reconfiguration.
> Allow plugins (probably as Go plugins?)
> Support for Markers, context attributes, Layouts, Appenders.
>
> Anyone interested?
>
> Ralph
>
>