Re: [Chainsaw] Removal of Log4j1

[Robert Middleton]

I've finished removing log4j1 from Chainsaw.  If anybody would like to take
a look, it is in a PR here:
https://github.com/apache/logging-chainsaw/pull/11

The next steps probably are:
* Make sure dependencies are up to date
* Create a better way of documenting how receivers work other than just
throwing javadoc at the user
* Create a full tutorial and documentation for chainsaw, since the
documentation is pretty non-existent now
* Integrate with the Advertisers that log4j2 has so you can easily connect
to an application using log4j2
* Look at JDeploy that Matt linked to and determine if that would be a good
way to distribute chainsaw

-Robert Middleton

On Mon, Jan 17, 2022 at 2:02 PM Robert Middleton 
wrote:

> Thanks for the input.  In that case I will certainly make sure that we
> do keep the VFSLogFilePatternReceiver.
>
> One thing that would be helpful if you have time Scott would be a
> manual on how to use Chainsaw and the features that it has.  I
> understand it enough now, but for people first trying to use it there
> isn't really any good documentation.
>
> -Robert Middleton
>
> On Mon, Jan 17, 2022 at 1:17 AM Scott Deboy  wrote:
> >
> > Looks great!
> >
> > It's a lot of work for sure - lots more to do to fully remove log4j1 -
> > custom level support (java.util.logging and Android for example),
> > support for UI-based interactions for some receivers(activateOptions),
> > and the loggerRepository extension pieces.
> >
> > I definitely want to see VFSLogFilePatternReceiver preserved of course
> > - it's turned out to be a very useful Receiver (parse mostly-arbitrary
> > log formats, even remote/ssh).
> >
> > Happy to help I just never have much time.
> >
> > Scott
> >
> >
> >
> > On 1/16/22, Robert Middleton  wrote:
> > > I've been working on this for a little bit now, and I do have
> > > something that mostly seems to work.  This has been made somewhat more
> > > difficult by the very tight coupling that Chainsaw has with log4j1 and
> > > its plugin framework.  At this point, I've done the following:
> > >
> > > * Remove dependency on log4j1-extras
> > > * Add in log4j2 dependencies for logging
> > > * Create a generic Chainsaw log event that is used to pass log events
> > > around internally
> > > * Rework the receivers framework to use ServiceLoader instead of some
> > > home-grown system
> > >
> > > If people are willing to take a look at what I've done so far, the
> > > (very rough still) branch is here:
> > > https://github.com/rm5248/logging-chainsaw/tree/remove-log4j1
> > >
> > > There are still a number of bugs in it still, since there's  a fair
> > > amount of invasive surgery.  If you want to test, you'll need to do
> > > the following:
> > > 1. Remove your ~/.chainsaw directory(this may or may not be needed; it
> > > doesn't seem to like to load old settings at the moment)
> > > 2. Start chainsaw
> > > 3. Open the 'receivers' panel(icon that looks like a satellite dish)
> > > 4. Create  a new JSON receiver.  There's only one option, so you can
> click
> > > 'ok'
> > > 5. Run log4j2 with a configuration file similar to the following:
> > >
> > > ?xml version="1.0" encoding="UTF-8"?>
> > > 
> > >   
> > > 
> > >   
> > > 
> > > 
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   
> > > 
> > >
> > > You should then see log messages showing up in a new tab.
> > >
> > > -Robert Middleton
> > >
> > > On Tue, Dec 28, 2021 at 6:32 AM Volkan Yazıcı  wrote:
> > >>
> > >> +1 for implementation-agnostic custom DTO tailored for Chainsaw.
> > >>
> > >> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker  wrote:
> > >>
> > >> > I agree on the generic approach. While there’s a LogEvent interface
> in
> > >> > log4j2, it would probably make sense for Chainsaw to define its own
> > >> > DTOs
> > >> > and such.
> > >> > --
> > >> > Matt Sicker
> > >> >
> > >> > > On Dec 26, 2021, at 15:50, Ralph Goers <
> ralph.go...@dslextreme.com>
> > >> > wrote:
> > >> > >
> > >> > > Scott has been sort of maintaining Chainsaw on his own for years.
> I
> > >> > > am
> > >> > sure he would love new energy in the project.
> > >> > >
> > >> > > I think isolating it from any logging framework implementation
> would
> > >> > > be
> > >> > a good thing.
> > >> > >
> > >> > > Ralph
> > >> > >
> > >> > >> On Dec 26, 2021, at 2:13 PM, Robert Middleton
> > >> > >> 
> > >> > wrote:
> > >> > >>
> > >> > >> I've been looking into Chainsaw to remove Log4j1, since that is
> > >> > >> rather
> > >> > >> obsolete at this point.  Unfortunately, Chainsaw is closely tied
> to
> > >> > >> Log4j1, as it seems that what happens is when it receives events
> > >> > >> from
> > >> > >> a source, it sends the messages to a custom LoggerRepository
> with a
> > >> > >> custom appender that will then show the log messages.
> > >> > >>
> > >> > >> There are also a handful of classes from the log4j1 extras
> package
> > >> > >> that are used as well, such as Rule.
> > >> > >>
> > >> > >> It 

Re: Release 2.17.2

[Gary Gregory]

Here is another know broken feature in the 1.2 bridge, the
getAllAppenders() API often (always?) returns an empty Enumeration. The
guts of the class that implements the API is probably completely wrong in
the context of a bridge, it should probably find all the appended wrappers
and return those instead of trying to emulate what 1.2.17 does but I am not
100% sure.

Gary

On Mon, Feb 21, 2022, 15:29 Piotr P. Karwasz 
wrote:

> Hi,
>
> On Mon, Feb 21, 2022 at 3:01 PM Gary Gregory 
> wrote:
> >
> > Note that I recently added DOMTestCase to the 1.2 bridge from the 1.2.17
> > code base; this contains disabled tests for some non-trivial
> > configurations. I would appreciate extra eyes to debug these.
>
> I can look into the CategoryFactory feature, but I think it is not
> worth delaying the 2.17.2 release.
>
> On the other hand a feature that might be nice to have in the Log4j
> 1.x bridge is the support of the `reset` attribute. Since the system
> property `log4j.configuration` didn't support multiple values, users
> must have resorted to multiple calls to DOMConfigurator.configure.
>
> Piotr
>

Re: Release 2.17.2

[Piotr P. Karwasz]

Hi,

On Mon, Feb 21, 2022 at 3:01 PM Gary Gregory  wrote:
>
> Note that I recently added DOMTestCase to the 1.2 bridge from the 1.2.17
> code base; this contains disabled tests for some non-trivial
> configurations. I would appreciate extra eyes to debug these.

I can look into the CategoryFactory feature, but I think it is not
worth delaying the 2.17.2 release.

On the other hand a feature that might be nice to have in the Log4j
1.x bridge is the support of the `reset` attribute. Since the system
property `log4j.configuration` didn't support multiple values, users
must have resorted to multiple calls to DOMConfigurator.configure.

Piotr

Re: log4net - performance hit because UserName is fetched always

[Davyd McColl]

Hi Denis

Thanks for the report (:
I'm happy to review contributions, though for this particular issue, it seems 
like the resolution is to cache the resolved user name, rather than allowing 
specifying the name via config. The whole point of this property is to log the 
username under which the process is run (: The username for a process isn't 
going to change (at least, I'm not aware of a process for doing so), so it 
feels like the correct approach is simply to cache. Please feel free to raise a 
PR at github. I recognise that I'm not the fastest responder - there's just one 
of me and it seems like there's always something vying for my attention - but I 
do try to respond to pull requests as quickly as possible.
I have another fix in the works for xml layouts anyway, though I was pursuing 
that with respect to another reported issue, but I could let that issue go for 
now for a hastier release.
-d
On Feb 21 2022, at 7:22 pm, Denis Petker  wrote:
>
> Hi all,
>
> we have upgraded the log4net version from 1.2.10 to the newest version 2.0.14 
> and are now facing performace issues. I already have done some investigation 
> looking at the log4net code.
> With the ticket LOG4NET-205 
> (https://issues.apache.org/jira/browse/LOG4NET-205) a change has been 
> introduced, which makes log4net not acceptable for us in terms of 
> performance. (Commit 5c023f6a22bfb93873a5ce0d6f5ac7e7275e2914) The change has 
> been done in order to be able to use UserName and Identity in the 
> PropertyFilter. It adds 'internal' properties representing the UserName and 
> Identity to the m_compositeProperties so that they are now accessible in the 
> PropertyFilter. That works as intended so far. See the attached diff 
> illustrating the change.
>
> The problem is, that fetching the UserName from the system is pretty 
> expensive. With the change above UserName is fetched always, regardless of 
> whether we use UserName or not. I did some benchmarking and this change 
> slowed down logging by a factor of 60. I also don’t see any way to get around 
> this by changing the configuration. I believe this can only be fixed by 
> changing code.
>
> I would suggest, rather than adding 'internal' properties to 
> m_compositeProperties, we should make the function 
> LoggingEvent.LookupProperty to look after the native properties, when 
> corresponding keys are specified. E.g. when the key "UserName" is specified, 
> we could return the value of the property LoggingEvent.UserName etc.
>
> In the meantime we want to use a changed version of log4net for our purposes. 
> I wonder, whether this change could be integrated into the official version? 
> I’ve never contributed to a public github project before, so don’t know how 
> to proceed really.
>
> Thanks,
> Denis
>
>
> This is the historic change causing the problem.
>
>
> --
> Denis Petker
> Next Generation Solutions | 8BM3
>
>
>
> Rohde & Schwarz GmbH & Co. KG
> Hanomaghof 1 | 30449 Hanover
> Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200
> Internet: www.rohde-schwarz.com (http://www.rohde-schwarz.com/)
>
> 
> Geschäftsführung / Executive Board: Christian Leicher (Vorsitzender / 
> Chairman), Peter Riedel, Sitz der Gesellschaft / Company's Place of Business: 
> München, Registereintrag / Commercial Register No.: HRA 16 270, Persönlich 
> haftender Gesellschafter / Personally Liable Partner: RUSEG Verwaltungs-GmbH, 
> Sitz der Gesellschaft / Company's Place of Business: München, Registereintrag 
> / Commercial Register No.: HRB 7 534, Umsatzsteuer-Identifikationsnummer 
> (USt-IdNr.) / VAT Identification No.: DE 130 256 683, Elektro-Altgeräte 
> Register (EAR) / WEEE Register No.: DE 240 437 86
>
>

log4net - performance hit because UserName is fetched always

[Denis Petker]

Hi all,
we have upgraded the log4net version from 1.2.10 to the newest version 2.0.14 
and are now facing performace issues. I already have done some investigation 
looking at the log4net code.

With the ticket LOG4NET-205 
a change has been introduced, which makes log4net not acceptable for us in 
terms of performance. (Commit 5c023f6a22bfb93873a5ce0d6f5ac7e7275e2914) The 
change has been done in order to be able to use UserName and Identity in the 
PropertyFilter. It adds 'internal' properties representing the UserName and 
Identity to the m_compositeProperties so that they are now accessible in the 
PropertyFilter. That works as intended so far. See the attached diff 
illustrating the change.



The problem is, that fetching the UserName from the system is pretty expensive. 
With the change above UserName is fetched always, regardless of whether we use 
UserName or not. I did some benchmarking and this change slowed down logging by 
a factor of 60. I also don’t see any way to get around this by changing the 
configuration. I believe this can only be fixed by changing code.



I would suggest, rather than adding 'internal' properties to 
m_compositeProperties, we should make the function LoggingEvent.LookupProperty 
to look after the native properties, when corresponding keys are specified. 
E.g. when the key "UserName" is specified, we could return the value of the 
property LoggingEvent.UserName etc.



In the meantime we want to use a changed version of log4net for our purposes. I 
wonder, whether this change could be integrated into the official version? I’ve 
never contributed to a public github project before, so don’t know how to 
proceed really.



Thanks,

Denis


This is the historic change causing the problem.
[cid:image001.png@01D8274E.AA9B33A0]
--
Denis Petker
Next Generation Solutions | 8BM3

Rohde & Schwarz GmbH & Co. KG
Hanomaghof 1 | 30449 Hanover
Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200
Internet: www.rohde-schwarz.com


Geschäftsführung / Executive Board: Christian Leicher (Vorsitzender / 
Chairman), Peter Riedel, Sitz der Gesellschaft / Company's Place of Business: 
München, Registereintrag / Commercial Register No.: HRA 16 270, Persönlich 
haftender Gesellschafter / Personally Liable Partner: RUSEG Verwaltungs-GmbH, 
Sitz der Gesellschaft / Company's Place of Business: München, Registereintrag / 
Commercial Register No.: HRB 7 534, Umsatzsteuer-Identifikationsnummer 
(USt-IdNr.) / VAT Identification No.: DE 130 256 683, Elektro-Altgeräte 
Register (EAR) / WEEE Register No.: DE 240 437 86

Re: Release 2.17.2

[Gary Gregory]

Note that I recently added DOMTestCase to the 1.2 bridge from the 1.2.17
code base; this contains disabled tests for some non-trivial
configurations. I would appreciate extra eyes to debug these.

Gary

On Fri, Feb 18, 2022, 07:00 Gary Gregory  wrote:

> I took a brief look earlier this week, it's a large PR, so I plan on
> looking carefully Saturday.
>
> Gary
>
> On Fri, Feb 18, 2022, 01:07 Ralph Goers 
> wrote:
>
>> I have finished the initiatives I had wanted to complete for this release
>> and am now going through the list of open issues and PRs. I am hopeful that
>> I can complete that in the next couple of days.
>>
>> So I am targeting running the release build on Sunday sometime.
>> https://github.com/apache/logging-log4j2/pull/753 looks to me like it is
>> important to make in the release so it would be nice if some of us could
>> look at it.
>>
>> Ralph
>
>