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
smime.p7s
Description: S/MIME cryptographic signature
