[hibernate-dev] [ORM] Reducing startup log verbosity

[Guillaume Smet]

> 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 <sanne at hibernate.org>
wrote:

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