See below. On 1/3/19 10:29 AM, Steve Ebersole wrote: 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.

+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 <guillaume.smet(a)gmail.com&gt; 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. 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 <guillaume.smet(a)gmail.com&gt; wrote:

On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: 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 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.

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 <guillaume.smet(a)gmail.com&gt; wrote:

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. 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 <sanne(a)hibernate.org&gt; wrote: > On Fri, 11 Jan 2019 at 09:53, Guillaume Smet <guillaume.smet(a)gmail.com&gt; > 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. > > 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. > 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.smet(a)gmail.com&gt; 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 <steve(a)hibernate.org&gt; > wrote: > >>> > >>> > >>> > >>> On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > >>>> > >>>> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole <steve(a)hibernate.org&gt; > 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. > >>> > >>> >

On Thu, 10 Jan 2019 at 16:39, Steve Ebersole <steve(a)hibernate.org&gt; wrote: 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. Fair enough; I don't agree but happy to follow your guidance. 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

On Fri, 11 Jan 2019 at 14:00, Steve Ebersole <steve(a)hibernate.org&gt; wrote: 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. Let's face that in front of some great food in Rome :)