Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Tue, 15 Jan 2019 at 14:24, Guillaume Smet wrote: > > > A minor nitpick: not logging which entities are being enhanced seems > reasonable when ORM is being booted, but as a user I'd probably expect > to see such output if I'm running an explicit enhancement task via > some of the tooling. > > Perhaps you should allow the enhancer tasks to raise these back up to > INFO; maybe the enhancer task should pass in its own enhancement > observer? > > They already do log something if a class has been enhanced. Look for > "Successfully enhanced class" in the code. > > So I think we are covered here. Nice, thanks for checking. > > -- > Guillaume > > On Fri, Jan 11, 2019 at 12:04 PM Sanne Grinovero wrote: >> >> On Fri, 11 Jan 2019 at 09:53, Guillaume Smet >> wrote: >> > >> > So what I suggest: if you disagree on a change, just comment on the >> > specific line of the PR and I'll revert. >> > >> > I plan to merge that on Tuesday. >> >> I like it. Not merging it yet to get Steve a chance to comment too. >> >> A minor nitpick: not logging which entities are being enhanced seems >> reasonable when ORM is being booted, but as a user I'd probably expect >> to see such output if I'm running an explicit enhancement task via >> some of the tooling. >> Perhaps you should allow the enhancer tasks to raise these back up to >> INFO; maybe the enhancer task should pass in its own enhancement >> observer? >> >> Thanks Guillaume! >> >> > >> > On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet >> > wrote: >> >> >> >> In meeting all day so making progress on dumb stuff. >> >> >> >> Here is a very conservative PR on which I hope we could agree on quickly: >> >> https://github.com/hibernate/hibernate-orm/pull/2728 >> >> >> >> -- >> >> Guillaume >> >> >> >> On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole >> >> wrote: >> >>> >> >>> >> >>> >> >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero >> >>> wrote: >> >> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole >> wrote: >> > >> > I disagree that logging a single message is a better solution because >> > that probably ends up wrapping multiple lines, just as your sample >> > happened to do in the email. IMO that is actually more difficult to >> > read. >> >> Ok keep it in one line if you prefer. No strong preference on how it's >> presented, but I think it's a big mistake to hide essential >> diagnostics: "paste the logs" is often useful when helping someone; it >> gets much harder if you first have to change categories. >> >>> >> >>> >> >>> You are combining separate things here >> >>> >> >>> First, *you* are the one that suggested doing it on one line unless I >> >>> have misunderstood. My point is simply that practically speaking that >> >>> will either mean having to read wrapped lines (eww) or scroll >> >>> horizontally (double eww) to read this info. If your desire is to >> >>> continue present this information anyway, then, well, what exactly are >> >>> we changing? Just making it harder to read? >> >>> >> >>> "Diagnostics".. interesting choice of word... if you are diagnosing >> >>> something that implies that there is a problem you are debugging... but >> >>> here we are talking about boot-time informational logging. Different >> >>> beasts. >> >>> >> >>> If the distinction you are trying to make is that we want to see at a >> >>> glance what config Hibernate thinks it just processed versus what you >> >>> think it should be (was caching enabled, etc) - well, where do you draw >> >>> the line? Because this gets back to my first point; if you log >> >>> everything that is "useful" in this single boot-time log message it is >> >>> going to be completely unreadable. >> >>> >> >>> >> +1 those symbolic loggers are a great idea. But then please don't hide >> this information at least until we have those easier logger >> categories: Guillaume is set to patch 5.4x - which doesn't have them >> yet. >> >>> >> >>> >> >>> What I am doing in 6 has no bearing on this discussion. Either we >> >>> display information or we don't - that is the crux of this discussion, >> >>> not which logger/category name we use. >> >>> >> >>> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
> A minor nitpick: not logging which entities are being enhanced seems reasonable when ORM is being booted, but as a user I'd probably expect to see such output if I'm running an explicit enhancement task via some of the tooling. > Perhaps you should allow the enhancer tasks to raise these back up to INFO; maybe the enhancer task should pass in its own enhancement observer? They already do log something if a class has been enhanced. Look for "Successfully enhanced class" in the code. So I think we are covered here. -- Guillaume On Fri, Jan 11, 2019 at 12:04 PM Sanne Grinovero wrote: > On Fri, 11 Jan 2019 at 09:53, Guillaume Smet > wrote: > > > > So what I suggest: if you disagree on a change, just comment on the > specific line of the PR and I'll revert. > > > > I plan to merge that on Tuesday. > > I like it. Not merging it yet to get Steve a chance to comment too. > > A minor nitpick: not logging which entities are being enhanced seems > reasonable when ORM is being booted, but as a user I'd probably expect > to see such output if I'm running an explicit enhancement task via > some of the tooling. > Perhaps you should allow the enhancer tasks to raise these back up to > INFO; maybe the enhancer task should pass in its own enhancement > observer? > > Thanks Guillaume! > > > > > On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet < > guillaume.s...@gmail.com> wrote: > >> > >> In meeting all day so making progress on dumb stuff. > >> > >> Here is a very conservative PR on which I hope we could agree on > quickly: > >> https://github.com/hibernate/hibernate-orm/pull/2728 > >> > >> -- > >> Guillaume > >> > >> On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole > wrote: > >>> > >>> > >>> > >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero > wrote: > > On Thu, 10 Jan 2019 at 01:44, Steve Ebersole > wrote: > > > > I disagree that logging a single message is a better solution > because that probably ends up wrapping multiple lines, just as your sample > happened to do in the email. IMO that is actually more difficult to read. > > Ok keep it in one line if you prefer. No strong preference on how it's > presented, but I think it's a big mistake to hide essential > diagnostics: "paste the logs" is often useful when helping someone; it > gets much harder if you first have to change categories. > >>> > >>> > >>> You are combining separate things here > >>> > >>> First, *you* are the one that suggested doing it on one line unless I > have misunderstood. My point is simply that practically speaking that will > either mean having to read wrapped lines (eww) or scroll horizontally > (double eww) to read this info. If your desire is to continue present this > information anyway, then, well, what exactly are we changing? Just making > it harder to read? > >>> > >>> "Diagnostics".. interesting choice of word... if you are diagnosing > something that implies that there is a problem you are debugging... but > here we are talking about boot-time informational logging. Different > beasts. > >>> > >>> If the distinction you are trying to make is that we want to see at a > glance what config Hibernate thinks it just processed versus what you think > it should be (was caching enabled, etc) - well, where do you draw the > line? Because this gets back to my first point; if you log everything that > is "useful" in this single boot-time log message it is going to be > completely unreadable. > >>> > >>> > +1 those symbolic loggers are a great idea. But then please don't hide > this information at least until we have those easier logger > categories: Guillaume is set to patch 5.4x - which doesn't have them > yet. > >>> > >>> > >>> What I am doing in 6 has no bearing on this discussion. Either we > display information or we don't - that is the crux of this discussion, not > which logger/category name we use. > >>> > >>> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
Sounds good to me! :) On Fri, Jan 11, 2019 at 8:19 AM Sanne Grinovero wrote: > On Fri, 11 Jan 2019 at 14:00, Steve Ebersole wrote: > > > > Guillaume - I added a general start-a-discussion comment to the PR. > Hopefully anyone with an opinion on that can chime in there. Beyond that, > +1 > > > > > > Sanne - ok, I see. You are not expecting users to have to deal with > wrapping/scrolling because you limit the presented information to an > arbitrary set of values. That's certainly an option. My only caution > there is that this is an arbitrary list of values-of-interest. > > > > We all agree version is important. It is beyond that that we start to > have different preferences. I think everything beyond that is DEBUG-level > info. For any additional values, I worry about the arbitrary nature of > what we present and don't in this message. I mean to me, the same argument > that leads to "caching enabled/disabled" being important enough to list > also dictates that CDI integration is important enough too. Same for > BytecodeProvider, ConnectionProvider, ... Its this question of where we > draw the line that concerns me. And if we are drawing an arbitrary line, > why are we drawing that line at all? > > Yeah it's arbitrary. When I proposed it I thought with some luck we > might have a quick consensus; if not let's just stick to the version. > > > I'll eagerly await your discussion about enabling caching by default ;) > > Let's face that in front of some great food in Rome :) > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Fri, 11 Jan 2019 at 14:00, Steve Ebersole wrote: > > Guillaume - I added a general start-a-discussion comment to the PR. > Hopefully anyone with an opinion on that can chime in there. Beyond that, +1 > > > Sanne - ok, I see. You are not expecting users to have to deal with > wrapping/scrolling because you limit the presented information to an > arbitrary set of values. That's certainly an option. My only caution there > is that this is an arbitrary list of values-of-interest. > > We all agree version is important. It is beyond that that we start to have > different preferences. I think everything beyond that is DEBUG-level info. > For any additional values, I worry about the arbitrary nature of what we > present and don't in this message. I mean to me, the same argument that > leads to "caching enabled/disabled" being important enough to list also > dictates that CDI integration is important enough too. Same for > BytecodeProvider, ConnectionProvider, ... Its this question of where we draw > the line that concerns me. And if we are drawing an arbitrary line, why are > we drawing that line at all? Yeah it's arbitrary. When I proposed it I thought with some luck we might have a quick consensus; if not let's just stick to the version. > I'll eagerly await your discussion about enabling caching by default ;) Let's face that in front of some great food in Rome :) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
Guillaume - I added a general start-a-discussion comment to the PR. Hopefully anyone with an opinion on that can chime in there. Beyond that, +1 Sanne - ok, I see. You are not expecting users to have to deal with wrapping/scrolling because you limit the presented information to an arbitrary set of values. That's certainly an option. My only caution there is that this is an arbitrary list of values-of-interest. We all agree version is important. It is beyond that that we start to have different preferences. I think everything beyond that is DEBUG-level info. For any additional values, I worry about the arbitrary nature of what we present and don't in this message. I mean to me, the same argument that leads to "caching enabled/disabled" being important enough to list also dictates that CDI integration is important enough too. Same for BytecodeProvider, ConnectionProvider, ... Its this question of where we draw the line that concerns me. And if we are drawing an arbitrary line, why are we drawing that line at all? I'll eagerly await your discussion about enabling caching by default ;) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Fri, 11 Jan 2019 at 09:53, Guillaume Smet wrote: > > So what I suggest: if you disagree on a change, just comment on the specific > line of the PR and I'll revert. > > I plan to merge that on Tuesday. I like it. Not merging it yet to get Steve a chance to comment too. A minor nitpick: not logging which entities are being enhanced seems reasonable when ORM is being booted, but as a user I'd probably expect to see such output if I'm running an explicit enhancement task via some of the tooling. Perhaps you should allow the enhancer tasks to raise these back up to INFO; maybe the enhancer task should pass in its own enhancement observer? Thanks Guillaume! > > On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet > wrote: >> >> In meeting all day so making progress on dumb stuff. >> >> Here is a very conservative PR on which I hope we could agree on quickly: >> https://github.com/hibernate/hibernate-orm/pull/2728 >> >> -- >> Guillaume >> >> On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole wrote: >>> >>> >>> >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero >>> wrote: On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > I disagree that logging a single message is a better solution because > that probably ends up wrapping multiple lines, just as your sample > happened to do in the email. IMO that is actually more difficult to > read. Ok keep it in one line if you prefer. No strong preference on how it's presented, but I think it's a big mistake to hide essential diagnostics: "paste the logs" is often useful when helping someone; it gets much harder if you first have to change categories. >>> >>> >>> You are combining separate things here >>> >>> First, *you* are the one that suggested doing it on one line unless I have >>> misunderstood. My point is simply that practically speaking that will >>> either mean having to read wrapped lines (eww) or scroll horizontally >>> (double eww) to read this info. If your desire is to continue present this >>> information anyway, then, well, what exactly are we changing? Just making >>> it harder to read? >>> >>> "Diagnostics".. interesting choice of word... if you are diagnosing >>> something that implies that there is a problem you are debugging... but >>> here we are talking about boot-time informational logging. Different >>> beasts. >>> >>> If the distinction you are trying to make is that we want to see at a >>> glance what config Hibernate thinks it just processed versus what you think >>> it should be (was caching enabled, etc) - well, where do you draw the line? >>> Because this gets back to my first point; if you log everything that is >>> "useful" in this single boot-time log message it is going to be completely >>> unreadable. >>> >>> +1 those symbolic loggers are a great idea. But then please don't hide this information at least until we have those easier logger categories: Guillaume is set to patch 5.4x - which doesn't have them yet. >>> >>> >>> What I am doing in 6 has no bearing on this discussion. Either we display >>> information or we don't - that is the crux of this discussion, not which >>> logger/category name we use. >>> >>> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Thu, 10 Jan 2019 at 16:39, Steve Ebersole wrote: > > > > On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: >> >> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: >> > >> > I disagree that logging a single message is a better solution because that >> > probably ends up wrapping multiple lines, just as your sample happened to >> > do in the email. IMO that is actually more difficult to read. >> >> Ok keep it in one line if you prefer. No strong preference on how it's >> presented, but I think it's a big mistake to hide essential >> diagnostics: "paste the logs" is often useful when helping someone; it >> gets much harder if you first have to change categories. > > > You are combining separate things here > > First, *you* are the one that suggested doing it on one line unless I have > misunderstood. My point is simply that practically speaking that will either > mean having to read wrapped lines (eww) or scroll horizontally (double eww) > to read this info. If your desire is to continue present this information > anyway, then, well, what exactly are we changing? Just making it harder to > read? I wasn't implying it would necessarily wrap on multiple lines. Not suggesting to add a ton of information, but a careful selection - if we take my example literally that should fit in "most" defintions of lines, especially as it's shorter than many other messages we produce. > "Diagnostics".. interesting choice of word... if you are diagnosing something > that implies that there is a problem you are debugging... but here we are > talking about boot-time informational logging. Different beasts. Fair enough; I don't agree but happy to follow your guidance. > > If the distinction you are trying to make is that we want to see at a glance > what config Hibernate thinks it just processed versus what you think it > should be (was caching enabled, etc) - well, where do you draw the line? > Because this gets back to my first point; if you log everything that is > "useful" in this single boot-time log message it is going to be completely > unreadable. Sure; I just meant we should always log: - Hibernate's version - Dialect choice And possibly also: - Transaction mode - If caching is enabled (especially as I have in mind a proposal to have 2LC and query caching enabled by default: not to sidetrack this conversation now but that's where I was coming from) That's just four pieces of information which we could try to show by default; I understand it's not much and not enough to diagnose many problems, but it felt like a good balance to me as it's useful to have some basics logged by default as a starting point. No strong feeling though, so if you disagree.. you're the lead and that's it. Thanks, Sanne > > >> +1 those symbolic loggers are a great idea. But then please don't hide >> this information at least until we have those easier logger >> categories: Guillaume is set to patch 5.4x - which doesn't have them >> yet. > > > What I am doing in 6 has no bearing on this discussion. Either we display > information or we don't - that is the crux of this discussion, not which > logger/category name we use. > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
So what I suggest: if you disagree on a change, just comment on the specific line of the PR and I'll revert. I plan to merge that on Tuesday. On Fri, Jan 11, 2019 at 10:24 AM Guillaume Smet wrote: > In meeting all day so making progress on dumb stuff. > > Here is a very conservative PR on which I hope we could agree on quickly: > https://github.com/hibernate/hibernate-orm/pull/2728 > > -- > Guillaume > > On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole > wrote: > >> >> >> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero >> wrote: >> >>> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole >>> wrote: >>> > >>> > I disagree that logging a single message is a better solution because >>> that probably ends up wrapping multiple lines, just as your sample happened >>> to do in the email. IMO that is actually more difficult to read. >>> >>> Ok keep it in one line if you prefer. No strong preference on how it's >>> presented, but I think it's a big mistake to hide essential >>> diagnostics: "paste the logs" is often useful when helping someone; it >>> gets much harder if you first have to change categories. >>> >> >> You are combining separate things here >> >> First, *you* are the one that suggested doing it on one line unless I >> have misunderstood. My point is simply that practically speaking that will >> either mean having to read wrapped lines (eww) or scroll horizontally >> (double eww) to read this info. If your desire is to continue present this >> information anyway, then, well, what exactly are we changing? Just making >> it harder to read? >> >> "Diagnostics".. interesting choice of word... if you are diagnosing >> something that implies that there is a problem you are debugging... but >> here we are talking about boot-time informational logging. Different >> beasts. >> >> If the distinction you are trying to make is that we want to see at a >> glance what config Hibernate thinks it just processed versus what you think >> it should be (was caching enabled, etc) - well, where do you draw the >> line? Because this gets back to my first point; if you log everything that >> is "useful" in this single boot-time log message it is going to be >> completely unreadable. >> >> >> +1 those symbolic loggers are a great idea. But then please don't hide >>> this information at least until we have those easier logger >>> categories: Guillaume is set to patch 5.4x - which doesn't have them >>> yet. >>> >> >> What I am doing in 6 has no bearing on this discussion. Either we >> display information or we don't - that is the crux of this discussion, not >> which logger/category name we use. >> >> >> ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
In meeting all day so making progress on dumb stuff. Here is a very conservative PR on which I hope we could agree on quickly: https://github.com/hibernate/hibernate-orm/pull/2728 -- Guillaume On Thu, Jan 10, 2019 at 5:38 PM Steve Ebersole wrote: > > > On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero > wrote: > >> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: >> > >> > I disagree that logging a single message is a better solution because >> that probably ends up wrapping multiple lines, just as your sample happened >> to do in the email. IMO that is actually more difficult to read. >> >> Ok keep it in one line if you prefer. No strong preference on how it's >> presented, but I think it's a big mistake to hide essential >> diagnostics: "paste the logs" is often useful when helping someone; it >> gets much harder if you first have to change categories. >> > > You are combining separate things here > > First, *you* are the one that suggested doing it on one line unless I have > misunderstood. My point is simply that practically speaking that will > either mean having to read wrapped lines (eww) or scroll horizontally > (double eww) to read this info. If your desire is to continue present this > information anyway, then, well, what exactly are we changing? Just making > it harder to read? > > "Diagnostics".. interesting choice of word... if you are diagnosing > something that implies that there is a problem you are debugging... but > here we are talking about boot-time informational logging. Different > beasts. > > If the distinction you are trying to make is that we want to see at a > glance what config Hibernate thinks it just processed versus what you think > it should be (was caching enabled, etc) - well, where do you draw the > line? Because this gets back to my first point; if you log everything that > is "useful" in this single boot-time log message it is going to be > completely unreadable. > > > +1 those symbolic loggers are a great idea. But then please don't hide >> this information at least until we have those easier logger >> categories: Guillaume is set to patch 5.4x - which doesn't have them >> yet. >> > > What I am doing in 6 has no bearing on this discussion. Either we display > information or we don't - that is the crux of this discussion, not which > logger/category name we use. > > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: > On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > > > I disagree that logging a single message is a better solution because > that probably ends up wrapping multiple lines, just as your sample happened > to do in the email. IMO that is actually more difficult to read. > > Ok keep it in one line if you prefer. No strong preference on how it's > presented, but I think it's a big mistake to hide essential > diagnostics: "paste the logs" is often useful when helping someone; it > gets much harder if you first have to change categories. > You are combining separate things here First, *you* are the one that suggested doing it on one line unless I have misunderstood. My point is simply that practically speaking that will either mean having to read wrapped lines (eww) or scroll horizontally (double eww) to read this info. If your desire is to continue present this information anyway, then, well, what exactly are we changing? Just making it harder to read? "Diagnostics".. interesting choice of word... if you are diagnosing something that implies that there is a problem you are debugging... but here we are talking about boot-time informational logging. Different beasts. If the distinction you are trying to make is that we want to see at a glance what config Hibernate thinks it just processed versus what you think it should be (was caching enabled, etc) - well, where do you draw the line? Because this gets back to my first point; if you log everything that is "useful" in this single boot-time log message it is going to be completely unreadable. +1 those symbolic loggers are a great idea. But then please don't hide > this information at least until we have those easier logger > categories: Guillaume is set to patch 5.4x - which doesn't have them > yet. > What I am doing in 6 has no bearing on this discussion. Either we display information or we don't - that is the crux of this discussion, not which logger/category name we use. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > I disagree that logging a single message is a better solution because that > probably ends up wrapping multiple lines, just as your sample happened to do > in the email. IMO that is actually more difficult to read. Ok keep it in one line if you prefer. No strong preference on how it's presented, but I think it's a big mistake to hide essential diagnostics: "paste the logs" is often useful when helping someone; it gets much harder if you first have to change categories. > And I just do not understand this idea that we have to direct people to > enable logging to track down problems. This is a non-argument to me. I can understand were you're coming from, but that's how most support people work. Let's try to be nice to them :) > As for what logger to use... that is definitely a concern, though its not > really any different than we have today. If I refactor an internal class > (because, well, its internal) - that almost always will affect logging on the > user's end. It's one of the reasons I started looking at using "symbolic" > logger names. Which of course is its own concern. +1 those symbolic loggers are a great idea. But then please don't hide this information at least until we have those easier logger categories: Guillaume is set to patch 5.4x - which doesn't have them yet. Thanks, Sanne > > On Wed, Jan 9, 2019 at 12:54 PM Guillaume Smet > wrote: >> >> Pretty good idea but definitely too much work for the effort I want to put >> in it right now. >> >> But, yes, we can do that for version 7.0.1.Final, I like your example :). >> >> I will make a proposal to reduce the log verbosity (enhanced classes, >> hibernate.properties missing and a few others) but keep the important >> diagnostic information as is. >> >> On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero wrote: >> >> > +1 to polish output, but: >> > >> > I don't want to need to figure out how to reconfigure whatever Logger >> > of the day one happens to hit, to finally notice that essential >> > configuration details are wrong. Mostly because it requires to get the >> > idea to actually check this, which is not a straightforward thought >> > when all you observe is some odd behaviour. >> > >> > Not least, big we don't want to have to go back to supported customers >> > and community members who have a problem with a "can you change the >> > log levels as I'm missing essential information": that's a huge waste >> > of time especially if we're having an exchange across timezones. >> > >> > Could we rather collect essential info and then print it all out as a >> > single message? >> > >> > "Hibernate ORM ready and operational! [version: 7.0.1.Final, >> > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" >> > >> > Also I'd question that "verbosity" isn't the same as brevity; the >> > focus should be on hiding unnecessary technicalities but showing nicer >> > / better information, so I'd not be shy to use some multi-line >> > information box if that looks better. >> > >> > Thanks, >> > Sanne >> > >> > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet >> > wrote: >> > > >> > > Yeah sure, they will be kept as is just moved to DEBUG. >> > > >> > > The only one that would change is the "Processing PersistenceUnitInfo" >> > > thing: we will remove the INFO one and keep the more detailed DEBUG one. >> > > >> > > BTW, I agree with everything Steve said, sorry for not replying earlier. >> > > >> > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford >> > wrote: >> > > >> > > > See below. >> > > > >> > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: >> > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: >> > > > >> org.hibernate.dialect.PostgreSQL95Dialect >> > > > >> >> > > > >> -> wondering if it has any value to log the dialect? I mean if you >> > don't >> > > > >> use the right one, you will definitely have some issues. >> > > > >> >> > > > > True, but it is probably hard(er) to interpret the true source of the >> > > > > issues later on. >> > > > > >> > > > > However, I think it is reasonable to make this DEBUG. If you have >> > > > problems >> > > > > the first reasonable thing to do is to crank logging to DEBUG if not >> > > > TRACE. >> > > > >> > > > I completely agree. >> > > > >> > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want >> > > > to necessarily change it such that it is no longer included in log >> > > > output at all. Having it be included is a good first-line of defense >> > on >> > > > trying to resolve potential problems not only for us, but even for >> > users >> > > > who are doing their own debugging before reporting an issue; >> > > > particularly if the error in question implies some Dialect >> > configuration >> > > > problem. >> > > > >> > > ___ >> > > hibernate-dev mailing list >> > > hibernate-dev@lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
I disagree that logging a single message is a better solution because that probably ends up wrapping multiple lines, just as your sample happened to do in the email. IMO that is actually more difficult to read. And I just do not understand this idea that we have to direct people to enable logging to track down problems. This is a non-argument to me. As for what logger to use... that is definitely a concern, though its not really any different than we have today. If I refactor an internal class (because, well, its internal) - that almost always will affect logging on the user's end. It's one of the reasons I started looking at using "symbolic" logger names. Which of course is its own concern. On Wed, Jan 9, 2019 at 12:54 PM Guillaume Smet wrote: > Pretty good idea but definitely too much work for the effort I want to put > in it right now. > > But, yes, we can do that for version 7.0.1.Final, I like your example :). > > I will make a proposal to reduce the log verbosity (enhanced classes, > hibernate.properties missing and a few others) but keep the important > diagnostic information as is. > > On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero > wrote: > > > +1 to polish output, but: > > > > I don't want to need to figure out how to reconfigure whatever Logger > > of the day one happens to hit, to finally notice that essential > > configuration details are wrong. Mostly because it requires to get the > > idea to actually check this, which is not a straightforward thought > > when all you observe is some odd behaviour. > > > > Not least, big we don't want to have to go back to supported customers > > and community members who have a problem with a "can you change the > > log levels as I'm missing essential information": that's a huge waste > > of time especially if we're having an exchange across timezones. > > > > Could we rather collect essential info and then print it all out as a > > single message? > > > > "Hibernate ORM ready and operational! [version: 7.0.1.Final, > > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" > > > > Also I'd question that "verbosity" isn't the same as brevity; the > > focus should be on hiding unnecessary technicalities but showing nicer > > / better information, so I'd not be shy to use some multi-line > > information box if that looks better. > > > > Thanks, > > Sanne > > > > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet > > wrote: > > > > > > Yeah sure, they will be kept as is just moved to DEBUG. > > > > > > The only one that would change is the "Processing PersistenceUnitInfo" > > > thing: we will remove the INFO one and keep the more detailed DEBUG > one. > > > > > > BTW, I agree with everything Steve said, sorry for not replying > earlier. > > > > > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford > > wrote: > > > > > > > See below. > > > > > > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > > > > >> org.hibernate.dialect.PostgreSQL95Dialect > > > > >> > > > > >> -> wondering if it has any value to log the dialect? I mean if you > > don't > > > > >> use the right one, you will definitely have some issues. > > > > >> > > > > > True, but it is probably hard(er) to interpret the true source of > the > > > > > issues later on. > > > > > > > > > > However, I think it is reasonable to make this DEBUG. If you have > > > > problems > > > > > the first reasonable thing to do is to crank logging to DEBUG if > not > > > > TRACE. > > > > > > > > I completely agree. > > > > > > > > I think its reasonable to make it DEBUG/TRACE but I don't think I > want > > > > to necessarily change it such that it is no longer included in log > > > > output at all. Having it be included is a good first-line of defense > > on > > > > trying to resolve potential problems not only for us, but even for > > users > > > > who are doing their own debugging before reporting an issue; > > > > particularly if the error in question implies some Dialect > > configuration > > > > problem. > > > > > > > ___ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
Pretty good idea but definitely too much work for the effort I want to put in it right now. But, yes, we can do that for version 7.0.1.Final, I like your example :). I will make a proposal to reduce the log verbosity (enhanced classes, hibernate.properties missing and a few others) but keep the important diagnostic information as is. On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero wrote: > +1 to polish output, but: > > I don't want to need to figure out how to reconfigure whatever Logger > of the day one happens to hit, to finally notice that essential > configuration details are wrong. Mostly because it requires to get the > idea to actually check this, which is not a straightforward thought > when all you observe is some odd behaviour. > > Not least, big we don't want to have to go back to supported customers > and community members who have a problem with a "can you change the > log levels as I'm missing essential information": that's a huge waste > of time especially if we're having an exchange across timezones. > > Could we rather collect essential info and then print it all out as a > single message? > > "Hibernate ORM ready and operational! [version: 7.0.1.Final, > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" > > Also I'd question that "verbosity" isn't the same as brevity; the > focus should be on hiding unnecessary technicalities but showing nicer > / better information, so I'd not be shy to use some multi-line > information box if that looks better. > > Thanks, > Sanne > > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet > wrote: > > > > Yeah sure, they will be kept as is just moved to DEBUG. > > > > The only one that would change is the "Processing PersistenceUnitInfo" > > thing: we will remove the INFO one and keep the more detailed DEBUG one. > > > > BTW, I agree with everything Steve said, sorry for not replying earlier. > > > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford > wrote: > > > > > See below. > > > > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > > > >> org.hibernate.dialect.PostgreSQL95Dialect > > > >> > > > >> -> wondering if it has any value to log the dialect? I mean if you > don't > > > >> use the right one, you will definitely have some issues. > > > >> > > > > True, but it is probably hard(er) to interpret the true source of the > > > > issues later on. > > > > > > > > However, I think it is reasonable to make this DEBUG. If you have > > > problems > > > > the first reasonable thing to do is to crank logging to DEBUG if not > > > TRACE. > > > > > > I completely agree. > > > > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want > > > to necessarily change it such that it is no longer included in log > > > output at all. Having it be included is a good first-line of defense > on > > > trying to resolve potential problems not only for us, but even for > users > > > who are doing their own debugging before reporting an issue; > > > particularly if the error in question implies some Dialect > configuration > > > problem. > > > > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
+1 to polish output, but: I don't want to need to figure out how to reconfigure whatever Logger of the day one happens to hit, to finally notice that essential configuration details are wrong. Mostly because it requires to get the idea to actually check this, which is not a straightforward thought when all you observe is some odd behaviour. Not least, big we don't want to have to go back to supported customers and community members who have a problem with a "can you change the log levels as I'm missing essential information": that's a huge waste of time especially if we're having an exchange across timezones. Could we rather collect essential info and then print it all out as a single message? "Hibernate ORM ready and operational! [version: 7.0.1.Final, Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" Also I'd question that "verbosity" isn't the same as brevity; the focus should be on hiding unnecessary technicalities but showing nicer / better information, so I'd not be shy to use some multi-line information box if that looks better. Thanks, Sanne On Mon, 7 Jan 2019 at 16:14, Guillaume Smet wrote: > > Yeah sure, they will be kept as is just moved to DEBUG. > > The only one that would change is the "Processing PersistenceUnitInfo" > thing: we will remove the INFO one and keep the more detailed DEBUG one. > > BTW, I agree with everything Steve said, sorry for not replying earlier. > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford wrote: > > > See below. > > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > > >> org.hibernate.dialect.PostgreSQL95Dialect > > >> > > >> -> wondering if it has any value to log the dialect? I mean if you don't > > >> use the right one, you will definitely have some issues. > > >> > > > True, but it is probably hard(er) to interpret the true source of the > > > issues later on. > > > > > > However, I think it is reasonable to make this DEBUG. If you have > > problems > > > the first reasonable thing to do is to crank logging to DEBUG if not > > TRACE. > > > > I completely agree. > > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want > > to necessarily change it such that it is no longer included in log > > output at all. Having it be included is a good first-line of defense on > > trying to resolve potential problems not only for us, but even for users > > who are doing their own debugging before reporting an issue; > > particularly if the error in question implies some Dialect configuration > > problem. > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
Yeah sure, they will be kept as is just moved to DEBUG. The only one that would change is the "Processing PersistenceUnitInfo" thing: we will remove the INFO one and keep the more detailed DEBUG one. BTW, I agree with everything Steve said, sorry for not replying earlier. On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford wrote: > See below. > > On 1/3/19 10:29 AM, Steve Ebersole wrote: > > [o.h.d.Dialect] (main) HHH000400: Using dialect: > >> org.hibernate.dialect.PostgreSQL95Dialect > >> > >> -> wondering if it has any value to log the dialect? I mean if you don't > >> use the right one, you will definitely have some issues. > >> > > True, but it is probably hard(er) to interpret the true source of the > > issues later on. > > > > However, I think it is reasonable to make this DEBUG. If you have > problems > > the first reasonable thing to do is to crank logging to DEBUG if not > TRACE. > > I completely agree. > > I think its reasonable to make it DEBUG/TRACE but I don't think I want > to necessarily change it such that it is no longer included in log > output at all. Having it be included is a good first-line of defense on > trying to resolve potential problems not only for us, but even for users > who are doing their own debugging before reporting an issue; > particularly if the error in question implies some Dialect configuration > problem. > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
See below. On 1/3/19 10:29 AM, Steve Ebersole wrote: > [o.h.d.Dialect] (main) HHH000400: Using dialect: >> org.hibernate.dialect.PostgreSQL95Dialect >> >> -> wondering if it has any value to log the dialect? I mean if you don't >> use the right one, you will definitely have some issues. >> > True, but it is probably hard(er) to interpret the true source of the > issues later on. > > However, I think it is reasonable to make this DEBUG. If you have problems > the first reasonable thing to do is to crank logging to DEBUG if not TRACE. I completely agree. I think its reasonable to make it DEBUG/TRACE but I don't think I want to necessarily change it such that it is no longer included in log output at all. Having it be included is a good first-line of defense on trying to resolve potential problems not only for us, but even for users who are doing their own debugging before reporting an issue; particularly if the error in question implies some Dialect configuration problem. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
In general I agree with everything you said, but had a few specific comments in line... > [o.h.j.i.u.LogHelper] (main) HHH000204: Processing PersistenceUnitInfo [ > name: templatePU > ...] > > -> so, first, I would make this one a one liner as we apparently didn't add > any other properties. I think it was done to mimic the DEBUG output but I > don't see any value to having it on several lines. > > And, frankly, I think I would get rid of it altogether and only log > something at debug level. > +1 to dropping the INFO one altogether. However, I think we should keep the DEBUG one and it should remain multi-line. I could not tell if you were saying the same wrt DEBUG. [o.h.d.Dialect] (main) HHH000400: Using dialect: > org.hibernate.dialect.PostgreSQL95Dialect > > -> wondering if it has any value to log the dialect? I mean if you don't > use the right one, you will definitely have some issues. > True, but it is probably hard(er) to interpret the true source of the issues later on. However, I think it is reasonable to make this DEBUG. If you have problems the first reasonable thing to do is to crank logging to DEBUG if not TRACE. [o.h.e.t.j.p.i.JtaPlatformInitiator] (main) HHH000490: Using JtaPlatform > implementation: > > [org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform] > > -> This one, I don't know. It's probably important to know that JTA is > properly configured but I'm not terribly excited about keeping it. > Thoughts? > I think we agree here if I understand you correctly - a simple "JTA integration enabled" message is fine for the bootstrap INFO logging. But then it is kind of awkward to have 2 messages next to each other - the INFO saying JTA integration was enabled and then a DEBUG message saying which > > Maybe one solution could be to have all these ones tied to a > "org.hibernate.bootstrap" logger and thus have the ability to enable them > in one go. > I heard you made nice things in 6 about logging but I would like to improve > the situation in the stable version. > The specific changes on 6 are more what you mention. I break down each "subsystem" into a dedicated message-logger. The overall idea is to split the intended audience targeted by the messages into 2 groups. "Message logs" are more intended for users and DEBUG/TRACE logs are intended for developers (or "power users"). Message loggers use a different "logger name" scheme not based on class/package names but more of a symbolic subsystem name. E.g., from `org.hibernate.cache.spi.SecondLevelCacheLogger`[1], I grouped all caching related messages using the logger name `org.hibernate.orm.cache`. The reason is two-fold... First it is refactor-safe which is great given the intended audience. Secondly it allows for a more logical hierarchy of logger names. Also it groups all ORM-related logging under a single name, as opposed to having to use `org.hibernate` which affects logging for all Hibernate projects being used. `BootstrapLogger` was one I intended on doing as well already. This is all an on-going process as a task of opportunity, meaning I am doing that conversion as I work in the subsystem. Personally I think it does not make sense to make such changes in 5.4 though. Cleaning up the INFO->DEBUG stuff discussed above makes sense, I just mean re-organizing the loggers/names. [1] https://github.com/hibernate/hibernate-orm/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/cache/spi/SecondLevelCacheLogger.java > > I would like to move quickly on this and hopefully integrate it in the > upcoming 5.4.1 so feedback very welcome! If some are polemic, I will just > work on the easy ones, that would still improve the situation. > > Thanks! > > -- > Guillaume > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [ORM] Reducing startup log verbosity
Hi,
Got a report from a fellow Red Hatter complaining about our logging
verbosity being so 2004 and, well, I must admit I tend to agree.
This is from a launch on a simple PostgreSQL app. I added some comments
inline.
Note that it might seem like wasting our time but I would like to improve
the user experience in some contexts - happy to discuss the rationale
behing this discussion privately if needed.
[o.h.Version] (build-) HHH000412: Hibernate Core {5.4.0.Final}
-> this one is a product requirement so let's keep it as is for now,
hopefully, we will have a global solution for that at some point
[o.h.c.Environment] (build-) HHH000206: hibernate.properties not found
-> I think we should use DEBUG here, framework nowadays rely on their own
config injection mechanisms
[o.h.b.e.s.Enhancer] (pool-2-thread-6) Enhancing [jpa.SequencedAddress] as
Entity
[o.h.b.e.s.Enhancer] (pool-2-thread-10) Enhancing [jpa.WorkAddress] as
Composite
[o.h.b.e.s.Enhancer] (pool-2-thread-1) Enhancing [jpa.Address] as Composite
[o.h.b.e.s.Enhancer] (pool-2-thread-8) Extended enhancement of [jpa.Animal]
[o.h.b.e.s.Enhancer] (pool-2-thread-13) Enhancing [jpa.Human] as
MappedSuperclass
[o.h.b.e.s.Enhancer] (pool-2-thread-16) Enhancing [jpa.Person] as Entity
[o.h.b.e.s.Enhancer] (pool-2-thread-5) Enhancing [jpa.Customer] as Entity
-> I would vote for using DEBUG. Let's imagine a 250 entities model and I
think we can agree we don't want it to be logged by default.
[o.h.j.i.u.LogHelper] (main) HHH000204: Processing PersistenceUnitInfo [
name: templatePU
...]
-> so, first, I would make this one a one liner as we apparently didn't add
any other properties. I think it was done to mimic the DEBUG output but I
don't see any value to having it on several lines.
And, frankly, I think I would get rid of it altogether and only log
something at debug level.
[o.h.a.c.Version] (main) HCANN01: Hibernate Commons Annotations
{5.1.0.Final}
-> version, can't touch it for now.
[o.h.d.Dialect] (main) HHH000400: Using dialect:
org.hibernate.dialect.PostgreSQL95Dialect
-> wondering if it has any value to log the dialect? I mean if you don't
use the right one, you will definitely have some issues.
[o.h.e.j.e.i.LobCreatorBuilderImpl] (main) HHH000422: Disabling contextual
LOB creation as connection was null
-> I would move that to DEBUG.
[o.h.t.BasicTypeRegistry] (main) HHH000270: Type registration
[java.util.UUID] overrides previous :
org.hibernate.type.UUIDBinaryType@7e8dcdaa
-> as I understand it, we will always have this message at startup when
using PostgreSQL. I think we should make it DEBUG too. Or find another
solution for this specific case but having it logged on each PostgreSQL app
is definitely a bad thing.
[o.h.e.t.j.p.i.JtaPlatformInitiator] (main) HHH000490: Using JtaPlatform
implementation:
[org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform]
-> This one, I don't know. It's probably important to know that JTA is
properly configured but I'm not terribly excited about keeping it. Thoughts?
Maybe one solution could be to have all these ones tied to a
"org.hibernate.bootstrap" logger and thus have the ability to enable them
in one go.
I heard you made nice things in 6 about logging but I would like to improve
the situation in the stable version.
I would like to move quickly on this and hopefully integrate it in the
upcoming 5.4.1 so feedback very welcome! If some are polemic, I will just
work on the easy ones, that would still improve the situation.
Thanks!
--
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
