Closed SentryMan closed 2 days ago
I'm pondering ... because to some extent AppLog is better that System.Logger as we can "default" it to slf4j rather than JUL ... and on the other hand we could just go with slfj4 now that it's got module-info support etc. Hmmm.
we could just go with slfj4 now
I'm trying to remove dependencies, not add bigger ones
I'm trying to remove dependencies, not add bigger ones
What logging backends do you actually use? Do you use JUL?
Slf4j usually, with the JDK adapter.
On Sat, Nov 30, 2024, 6:02 PM Rob Bygrave @.***> wrote:
I'm trying to remove dependencies, not add bigger ones
What logging backends do you actually use? Do you use JUL?
— Reply to this email directly, view it on GitHub https://github.com/avaje/avaje-jex/pull/100#issuecomment-2509466832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHWIY43STRIPTOCKCZ4H2G32DI7YBAVCNFSM6AAAAABSWKLQ4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBZGQ3DMOBTGI . You are receiving this because you were assigned.Message ID: @.***>
Or more specific we typically use logback or log4j2 depending on the team. If the perf requirements are not that high I use JUL for lambdas
On Sat, Nov 30, 2024, 6:41 PM Josiah Noel @.***> wrote:
Slf4j usually, with the JDK adapter.
On Sat, Nov 30, 2024, 6:02 PM Rob Bygrave @.***> wrote:
I'm trying to remove dependencies, not add bigger ones
What logging backends do you actually use? Do you use JUL?
— Reply to this email directly, view it on GitHub https://github.com/avaje/avaje-jex/pull/100#issuecomment-2509466832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHWIY43STRIPTOCKCZ4H2G32DI7YBAVCNFSM6AAAAABSWKLQ4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBZGQ3DMOBTGI . You are receiving this because you were assigned.Message ID: @.***>
So slf4j-api is 70kb and to me if feels like its already in most applications. For me currently, I think it's everywhere including Lambdas for us. I have experimented with removing it and going 100% System.Logger but actually imo that is a bit of a pain once you get a few developers involved ... and I'll suggest that is because for Application Developers [not library developers] slf4j-api is kinda nice and easy to use, its expected and everyone knows it etc.
That is, getting "Application Developers" to adopt 100% System.Logger currently to me seems marginal - the gain doesn't quite seem worth it to me as I currently see it. I think you are seeing it as worth it for Lambdas.
What I don't want to do is remove AppLog and end up in a worse place, and my current thinking is that JUL is that worse place - as I see it, it's a PITA. So if we keep AppLog and include the dependency that adapts that to slf4j ... then this actually suites MOST people / the vast majority of the people will be happy enough.
Hmmm.
Removing this would make this a zero-dependency web framework.
For me that aesthetic is pretty cool.
I'm not opposed to keeping applog if you think it is needed.
So slf4j-api is 70kb and to me if feels like its already in most applications.
Maybe so, but forcing the library to use SLF4J robs the consumer of the ability to make that call which I definitely don't like.
Also we don't use logging that much in Jex
FYI: AWS Lambda runtime still does not service load a System.Logger, so still uses JUL. In this sense any libs that get used with AWS Lambda managed runtime should still use AppLog imo. So is this the only exception to that rule? and how does that impact things? hmmm, pondering ...
So is this the only exception to that rule?
We have avaje sigma for lambdas, so I can't imagine a scenario where Jex would be used inside of one.
So yeah, let's give it a go without AppLog. The only issue here is that for myself, I'm 99% of the time going to be using Jex with avaje config etc so AppLog is going to be there for those [due to AWS Lambda funkiness] ... and I think that means that for those apps I will need slf4j-jdk-platform-logging
when I use Jex [where as with AppLog I could do it without that].
Says here that applog is mainly used for when an application does not have a dedicated JVM. (like AWS lambda)
Is there a reason to have this dependency for something guaranteed not to be deployed on stuff like lambda?