You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2022/09/23 21:01:20 UTC
Logging, uff-da
Not a problem for today, but I'm once again reminded how badly I want to toss out all of our logging abstraction.
Out Logger class started way back in 1999 before even Log4j existed. When good-looking frameworks came into the picture, we kept using ours. That bit is as our code for logging has grown in complexity and IMO has grown into something that's way too complicated and has bugs/issues swimming around in it.
One gripe is that since we added "async" logging, literally all log statements appear to come from the same class and method "org.apache.openejb.util.LogStreamAsync run". For example:
Sep 23, 2022 1:24:30 PM org.apache.openejb.util.LogStreamAsync run
SEVERE: Initialization attempt 1 failed. Supplier org.apache.openejb.util.CachedSupplierTest$$Lambda$160/0x0000000800d3dc50@7f96b8b9 threw an exception. Next retry will be in 1000 MILLISECONDS
Another is the plethora of bugs. For example if you create a Logger instance like so:
- Logger.getInstance(LogCategory.OPENEJB, CachedSupplier.class.getSimpleName())
...you will get an IndexOutOfBoundsException on each attempt to use the logger. I found and fixed that, but the ironic part is that the code with the bug was trying to create a logging category and well... because of the "feature" above it's ignored anyway.
I don't think we want to dive into this in TomEE 9, but TomEE 10 would be a good target.
I'm not sure why people are not screaming about our logging.
What's your opinion?
- "All that code is great and we really need it"
- "I have no idea what all that code does and I'm happy when I don't have to look at it"
-David
Re: Logging, uff-da
Posted by David Blevins <db...@tomitribe.com>.
> On Sep 28, 2022, at 11:45 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>
> However, I agree with JL, that we are really close to passing the TCK again, which would allow to cut a sweet & nice 9.0.0 Final before moving on to EE10 work :)
Agreed.
> On Sep 23, 2022, at 4:01 PM, David Blevins <da...@gmail.com> wrote:
>
> I don't think we want to dive into this in TomEE 9, but TomEE 10 would be a good target.
-David
Re: Logging, uff-da
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
I think, that we are an app server first and not a logging framework
(;-)), so I am fine with
"I have no idea what all that code does and I'm happy when I don't have to look at it".
However, I agree with JL, that we are really close to passing the TCK again, which would allow to cut a sweet & nice 9.0.0 Final before moving on to EE10 work :)
Gruß
Richard
Am Sonntag, dem 25.09.2022 um 11:19 +0200 schrieb Jean-Louis Monteiro:
> The code is way too complex. I agree.
>
> Abstraction is fine especially in Tomcat with the logging system and
> the
> class loading management to load configuration. If we want to be
> Tomcat we
> need to be able to support the same logging system in my opinion.
>
> Now it can probably be done using either an existing abstraction like
> slf4j
> or log back or whatever. Or have something really simple.
>
> TomEE 10 is a good target. We are too close to touch something like
> out
> logging system
>
> Le ven. 23 sept. 2022, 23:01, David Blevins <da...@gmail.com>
> a
> écrit :
>
> > Not a problem for today, but I'm once again reminded how badly I
> > want to
> > toss out all of our logging abstraction.
> >
> > Out Logger class started way back in 1999 before even Log4j
> > existed. When
> > good-looking frameworks came into the picture, we kept using ours.
> > That
> > bit is as our code for logging has grown in complexity and IMO has
> > grown
> > into something that's way too complicated and has bugs/issues
> > swimming
> > around in it.
> >
> > One gripe is that since we added "async" logging, literally all log
> > statements appear to come from the same class and method
> > "org.apache.openejb.util.LogStreamAsync run". For example:
> >
> > Sep 23, 2022 1:24:30 PM org.apache.openejb.util.LogStreamAsync
> > run
> > SEVERE: Initialization attempt 1 failed. Supplier
> > org.apache.openejb.util.CachedSupplierTest$$Lambda$160/0x0000000800d3dc50@7f96b8b9
> > threw an exception. Next retry will be in 1000 MILLISECONDS
> >
> > Another is the plethora of bugs. For example if you create a
> > Logger
> > instance like so:
> >
> > - Logger.getInstance(LogCategory.OPENEJB,
> > CachedSupplier.class.getSimpleName())
> >
> > ...you will get an IndexOutOfBoundsException on each attempt to use
> > the
> > logger. I found and fixed that, but the ironic part is that the
> > code with
> > the bug was trying to create a logging category and well... because
> > of the
> > "feature" above it's ignored anyway.
> >
> > I don't think we want to dive into this in TomEE 9, but TomEE 10
> > would be
> > a good target.
> >
> > I'm not sure why people are not screaming about our logging.
> >
> > What's your opinion?
> >
> > - "All that code is great and we really need it"
> > - "I have no idea what all that code does and I'm happy when I
> > don't have
> > to look at it"
> >
> >
> > -David
> >
> >
Re: Logging, uff-da
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
The code is way too complex. I agree.
Abstraction is fine especially in Tomcat with the logging system and the
class loading management to load configuration. If we want to be Tomcat we
need to be able to support the same logging system in my opinion.
Now it can probably be done using either an existing abstraction like slf4j
or log back or whatever. Or have something really simple.
TomEE 10 is a good target. We are too close to touch something like out
logging system
Le ven. 23 sept. 2022, 23:01, David Blevins <da...@gmail.com> a
écrit :
> Not a problem for today, but I'm once again reminded how badly I want to
> toss out all of our logging abstraction.
>
> Out Logger class started way back in 1999 before even Log4j existed. When
> good-looking frameworks came into the picture, we kept using ours. That
> bit is as our code for logging has grown in complexity and IMO has grown
> into something that's way too complicated and has bugs/issues swimming
> around in it.
>
> One gripe is that since we added "async" logging, literally all log
> statements appear to come from the same class and method
> "org.apache.openejb.util.LogStreamAsync run". For example:
>
> Sep 23, 2022 1:24:30 PM org.apache.openejb.util.LogStreamAsync run
> SEVERE: Initialization attempt 1 failed. Supplier
> org.apache.openejb.util.CachedSupplierTest$$Lambda$160/0x0000000800d3dc50@7f96b8b9
> threw an exception. Next retry will be in 1000 MILLISECONDS
>
> Another is the plethora of bugs. For example if you create a Logger
> instance like so:
>
> - Logger.getInstance(LogCategory.OPENEJB,
> CachedSupplier.class.getSimpleName())
>
> ...you will get an IndexOutOfBoundsException on each attempt to use the
> logger. I found and fixed that, but the ironic part is that the code with
> the bug was trying to create a logging category and well... because of the
> "feature" above it's ignored anyway.
>
> I don't think we want to dive into this in TomEE 9, but TomEE 10 would be
> a good target.
>
> I'm not sure why people are not screaming about our logging.
>
> What's your opinion?
>
> - "All that code is great and we really need it"
> - "I have no idea what all that code does and I'm happy when I don't have
> to look at it"
>
>
> -David
>
>